PHP Vulnerabilities in 2026: PHP2Shell, Every CVE and the Versions to Run

For most of 2026, PHP security news looked like it always does: monthly point releases fixing memory bugs in SOAP, Phar, OpenSSL and the HTTP stream wrapper, plus a steady stream of framework advisories. Then, on 21 October, the PHP project disclosed two critical bugs in the engine itself. Both let an unauthenticated request run code as the web server's PHP user.

The bugs, nicknamed PHP2Shell, sit below every PHP application. A WordPress, Drupal, Laravel or Symfony site is exposed through the PHP runtime it runs on, and no plugin or framework update can fix that.

This article covers PHP2Shell in detail, then the rest of 2026: the other php-src CVEs, Composer and Laravel, the Laravel-Lang supply-chain attack, and which PHP versions are still supported. If you also run Node.js, Bun or Ruby, we have written the same roundup for Node.js, Bun and Ruby and Rails.

What is PHP2Shell?

PHP2Shell is the name for two critical remote code execution vulnerabilities in PHP: CVE-2026-109618 and CVE-2026-109619. Both are rated CVSS v4.0 9.2 by the PHP project, both are fixed in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, and both were published on 21 October 2026.

They are two different bugs with the same root problem: PHP handling a fatal condition in a way that leaves memory or state behind.

CVE-2026-109618, "RCE via OOM corruption". When PHP runs out of memory it exits with longjmp(). If that happens while request memory is only half initialised, request shutdown later reads and branches on invalid memory. The advisory explains that an attacker can trigger the out-of-memory condition while staying inside apparent limits, using multipart requests:

• requests with no usable Content-Length;
• parts with unlimited headers;
• empty file fields with nested field names.

CVE-2026-109619, "RCE via stale global state". After a fatal error, some global state survives into the next request on the same worker and is used before it is reset. The advisory confirms three paths:

• fatal_error_backtraces on PHP 8.5. The advisory calls this the strongest case, and it is the basis of the confirmed exploit.
• Session upload progress. It is enabled by default and validated against mod_php and FPM.
• INI diagnostics raised before request initialisation. The advisory notes that hiding errors with @, error_reporting or display_errors does not help.

Who is affected by PHP2Shell?

Any PHP installation that serves web requests and runs a version before the fixed releases. That is how CISA's alert puts it, and it includes PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed.

The risk is not equal across server setups. According to the PHP advisories:

Because the bug is in the runtime, the content management system does not matter. Wiz, whose researchers are among those credited, says it demonstrated pre-authentication RCE against WordPress, Drupal and Joomla container images. The fix for all of them is the same: a patched PHP binary.

Is PHP2Shell being exploited?

Exploitation attempts are confirmed; confirmed compromises are not, as of 24 October 2026. The picture from the sources we checked:

• Amazon says its MadPot honeypots recorded a PHP2Shell exploitation attempt on 17 October 2026, four days before public disclosure. It also says public proof-of-concept exploits appeared from about 02:00 UTC on 21 October, and that "it's unclear if any of these attempts would have succeeded in real-world systems" (AWS Security Blog).
• CISA, on 21 October, said it had not observed successful exploitation at the time of publication.
• Singapore's CSA, updated on 23 October, reports "widespread exploitation attempts" and multiple PoCs (CSA alert).
• CISA's Known Exploited Vulnerabilities catalog did not list either CVE as of its 23 October update.

Treat an unpatched, internet-facing PHP server as one that is being probed now. Disclosure windows like this one are why patch speed matters more than the CVSS number.

How do you mitigate PHP2Shell if you cannot patch today?

You cannot fully mitigate it without upgrading. Both advisories say so, and CVE-2026-109619 adds that "no complete generic configuration mitigation exists". The settings below close specific paths while you schedule the upgrade. Set them in php.ini or the FPM pool (php_admin_value), never in .user.ini or with ini_set(), and restart every worker afterwards.

