PHP's critical October 2026 fixes on a Mac: Homebrew, MacPorts, MAMP, Server.app and the firewall

Published 2026-10-22

On 21 October 2026 at 14:00 UTC, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, a day after announcing them in advance. They fix two critical flaws, each rated 9.2 under CVSS v4.0, that can let an unauthenticated request run code on the server. php.net is blunt about it: there are no complete mitigations, and updating is the only safe choice.

Most of the coverage assumes a Linux host, where the distribution's package arrives and you install it. A Mac is different. Whether you are fixed today depends on where your PHP came from, and at the time of writing (22 October 2026) the answer is different for Homebrew, MacPorts, MAMP and Apple's own PHP. This post goes through each, then the firewall in front of them.

The two flaws

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while request data is only partly initialised, and the cleanup that follows treats the invalid data as valid.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): state that belongs to one request can survive after its memory is freed, and a later request on the same worker can use it.

Every PHP that serves web requests is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. php.net rates mod_php the highest risk, with a demonstrated exploit in which an unauthenticated request triggers the flaw before any application code runs. Your own code, plug-ins and login pages don't stand in the way.

PHP 8.1 and older get no upstream release. For people who build from source, the security team has published minimal backports for 7.4, 8.0 and 8.1 as branches in php-src (for example PHP-8.1-CVE-2026-109618-109619). Nothing older than 7.4 has one.

Homebrew: fixed, but restart PHP-FPM

Homebrew packaged the new releases on 21 October: php is at 8.5.12, and [email protected], [email protected] and [email protected] are at 8.4.27, 8.3.36 and 8.2.35. So brew upgrade php (or brew upgrade [email protected], and so on) brings in the fix. If you have turned off Homebrew's automatic update, run brew update first.

• Restart PHP-FPM afterwards. One of the two bugs lives in long-running workers, and workers started before the upgrade keep running the old code. Run brew services restart php (or [email protected]), and restart Apache too if it loads PHP as a module.
• Check every PHP you have. More than one formula is often installed. brew list --versions | grep php shows them all, and each one needs upgrading and restarting.
• [email protected] has no fix. Homebrew marks it deprecated, at 8.1.34. Move its sites to a supported branch.
• Intel Macs build from source. At the time of writing, Homebrew's ready-made bottles for these releases cover Apple silicon Macs only, so on an Intel Mac the upgrade compiles PHP. That takes a while and needs Apple's command-line tools.

MacPorts: fixed, once you upgrade

MacPorts published the fixed versions on 22 October: php85 8.5.12, php84 8.4.27 and php83 8.3.36. port install leaves a port that is already installed at its old version, so upgrade explicitly:

sudo port selfupdate
sudo port upgrade outdated
sudo port reload php84-fpm

Use the -fpm port that matches your branch. The reload matters for the same reason as on Homebrew. port installed | grep php lists what is there.

MAMP: wait for MAMP

MAMP ships its own PHP builds. They don't come from Homebrew or MacPorts, and they change only when MAMP releases an update. Until it does, put the interim settings in the php.ini MAMP uses for each PHP version you serve, and restart MAMP's servers. If MAMP only serves your own Mac while you develop, the exposure is small. If it serves a website to your network or the internet, treat it like any other server.

Apple's PHP and Server.app: no fix is coming

Old Macs still running Apple's Server.app (the macOS 10.13 era) serve their websites with Apple's PHP 7.1, loaded into Apache as mod_php. That is the worst combination this advisory describes: the highest-risk way of running PHP, on a version too old even for the source backports, which start at 7.4. Apple won't update it. (Macs from macOS 12 on don't include PHP at all.)

The fix is to move the websites to a supported PHP on PHP-FPM, beside Apple's. We described how in Another ten years from the Mac servers you already own: MacPorts PHP 8.5, every site checked before and after, and a switch back if one breaks. FrontierStack's Modernize pane now moves those sites to PHP 8.5.12 or later and refuses anything older. Moving takes the sites off mod_php, the setup the advisory calls the most exposed. If a site can't move yet, ask whether it needs to be public at all: an intranet page only staff use can be limited to the office network or a VPN.

OPNsense and pfSense: PHP on the firewall

Firewalls run PHP too. OPNsense's web GUI is written in PHP and runs as root, and its captive portal serves PHP pages to guest devices, so on a guest network the very devices you are keeping out are the ones talking to it. At the time of writing OPNsense hasn't announced a fix. FreeBSD's ports tree already has the patched PHP (8.3.36, 8.4.27 and 8.5.12), but OPNsense ships PHP in its own firmware packages, and a user on the OPNsense forum noted that 26.1 is still on PHP 8.3.30.

• Update only through OPNsense's firmware updater (System ▸ Firmware ▸ Updates) when the fix ships. Don't install PHP packages on the firewall by hand.
• Until then, keep the web GUI reachable only from trusted networks: not from the WAN, and not from guest or IoT networks.
• If you run the captive portal, watch for OPNsense's announcement especially closely. It is the PHP that untrusted devices reach.

