On October 21, 2026 the PHP project shipped emergency releases for two critical remote-code-execution bugs in the language runtime itself. The headline most outlets chose is "AI found it". The more useful part is what the PHP Foundation says about why it took so long to fix.
What happened (facts)
- Releases. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, per the php.net advisory. PHP says there are no complete mitigations: updating is the only safe choice.
- The bugs. CVE-2026-109618 (out-of-memory corruption) and CVE-2026-109619 (stale global state after a fatal error). Both are rated CVSS v4.0 9.2 and can allow unauthenticated remote code execution, according to CERT-EU.
- Who is affected. Per AWS's bulletin, 8.5.0-8.5.11, 8.4.0-8.4.26, 8.3.0-8.3.35 and 8.2.0-8.2.34. PHP 8.1 and older get no official release; the PHP security team published minimal source backports for 7.4 to 8.1.
- Disclosure went wrong. The CVE IDs leaked on October 20, the release was pulled forward a day, a researcher firm published a proof-of-concept video, and a distributor published patched images before the embargo ended, per the PHP Foundation.
Why people care
PHP sits in WordPress, Laravel and a great many business sites. The Foundation says one of the bugs could be triggered on Apache with mod_php before any application code runs, so a perfectly written app is still exposed. Amazon Threat Intelligence reportedly saw an exploitation attempt on October 17, per Tenable. OpenAI says its GPT-5.6 Sol model helped the researchers, in its disclosure post.
What the coverage is missing
1. The bug was not new, the decision was stuck. The Foundation writes that the first signs of the out-of-memory problem were found in 2024. Several fixes existed, each with a trade-off: broken compatibility, new denial-of-service risk, or changes to many third-party extensions. The team "struggled to choose" and calls the delay "a structural failure". AI did not find a hidden bug here; it proved the impact, which forced the decision.
2. The fix is the hard part, and it is still human. The Foundation says tools find bugs faster for defenders and attackers alike, and that a person makes every call and works on every patch. Reports are rising: 15 CVEs since July 1 and more than 100 invalid or duplicate reports.
3. Your version is probably not the one you think. The risk sits in containers, base images, shared hosting and old agency builds, not only in the server you patched last.
Prediction, labeled
My read, not a fact: expect more AI-assisted disclosures to land on long-standing, "known but hard" bugs, because proof of impact is now cheap. Maintainer time and funding will matter more than detection.
What to do today
php -v # on the host
docker run --rm IMAGE php -v # inside each image you ship
Confirm you are on 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later, then rebuild images that pin an older tag. If you run 8.1 or older, plan the upgrade; do not rely on the backport branches as a long-term answer.
Sources
- PHP security advisory: https://www.php.net/archive/2026.php#2026-10-21-5
- PHP Foundation post: https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
- OpenAI disclosure: https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/
- AWS bulletin: https://aws.amazon.com/security/security-bulletins/2026-143-aws/
- CERT-EU advisory: https://cert.europa.eu/publications/security-advisories/2026-018
Written with AI assistance and checked against the sources above.
Top comments (1)
Good framing. "Stuck decision, not missing detection" matches what I have seen in smaller projects too: the known-but-hard bugs sit in the tracker because every fix breaks someone.
Your advice to check versions inside images and not just on hosts is the part I would underline. Moving to 8.4.27 took minutes. The longer part was finding every PHP that was actually installed, including an older one nobody used on purpose.