michael-hettwer.com

Direct Connect

← Back to Blog
·7 min read

PHP & Magento security roundup: September and October 2026

PHPMagentoSecurity

The last eight weeks were unusually dense on the server side: two critical PHP vulnerabilities with unauthenticated remote code execution, a Magento zero-day that was genuinely exploited in the wild, and three Adobe bulletins on top. Because the runtime and the shop software live on the same machines, I am covering both in one article. Period: 1 September to 31 October 2026. Everything below comes from the linked official php.net and Adobe sources.

PHP: security releases for all branches on 24 September

First stop: on 24 September 2026, the PHP team shipped 8.5.11, 8.4.26, 8.3.35 and 8.2.34 as security releases for every maintained 8.x branch. The cycle covers roughly a dozen CVEs; three of them hit classic server setups directly:

  • –CVE-2026-91768 (GHSA-62xp-839h-2637): an IPv6 ACL bypass in PHP-FPM's listen.allowed_clients. The FastCGI check compared only 12 of 16 address bytes; an attacker sharing the same /96 prefix could reach the FPM endpoint. Unix sockets and IPv4-only setups are not affected.
  • –CVE-2026-91769: TLS hostname verification in the OpenSSL extension fell back to the certificate's Common Name after a SAN mismatch — mostly relevant for connections to private PKIs and internal CAs.
  • –CVE-2026-91766: the HTTP stream wrapper forwarded Authorization and Cookie headers unchanged on cross-origin redirects.

Standard procedure after such a round: upgrade, restart your FPM workers, and check php -v on every SAPI — CLI, the FPM pool and, where present, mod_php. Not just in the shell.

PHP: the emergency release on 21 October — two critical RCEs

Ten days later it got serious. PHP announced the emergency release unusually prominently in advance, then shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October 2026 — fixing two critical vulnerabilities, rated 9.2 (CVSS v4.0, oss-security):

  • –CVE-2026-109618 — "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w): an out-of-memory abort can interrupt PHP in the middle of request initialization; during the following cleanup, the partially initialized request state may then be treated as valid.
  • –CVE-2026-109619 — "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp): request-owned state survives the memory-free and can be reused by the next request on the same worker.

Both bugs allow unauthenticated remote code execution before any application code runs. php.net considers the risk highest for Apache with mod_php — a demonstrated exploit exists there — while PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also in scope. And the advisory contains the sentence worth remembering: there are no complete mitigations — updating is the only safe choice. The interim measures it lists (locking down memory_limit so applications cannot override it; keeping post_max_size small; setting session.upload_progress.enabled=0) narrow the attack surface, but they do not replace the update.

The same week brought two additions from PHP: on 23 October an informational advisory for CVE-2026-115560 — an unlikely combination of a serialize-handler change and upload progress as an RCE vector, with the complete fix due in the next regular bugfix release. On 26 October, rebuilt Windows packages appeared (8.5.12-1, 8.4.27-1, 8.3.36-1, 8.2.35-1) bundling Brotli 1.2.1 with the fix for CVE-2026-111497; if you run PHP on Windows, deploy the -1 rebuilds, not the original binaries.

PHP 8.2: end of security support on 31 December

Beyond the current gaps, the deadline is the bigger long-term item: after 31 December 2026, PHP 8.2 stops receiving security fixes, and PHP 8.1 and older have been without releases from the project for a while. The way I read it: every 8.1 or 8.2 inventory needs a scheduled upgrade path to 8.3 or higher now — "after the turn of the year" is not a schedule.

Magento: a zero-day that was exploited (7 September)

On the application layer, the period opened on 7 September 2026 with APSB26-146 and CVE-2026-75650 — an unauthenticated remote code execution in the template engine (CWE-1336) with a CVSS 3.1 score of 10.0. Adobe explicitly confirms the vulnerability was exploited in the wild; under practitioners it goes by the name "StyleSmuggler". The mechanics are uncomfortably simple: insufficiently sanitized GraphQL "styles" template properties let PHP code slip into a file Magento itself writes; rendering a notification template then executes it server-side (CERTVU Advisory 273).