pfSense also uses PHP, served by nginx and php-fpm. Netgate hadn't published an advisory at the time of writing. The same advice applies: update through pfSense's own update mechanism when Netgate ships a fix, and keep the GUI off untrusted networks until then.

Linux servers: check the tracker, not the version number

php.net says Linux distributions and LTS vendors received the patches in advance. Many backport a fix into the PHP version they already ship, so a fixed server can still report a lower number than 8.2.35 or 8.4.27. Look up CVE-2026-109618 and CVE-2026-109619 in your distribution's security tracker rather than comparing versions, and restart PHP-FPM or Apache after the package update.

If you can't update yet

php.net lists settings that reduce exposure to specific attack paths. It says plainly that they don't make an installation safe, so treat them as a bridge to the update, not a substitute for it.

• session.upload_progress.enabled = 0, set in php.ini or the PHP-FPM pool. ini_set() and .user.ini files apply too late, so don't rely on them. Then restart every worker.
• On PHP 8.5, also fatal_error_backtraces = 0, again followed by a restart. php.net says this blocks only the confirmed backtrace path.
• Keep post_max_size small: 8M for sites that take no uploads, 32M for those that do, with upload_max_filesize below it.
• php.net also lists memory_limit = -1, set where applications can't override it, but warns that an allocation failure can still reach the bug. On a Mac with little memory, removing the limit also lets one runaway request take memory from everything else.

What to do today

1. List every machine that serves PHP, and where each PHP came from: Homebrew, MacPorts, MAMP, Apple, a Linux distribution or the firewall's firmware.
2. Homebrew: upgrade each PHP formula, restart PHP-FPM and Apache, and check the version.
3. MacPorts: run sudo port selfupdate, upgrade the PHP ports, reload PHP-FPM and check the version.
4. MAMP: apply the interim settings and restart now, then update MAMP as soon as it ships the fixed PHP.
5. Apple's PHP on Server.app: plan the move to PHP-FPM this week, and until then limit who can reach sites that don't need to be public.
6. Linux: install your distribution's update, confirm both CVEs in its tracker, and restart PHP.
7. Firewalls: keep the OPNsense or pfSense GUI on trusted networks only, and update through the firmware updater when the fix ships.
8. Check what is actually running. php -v shows the command-line PHP, which isn't always the one serving your sites. Confirm the version the web server uses too, and if you use a phpinfo() page for that, delete it straight afterwards.

How FrontierStack helps

FrontierStack doesn't replace any of the steps above. Its next update makes them quicker to find and harder to forget.

• Fleet Run ▸ PHP versions & security fixes is a read-only check across your linked servers. It lists every PHP on each one (Homebrew, MacPorts, MAMP, Apple's own, distribution packages, and OPNsense or pfSense firmware over SSH), shows whether the server serves PHP to the web through php-fpm, php-cgi or mod_php, and compares each with php.net's latest release of its branch. Installs behind a security release, or on a branch that no longer gets fixes, are flagged. FrontierStack doesn't update PHP itself. Copy AI Prompt puts a prompt on the clipboard for Claude Code, the AI Administrator or another agent, which updates PHP from the source each server installed it from, one server at a time, asking you before every change, and checks the vendor's tracker for distribution and firewall packages. See Fleet Run in the manual.
• Modernize Old Mac Server now installs PHP 8.5 and enforces the fix: Install, Switch and Move refuse anything older than 8.5.12, the first PHP 8.5 with these fixes. A server set up earlier on PHP 8.4 gets Move to PHP 8.5, which checks every site before and after and goes straight back if one breaks. The pane also warns the day PHP ships a later security release, even before MacPorts has packaged it. Update PHP 8.5 now upgrades the PHP ports and restarts PHP-FPM; before, running Install again never upgraded a PHP that was already installed. The curl, rsync and OpenSSL update now upgrades too, and the MacPorts installer works on every macOS version MacPorts supports, including macOS 26 and 27. The security checklist marks any website still on Apple's PHP as failing, and the pane lists the MacPorts tools that are out of date on the server. See the Modernize pane in the manual.
• The PHP pane gains a Security check of every PHP on the Mac (Homebrew, MAMP, MacPorts and Apple's own). It flags anything below 8.5.12, or below 8.4.27, 8.3.36 and 8.2.35 on the older branches, marks 8.1 and older as getting no fixes, and names the fix for each.
• Router Health reads the installed PHP version from the firmware package list of an OPNsense firewall linked through its API, and warns when it is behind PHP's latest security release for its branch. The fix itself still comes through OPNsense's firmware. See firewall vitals in the manual.

All three read and report. Changes are made through the source each PHP came from, and only with your approval.

Sources: php.net's advance notice of 20 October and release announcement of 21 October 2026, the two php-src advisories linked above, and the Homebrew, MacPorts and FreeBSD package indexes as checked on 22 October 2026. Package versions change quickly in the days after a release; check them again before you rely on them.