Latest PHP Vulnerabilities (October 2026): CVEs, Affected Versions and How to Fix Them

Short answer: on 22 October 2026 the PHP project shipped 8.2.35, 8.3.36, 8.4.27 and 8.5.12 to fix two critical, unauthenticated remote code execution flaws (GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, CVSS 4.0 score 9.2). If any server, container image or CI runner runs an older PHP 8.x build, upgrading it is the fix. Settings changes reduce the risk but don't remove it.

This guide covers the most recent PHP vulnerabilities from 2025–2026, which versions they affect, which releases fix them, and a practical plan to check, patch and harden your PHP stack. Every advisory ID, CVE and version number below comes from the official PHP 8 ChangeLog and the php-src GitHub security advisories. These are public disclosures by the PHP project and its reporters, not findings of ours.

What changed on 22 October 2026

Two advisories published on 21 October 2026 describe memory-safety bugs in how PHP handles requests. Both are rated Critical (9.2), and both affect every supported branch before the patched release.

GHSA-w8hw-w9fx-j79w: RCE via out-of-memory corruption

PHP uses longjmp() to abort a request when it runs out of memory. In some places, request memory is reachable before it is fully initialised. An out-of-memory (OOM) error at that moment leaves it in an invalid state, and request shutdown then acts on that state. The advisory lists multipart parsing tricks that let an attacker trigger OOM while staying within the request's apparent limits: a body without a usable declared length, unlimited headers per part, and empty file fields that don't count against max_file_uploads.

• Confirmed: full unauthenticated RCE over HTTP against Apache mod_php with default input and memory limits. This happens before any application code runs.
• PHP-FPM: source analysis says it is susceptible, but no complete FPM exploit has been demonstrated. FrankenPHP is described as likely susceptible, and LSAPI as likely with an application-specific trigger.
• Fix: the patch replaces the OOM longjmp() with a graceful "soft OOM" plus a hard _exit() ceiling.

GHSA-6wmf-4rv5-p3rp: RCE via stale global state

Some global state (error, session, object and extension state) can still point to memory owned by a request that has finished. If an earlier request aborts with a fatal error, OOM or timeout before resetting that state, a later request on the same worker can use freed memory before normal initialisation runs. That is a use-after-free that can lead to RCE.

• Confirmed paths: PHP 8.5 with fatal_error_backtraces enabled (RCE on mod_php), and the session upload progress lifecycle (RCE validated on both mod_php and FPM).
• Early "consumers": INI diagnostics raised before request start, for example from .htaccess php_value lines or PHP_VALUE/PHP_ADMIN_VALUE FastCGI parameters. Silencing errors with @ or display_errors=Off does not protect you.

At the time of writing, neither advisory listed a CVE ID, so track them by their GHSA IDs.

All recent PHP security fixes at a glance

Patches are cumulative. Upgrading to the October 2026 release on your branch fixes everything in the table below as well.

September 2026 (8.2.34, 8.3.35, 8.4.26, 8.5.11)

• CVE-2026-91769 (GHSA-vvx9-73fr-5jjx): TLS hostname verification fell back to the certificate CN after a SAN mismatch.
• CVE-2026-91767 (GHSA-xr7j-rvgx-xq5p): heap buffer overflow in OpenSSL wildcard name matching, triggered by a crafted server certificate.
• CVE-2026-91766 (GHSA-fpwc-w8rq-cr92, Moderate): credentials leaked across origins when the HTTP stream wrapper followed redirects.
• CVE-2026-93682 (GHSA-7875-c8px-7q5f, Moderate): out-of-bounds read when a redirect has an empty Location header.
• CVE-2026-91768 (GHSA-62xp-839h-2637, Moderate): IPv6 bypass of the FPM listen.allowed_clients access list.
• CVE-2026-91765 (GHSA-rgrp-mwpx-f6rm, High): unbounded recursion in server-side SOAP XML cleanup.
• CVE-2025-14181 (GHSA-cj93-vc83-wgqv): integer overflow leading to a buffer overflow in SOAP HTTP parsing.
• CVE-2026-6103 (GHSA-j3wh-g957-2m85): integer overflow in Phar TAR parsing that allows archive entry injection.
• CVE-2025-1218 (GHSA-r6x9-5r99-36j7): packet over-reads in the mysqlnd wire protocol.
• CVE-2026-92842 (GHSA-88hq-2827-7pg6): out-of-bounds read in convert.* stream filters.
• CVE-2026-17545 (GHSA-9f67-6fw4-hpfp, Windows only): reserved device names were not rejected before file I/O.