Affected are Adobe Commerce 2.4.4 to 2.4.9 (August 2026 builds and earlier), Adobe Commerce B2B 1.3.3 to 1.5.3, and Magento Open Source 2.4.6 to 2.4.9 — again, August 2026 builds and earlier. The fix is the VULN-39341 hotfix, a composer patch with no version bump; once applied, vendor/bin/magento-patches -n status | grep 39341 reports the "Applied" status (Adobe KB).

Since the observed exploitation began before the fix, any internet-facing shop should be treated as a likely compromise — two work streams: first, check the indicators from Advisory 273 against your logs and filesystem (disguised process names like fc-cache or chronyd in unexpected locations, webshells under pub/media/, files with x_trace_ under var/report/, outbound connections to unknown infrastructure). Second, work through the credential rotation Adobe documents: the encryption key, admin passwords, integration and OAuth tokens, payment gateway credentials, database and Fastly credentials, SSH and deploy keys — rotated at the source, not only inside the shop.

Magento: two further bulletins (8 September and 13 October)

One day after the zero-day came the regular update, APSB26-138 (8 September), with eight vulnerabilities — including two unauthenticated stored-XSS privilege escalation flaws (CVE-2026-76200 and CVE-2026-76201) and a path traversal (CVE-2026-77110). The fixes shipped as the September isolated patch; the bulletin itself reminds you to install the APSB26-146 hotfix in addition.

On 13 October followed APSB26-153 with eleven CVEs for Adobe Commerce, B2B and Magento Open Source on their September 2026 builds and earlier; per Adobe, no exploitation in the wild is known for these. The highest ratings per the bulletin: CVE-2026-103849 (CVSS 10.0, the same CWE-1336 category as the zero-day, no authentication required), CVE-2026-92909 (CVSS 9.8, incorrect authorization, in Adobe Commerce B2B), and the stored-XSS privilege escalations CVE-2026-91013 and CVE-2026-100133 (CVSS 9.3 each). Patching is done via the October isolated patch levels of the branches. And the point Adobe stresses repeatedly (KB): the hotfix for CVE-2026-75650 is not included in the October isolated patch and must be installed in addition.

What I would do now

In practice, PHP and Magento patches usually land in the same maintenance window; so one combined checklist:

1. Inventory: record every PHP SAPI on each server (php -v in CLI, the FPM pool and the mod_php context) and note the Magento build level per shop (e.g. 2.4.7-2026-aug).

2. Update PHP: move to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 or your distribution's backported package, restart all workers, and verify the version on every SAPI. Internet-facing systems first. If an update is still on hold, apply the advisory's mitigations as a reduction — not as a replacement.

3. Patch Magento: apply the October isolated patch for your branches, add the September isolated patch if your line does not include the APSB26-138 fixes, and explicitly install the VULN-39341 hotfix; verify with vendor/bin/magento-patches -n status | grep 39341.

4. Check for compromise: for the window between exploitation beginning and the hotfix, compare logs and filesystem against the Advisory 273 indicators, then work through Adobe's rotation list, and finally flush the cache and redeploy.

5. Calendar hygiene: put the PHP 8.2 end of security support (31 December 2026) into your upgrade plan and keep documenting Magento build levels — it makes the next patch cycle faster.

Final thoughts

Two critical PHP RCEs and an exploited Magento zero-day within eight weeks is a lot. Nothing here required heroics, though: a prepared patch process can absorb it in an evening. The realistic bottleneck sits before that — do you know which PHP versions run on which servers, and which build every shop is on? If yes, October was routine maintenance. If not, the inventory is the actual project — with or without an active CVE.

That last part is my day-to-day as owner of Linux-Server-Admin.com s.r.o.: we manage Linux servers and PHP stacks, keep tested update paths and backups ready, and trigger emergency patches in maintenance windows — alongside the Magento teams on the application layer.

Sources

Questions or feedback regarding this article?

Send Message