; Closes the session upload-progress path (worth keeping off if you don't use it)
session.upload_progress.enabled = 0

; PHP 8.5 only: closes the strongest CVE-2026-109619 path
fatal_error_backtraces = 0

; Removes PHP's own out-of-memory path (CVE-2026-109618).
; Pair it with a container or cgroup memory.max so the kernel stops a runaway worker instead.
memory_limit = -1

; Keep request sizes conservative (PHP suggests 8M, or 32M if you accept uploads)
post_max_size = 8M

At the web server or proxy, also:

• Bound request bodies: limit decoded body size, input variables, multipart parts and headers per part, including requests with no usable Content-Length.
• Block multipart entirely on hosts whose application does not accept uploads.
• Recycle workers: consider pm.max_requests=1, which limits worker reuse, if your traffic allows it.
• Avoid RLIMIT memory caps: do not use RLIMIT_AS or RLIMIT_DATA. The advisory warns that they trigger the vulnerable longjmp() path.

Then watch for PHP worker processes that start shells or download tools. CISA lists that as the indicator to hunt for.

Which PHP versions are still supported?

PHP 8.2, 8.3, 8.4 and 8.5. PHP 8.1 reached end-of-life on 31 December 2025. PHP 8.2 is in security-only support and reaches end-of-life on 31 December 2026, about two months from now.

Dates are from php.net/supported-versions. PHP 8.6 is at release-candidate stage and not for production. For anything you are upgrading now, we would target PHP 8.4 or 8.5, so you are not repeating the exercise in 2027.

Where do PHP vulnerabilities come from?

In 2026, from every layer of the stack, and the most dangerous ones from the engine itself. Here is where this year's advisories sit.

What other PHP CVEs were fixed in 2026?

Besides PHP2Shell, the regular 2026 security releases fixed dozens of CVEs in php-src. These are the ones with published advisories and confirmed branch coverage:

The 7 May releases (8.2.31, 8.3.31, 8.4.21, 8.5.6) fixed a further batch, listed in the PHP 8 changelog:

• an XSS in the FPM status page (CVE-2026-6735);
• SQL injection in PDO_Firebird (CVE-2025-14179);
• several use-after-free bugs in SOAP.

The pattern is the same as PHP2Shell: memory safety in C code, and helper functions that look safe but are not, like an escaping function in pg_insert() that can be broken out of.

Is CVE-2024-4577 still a risk?

Yes, if you run PHP in CGI mode on Windows. CVE-2024-4577 is a PHP-CGI argument injection that turns certain Windows locales' character conversion into remote code execution. It is fixed in 8.1.29, 8.2.20 and 8.3.8, and it is still in CISA's Known Exploited Vulnerabilities catalog, with known ransomware use. It is two years old and still worth checking, because the affected setups (XAMPP-style Windows servers) are often the ones nobody updates.

What Laravel, Symfony and Composer vulnerabilities were fixed in 2026?

The most serious was in Laravel's API authentication. CVE-2026-114509 (GHSA-f9x3-7vq9-cph6), published 19 October 2026, is a TokenGuard authentication bypass. On MySQL and MariaDB, a crafted non-string API credential can match a different user's record. That means an unauthenticated account takeover on token-guarded routes. It is rated Critical, CVSS v4.0 9.2, and fixed in Laravel 12.68.0 and 13.29.0.

Livewire had no new CVE this year, but an old one became urgent. CVE-2025-54068, an unauthenticated remote command execution in Livewire v3 up to 3.6.3, was added to CISA's Known Exploited Vulnerabilities catalog on 20 March 2026. It is fixed in Livewire 3.6.4. If a Laravel app still runs an older Livewire 3 release, upgrade it before anything else on this list.

Composer had three command-injection CVEs in its Perforce driver:

• CVE-2026-40261 and CVE-2026-40176, 14 April, fixed in 2.9.6 and 2.2.27 LTS.
• CVE-2026-84361, 27 August, fixed in 2.10.3 and 2.2.30.

All three need Perforce source metadata. Packagist.org has refused to publish Perforce source metadata since 10 April, so the risk comes from private repositories, inline package definitions and untrusted lockfiles (Packagist blog, GHSA-rvx4-ffvw-m9q3). Run Composer 2.10.3 or later, or 2.2.30 on the LTS line.

Twig 3.26.0 (20 May) fixed 13 advisories at once, including two Critical code-injection bugs, CVE-2026-46640 and CVE-2026-46633, plus several sandbox bypasses (Symfony blog). This matters most if you let users write templates and rely on the Twig sandbox.

Symfony published three denial-of-service fixes on 15 October 2026:

• CVE-2026-108082: ReDoS in HeaderUtils::split() via Cache-Control.
• CVE-2026-109449: unbounded nesting in the expression parser.
• CVE-2026-109413: unbounded recursion in the YAML inline lexer.

Take the latest patch release of your branch; the Symfony advisories note that the first HeaderUtils fix had to be corrected.

What was the Laravel-Lang supply-chain attack?

On 22 and 23 May 2026, an attacker used a leaked GitHub token to rewrite about 700 historical release tags across the laravel-lang packages. The affected repositories were lang, attributes, http-statuses and actions. The malicious code sat in a src/helpers.php file registered under autoload.files, so it ran on every PHP request, not only at install time. It downloaded a credential stealer. Packagist removed the malicious releases on 23 May (Snyk's analysis).

Two lessons carry over to every PHP project:

• A version number is not proof. Because existing tags were rewritten, a version that looked old and trusted could resolve to new code. A committed composer.lock records the exact commit each package was installed from, which is what protects you from a rewritten tag. A composer update run in that window is what pulled the new code.
• Autoloaded files run on every request. A malicious dependency in PHP does not need an install hook. Treat a new autoload.files entry in a dependency diff as something to read.

If you installed any laravel-lang/* package on 22 or 23 May, rebuild from a clean image and rotate every secret the PHP process could read.

What should you patch first?

1. Upgrade PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 on every server and image, and restart FPM, Apache, FrankenPHP or LiteSpeed. Verify with php -v where the code actually runs.
2. Apply the interim settings above anywhere you cannot upgrade today, and keep session.upload_progress.enabled=0 afterwards if you do not use it.
3. Get off PHP 8.1 and older, and put PHP 8.2's end-of-life on 31 December 2026 in the plan.
4. Upgrade Laravel to 12.68.0 or 13.29.0 if you use token authentication on MySQL or MariaDB, and Livewire to 3.6.4 or later.
5. Upgrade Composer to 2.10.3, Twig to 3.26.0, and Symfony to the latest patch of your branch.
6. Run composer audit in CI, commit composer.lock, and read dependency diffs that add autoloaded files.

Nordbeam builds and maintains web applications. If you are on an end-of-life PHP version and the upgrade keeps slipping, our web development team can help you plan it.