July 2026 (8.2.33, 8.3.33, 8.4.24, 8.5.9)

• CVE-2026-17543 (GHSA-7qpv-r5mr-78m4, High): SQL injection in ext/pgsql through an E'...' backslash breakout.
• CVE-2026-17544 (GHSA-x692-q9x7-8c3f, High): out-of-bounds write in bccomp().
• CVE-2026-7260 (GHSA-vc5h-9ppw-p5f3): Phar crash through recursive symlinks.
• CVE-2026-9672: bundled libgd upgraded.

Earlier in July, 8.2.32, 8.3.32, 8.4.23 and 8.5.8 fixed CVE-2026-14355 (heap corruption in openssl_encrypt() with AES-WRAP-PAD).

May 2026 (8.2.31, 8.3.31, 8.4.21, 8.5.6)

• CVE-2026-6735: XSS in the PHP-FPM status page.
• CVE-2025-14179: SQL injection in PDO_Firebird through NUL bytes in quoted strings.
• CVE-2026-6722, CVE-2026-7261, CVE-2026-7262: SOAP memory-safety bugs, including a use-after-free with SOAP_PERSISTENCE_SESSION.
• CVE-2026-7259, CVE-2026-6104: mbstring null dereference and out-of-bounds access.
• CVE-2026-7568, CVE-2026-7258: integer and ctype issues in the standard library.

Late 2025 (8.5.1 and matching releases on other branches)

• CVE-2025-14178: heap buffer overflow in array_merge().
• CVE-2025-14177: memory information leak in getimagesize().
• CVE-2025-14180: null dereference in PDO quoting.

Step 1: check which PHP versions you actually run

CLI and web PHP are often different builds. Check every runtime: the CLI, PHP-FPM, Apache mod_php, Docker base images and CI.

# CLI version
php -v

# FPM binary (name varies by distro)
php-fpm8.3 -v   # or: php-fpm -v

# Docker images in use
docker run --rm your-image:tag php -r 'echo PHP_VERSION, PHP_EOL;'

# From inside the app (remove after checking)
<?php echo PHP_VERSION;

You are patched against everything in this article if the version is at least 8.2.35, 8.3.36, 8.4.27 or 8.5.12. A PHP version below 8.2 is end of life and does not get these fixes from php.net.

Step 2: upgrade to the patched release

• Docker: bump the base image tag (for example php:8.3-fpm to a build that reports 8.3.36), rebuild without cache, then redeploy. Pin the patch version in CI so you don't silently run an old image.
• Debian/Ubuntu with Ondřej Surý's PPA or sury.org: apt update && apt install --only-upgrade 'php8.3*' once the new package is published.
• Distribution PHP (RHEL, Ubuntu main, Alpine): vendors often backport fixes without changing the upstream version number. Check your vendor's security tracker for the GHSA or CVE rather than relying only on php -v.
• Managed hosting or PaaS: confirm with your provider that the runtime has been rebuilt, and redeploy so new workers pick it up.

Then restart every worker (systemctl restart php8.3-fpm, apachectl graceful). Long-lived workers keep running the old binary until they restart.

Step 3: harden configuration while you patch

These steps come from the advisories themselves. They reduce exposure if you can't patch immediately, and they're good defence in depth afterwards.

; php.ini (startup config), then restart all workers
session.upload_progress.enabled = 0   ; unless you really use it
fatal_error_backtraces = 0            ; PHP 8.5 only, removes a confirmed RCE producer
post_max_size = 8M                     ; keep conservative
max_input_vars = 1000
max_input_nesting_level = 32
max_file_uploads = 20

