❌

Normal view

macOS 15.7.9 and 14.8.9

7 August 2026 at 22:25

macOS 15.7.9 (security, full installer):

This update provides important security fixes and is recommended for all users.

macOS 14.8.9 (security, full installer):

This update provides important security fixes and is recommended for all users.

These seem to fix the same screen sharing bug as the macOS 26.6.1 update.

See also: Howard Oakley.

Previously:

Apple Fixes Screen Sharing Vulnerability in Tahoe, Sequoia, and Sonoma

6 August 2026 at 20:29
Apple has released updates to macOS 26.6.1, 15.7.9, and 14.8.9 to fix a Screen Sharing vulnerability that could let an attacker β€œon the network” connect without valid credentials. Update soon.

macOS Hidden Treasures: Typing Exotic Characters

Security Updates MacOS Tahoe 26.6.1, macOS Sequoia 15.7.9, macOS Sonoma 14.8.9 Released

6 August 2026 at 20:22

Apple has released security updates for MacOS Tahoe 26.6.1, MacOS Sequoia 15.7.9, and MacOS Sonoma 14.8.9, each addressing the same security flaw relating to the Screen Sharing service where an attacker could authenticate without valid credentials. Download links for IPSW and full installers for these new versions of MacOS are available further below. Due to ... Read More

The post Security Updates MacOS Tahoe 26.6.1, macOS Sequoia 15.7.9, macOS Sonoma 14.8.9 Released appeared first on OS X Daily.

NSPasteboard Crashes When Handling File Promises

3 August 2026 at 21:35

Wade Tregaskis:

NSPasteboard mutates itself simultaneously from the main thread and the global concurrent Dispatch pool, w.r.t. to its internal type cache. This is surprisingly trivial to reproduce (sample code below) by just dropping, e.g. a file promise (such as by opening a PNG in Preview, revealing the thumbnails sidebar, and then dragging the thumbnail onto the sample project’s window).

[…]

Since this bug causes semi-random memory corruption, it manifests in a large number of ways – not all of which are all that helpful.

[…]

SwiftUI’s onDrop(of:isTargeted:perform:) method makes no claims or promises as to what thread / queue it executes the closure on, and in fact according to the anonymous Apple engineer it never executes the closure on the main thread.

Now, while that may be the intent, the reality of that is wrong – in my experience it always executes the closure on the main thread (which makes a lot of sense to me as drag-and-drop event handling in AppKit has always been on the main thread in practice).

Apple also told him that NSPasteboard is not safe to use outside the main thread, even though that’s not documented, it’s not @MainActor, and Apple’s own code does do that.

❌