Malwarebytes:

If you’ve encountered websites in maintenance mode today, it may be a security precaution. Reports of attacks targeting two critical PHP vulnerabilities have prompted warnings to install emergency updates and consider temporarily taking affected services offline until they can be patched.

[…]

Successful exploitation could let an attacker run malicious code on an affected server without logging in. That code would run with the permissions available to the PHP process, potentially allowing attackers to steal application data, alter website content, or establish a backdoor.

[…]

The PHP team scheduled its emergency security updates for October 21 at 10:00 am ET (14:00 UTC). It has now released fixes in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, and urges users to update immediately. Administrators should check with their hosting provider or operating system vendor for the appropriate updated packages.

Adam Engst:

Expect to see numerous websites go down or serve “Page not found” errors as they update PHP, the programming language that underpins 70% of websites. If you run a WordPress, Drupal, or Joomla site, this affects you directly.

Nick Heer:

Word on the street is that these exploits have leaked, and that remote code can likely be executed all the way back to PHP 5. If you have access to your website’s php.ini file, it might be worth turning off multipart uploads for now.

Vincent Schmalbach:

Two changes reduce the risk until the fixed versions are out. They were checked against PHP’s source code and the PHP manual, but they are not an official PHP mitigation. When someone suggested that turning off session upload progress might be enough, PHP core developer Gina Peter Banyard replied, “The only thing I can say is that the only mitigation is patching / upgrading PHP. I sadly know too much.” Use the stopgaps to lower the risk for a few hours, and update PHP as soon as the fixed builds exist.

Add to php.ini:

session.upload_progress.enabled = Off

Add to .htaccess:

<If "req('Content-Type') =~ /multipart/i">
    Require all denied
</If>

Howard Oakley:

Now move the pointer to the right edge of the list of folder contents, just far enough to the left to avoid moving the window divider, but not so far as to fully select items from within that folder. Click there and the item will be selected, but in grey, the same as would appear if it had been fully selected but its window was no longer in focus. At this stage, the original folder will still be fully highlighted, as if nothing had been selected inside it, but you can drag that grey unfocussed selection to include other items inside the folder.

On my Mac, if I click on a file icon in the second column, the first column retains focus. The second column only gets focus if I click on a filename (or even farther to the right).

Now using the up and down arrow keys doesn’t move within the items inside that folder, but back with the fully highlighted folder. With a few of the items inside that folder in grey, so they’re selected but not in focus, press the spacebar for a QuickLook preview, and you’ll see the greyed items, not the folder that’s still fully selected to the left.

[…]

In other situations, this becomes infuriating.

In my log browser LogUI, separation of selection from focus can leave you clicking wildly without being able to select log entries.

Previously:

• Tahoe Broke Resizing Finder Column View
• Viewing Metadata in the Finder
• Mojave Finder’s Preview Column Shouldn’t Prioritize Thumbnail Size

Update (2026-10-21): Philip Savoulidis:

I too was wondering if there was something peculiar with my Mac. Focus seems so broken in Golden Gate that I was expecting macOS reviews to mention it. In this regard, I am glad to see focus problems mentioned here.

The behaviour seems inconsistent. For example, in Finder and Mail the sidebar does not gain focus on click, but it does in Contacts and NetNewsWire (a third-party app). The Passwords app seems like the worst offender: the password list itself does not gain focus on click (e.g. click the search field then click an item and focus remains in the search field).

I spent some time investigating this, and I think it comes down to a SwiftUI bug. List and Table in SwiftUI are affected. Both use NSTableView under the hood, but they never become first responder on click.

But I don’t think NSBrowser is built on SwiftUI, so there are probably multiple issues here.

Jeff Benjamin:

A drawback of using an HDR-ready third-party monitor on macOS 26 Tahoe was the inability to activate High Dynamic Range at the common 2560 x 1440 scaled resolution. Fortunately, the newest macOS release resolves this problem.

Alexander Cohen:

• Symptom: scrolling is choppy on the Studio Display XDR at 120Hz or Adaptive (47–120Hz). At 60Hz, and on the MacBook’s own screen, scrolling is smooth.
• What devices are affected: M5 Pro MacBook Pros have reproduced the problem; other repots suggest the Mac mini with M5 Pro chip is also affected. Apple lists M5 Pro MacBook Pro models as supporting the Studio Display XDR at 120Hz.
• Likely cause: measurements suggest the GPU stays at a low clock speed while scrolling and misses frame deadlines.
• Workaround: MacRumors Forums poster Tiguanito’s M5ScrollBoost, a small menu bar app that encourages the GPU to run faster while you scroll.

Previously:

• MacBook Pro 2026
• Studio Display and Studio Display XDR

Update (2026-10-14): Timuçin Kabak:

Another issue I encountered is that the True Tone also applies to some external displays and applies a tint. I created a tool for it.

anonymoussingh:

We maintain a macOS product whose installer uses custom InstallerSection plugin bundles to show configuration panes during install. Starting with macOS 27 beta 6, all of our plugins stopped loading in Installer.app — the panes never appear and the install fails because our preinstall step depends on data the panes collect.

HirohikoKihara (via Ric Ford):

A third-party PKG installer that ships a custom Installer Plugin no longer displays one of its selection panes. The plugin bundle appears not to be loaded, so the pane that it provides is silently skipped and the user cannot choose the intended installation option.

FE:

This is regression for all latest updates eg. 15.8, 27.7, 28.0. This bug refuse open installer plugin for security reason in spite of the plugin and installer are correctly signed, notarized and works seamlessly in previous macOS versions. Workaround is copy installer (*.pkg) to local file system (home, desktop folder).

Previously:

• macOS 27.0.1
• macOS 26.7.1 and macOS 15.8.1

Bob Gendler:

Since macOS 26.4, there’s been an issue with the keychain hiding in plain sight and that issue is it’ll take ANY password. Say what? The story behind CVE-2026–43728.

[…]

Where this is a bit more of a kicker…you can reset the keychain password without even knowing the real one.

[…]

Now did Apple fully fix it, well mostly. Something is different after macOS 26.4 (I believe it’s the new, User Authentication Daemon — userauthd). On macOS 26.3, if you ran security lock-keychain and then security unlock-keychain it HAD to be your keychain password. But now they added this note to the man page.

Unlocking the login keychain might succeed when an incorrect password is presented, if other unlock factors are available.

Previously:

• Locked Down Passkey and Keychain Backups
• macOS 26.6
• macOS 26.4

Nicolas Seriot:

// "<a>" in UTF-16 LE + a single dangling byte
const UInt8 bytes[] = {'<', 0, 'a', 0, '>', 0, 'X'};

[…]

The whole bug is a confusion between bytes left versus UTF-16 characters left. The result is repeated buffer doubling until allocation fails, and a local process crash if the exception is uncaught.