• Enforce body size at the edge (nginx client_max_body_size, Apache LimitRequestBody). If an app doesn't accept multipart uploads, block multipart/form-data before it reaches PHP.
• Remove per-request INI overrides: audit .htaccess php_value/php_flag lines and any fastcgi_param PHP_VALUE. Move them into php.ini or the FPM pool, and remove deprecated directives that emit warnings.
• Prefer PHP-FPM over mod_php. In the advisories, mod_php was the most exposed SAPI.
• Be careful with memory limits. As a stop-gap for the OOM bug, the advisory suggests administratively setting memory_limit=-1 and bounding memory elsewhere. It also warns not to use RLIMIT_AS/RLIMIT_DATA, because they trigger the vulnerable path. This is a temporary measure that trades RCE risk for resource risk. Patch instead.
• Turn on log_errors with E_ALL and fix recurring fatal errors, timeouts and early-startup warnings. They are the "producers" the stale-state bug relies on.

Step 4: fix the application-level issues too

• pgsql SQL injection (CVE-2026-17543): after patching, use parameterised queries (pg_query_params() or PDO prepared statements) rather than escaped string building.
• HTTP stream redirects (CVE-2026-91766, CVE-2026-93682): if you call file_get_contents() on URLs with auth headers, disable redirect following ('follow_location' => 0) or move to an HTTP client with explicit redirect policies.
• TLS verification (CVE-2026-91769, CVE-2026-91767): keep verify_peer and verify_peer_name enabled. Never "fix" certificate errors by turning them off.
• FPM exposure (CVE-2026-91768, CVE-2026-6735): bind FPM to a Unix socket or localhost, and never expose pm.status_path publicly.
• Uploads and archives: don't open untrusted Phar or TAR files with the phar:// wrapper.

Step 5: verify and keep it from happening again

• Re-run php -v on each runtime and confirm the patched version is live behind the load balancer.
• Add a CI gate that fails builds on PHP versions below your minimum.
• Run composer audit for library vulnerabilities. It covers Composer packages, not the PHP engine, so you need both checks.
• Subscribe to the php.net releases feed and the php-src advisory page so you hear about the next release on day one.

PHP vulnerability fix checklist

• Inventory every PHP runtime (CLI, FPM, mod_php, containers, CI, cron hosts).
• Upgrade to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 or later (or the vendor backport).
• Restart all workers and rebuild all images.
• Disable session.upload_progress if unused. On 8.5, set fatal_error_backtraces=0.
• Enforce request body limits at the proxy, and block multipart where it isn't needed.
• Remove .htaccess and PHP_VALUE INI overrides and deprecated directives.
• Keep FPM private and the status page internal.
• Upgrade off PHP 8.1 and older, which no longer get security fixes.

FAQ

Which PHP version is safe right now?

As of 22 October 2026: PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or any later release on those branches.

Am I affected if I use PHP-FPM with nginx?

Probably, but less directly. Apache mod_php had the confirmed application-independent exploits. For FPM, the advisories show the stale-state RCE through session upload progress, and source analysis supports the OOM bug. Patch either way.

Do these bugs have CVE numbers?

At publication, the two October advisories were tracked by GHSA IDs (GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp). The earlier issues have the CVE IDs listed above.

Is updating Composer packages enough?

No. These are bugs in the PHP interpreter itself. You have to update the PHP binary, not just your vendor/ folder.

I'm on PHP 7.4 or 8.0. What should I do?

Those branches no longer receive official security fixes. Plan a migration to 8.3 or 8.4. If you can't do it immediately, use a vendor with extended support, and apply the configuration mitigations above in the meantime.

Need help patching or upgrading PHP?

CodeSapient builds and maintains PHP and Laravel applications, including version upgrades, Docker image rebuilds and security hardening. If you have legacy PHP that needs to move to a supported branch, talk to our team. You may also like our guides on zero-downtime database migrations and SaaS webhook reliability.