PHP patches unauthenticated RCE flaws as Foundation admits security handling failures

PHP shipped security releases across four supported branches on October 21, and the PHP Foundation has since admitted that the process behind them fell short. According to a dev.to analysis, the patched vulnerabilities could, under certain conditions, allow remote code execution without authentication, and the project's handling of the underlying reports stretches back to 2024.

What the October 21 releases fixed

The updates — PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 — close two flaws tracked as CVE-2026-109618 and CVE-2026-109619. The dev.to post reports that, under the relevant conditions, the bugs permit unauthenticated remote code execution, and that the official advisory urges all users to update. Anyone running an affected branch should treat this as an urgent patch rather than an optional housekeeping step.

A second vector disclosed on October 23

Two days later, the project published a follow-up notice. As the dev.to write-up describes it, the notice covers an additional and unlikely remote code execution path that combines session upload progress with a particular runtime change to the session serialization handler. Temporary mitigation guidance was issued while users wait for the next regular bugfix release, and the author advises administrators to read that notice alongside the October 21 advisory rather than assume the original update settled the matter.

Why the fix took so long

The most consequential part of the episode is the Foundation's own accounting. Per the dev.to post, the first signs of the out-of-memory issue were found in 2024, and the Foundation attributes the delay to a structural breakdown in decision-making compounded by insufficient resources, not to a single technical misstep. Changes are reportedly under way in how the security team makes decisions, with the stated goals of resolving difficult cases sooner and involving Foundation leadership earlier whenever work stalls.

The language and ecosystem keep moving

The security news lands against a backdrop of steady development. According to the dev.to analysis, PHP 8.4 delivered property hooks, asymmetric visibility and native lazy objects, while PHP 8.5 added a built-in URI extension, the pipe operator and new behaviour for modifying properties when cloning objects. Under the project's support policy, PHP 8.5 is scheduled for active support through December 2027 and security support through December 2029.

The frameworks are tracking the runtime: Symfony 8.1, released in May 2026, requires PHP 8.4 or later, while Symfony 7.4 LTS has security support scheduled through November 2029; Laravel 13 arrived in March 2026 with a published support schedule. The stakes extend well beyond framework users. MediaWiki, which powers Wikipedia, is written in PHP, WordPress requires it, and Adobe Commerce publishes supported PHP versions in its system requirements.

Behind that maintenance is a small paid team. The PHP Foundation's 2025 Impact and Transparency Report, cited in the post, counted 11 contracted developers working full-time or part-time at the end of the year, handling bug fixes, security fixes and language development alongside community contributions.

Investment was already under way

Some of the remediation predates the October disclosures. In May 2026, the Foundation announced an Ecosystem Security Team backed by an Alpha-Omega grant to help with security reports, coordination and work across the PHP ecosystem. The dev.to author argues that the next step is durability: fixes blocked by hard technical trade-offs need a clear owner, stalled decisions need escalation, and sustained funding needs to translate into engineer time for investigating, implementing and reviewing fixes. Those, the author suggests, are the benchmarks against which the promised reforms should be judged.

Why it matters

Two vulnerabilities enabling unauthenticated remote code execution in a runtime that powers Wikipedia, WordPress and a large share of commercial sites would be significant on their own. What makes this story worth tracking is the admission that the underlying issue sat unresolved since 2024 because of process and resourcing failures rather than technical impossibility. The Foundation has named the problem and pointed at structural fixes — earlier leadership involvement, clearer ownership of decisions and a funded ecosystem security team — but the October 23 follow-up, which surfaced a second attack vector days after the original patch, shows how much work follows a security release. For teams that depend on PHP, the practical takeaways are immediate: apply the October 21 releases, check the October 23 mitigation guidance, and watch whether the promised process changes actually hold.