Reviewed on 24 October 2026. A plain-English guide to the October PHP security alerts.
A website can have a carefully designed login screen and still face a security problem underneath it. That is the concern behind PHP2Shell, the name used for two critical flaws in PHP, software that runs many web applications. Under the right conditions, an attacker can make an affected server run code without first logging in. Singapore’s Cyber Security Agency (CSA) identifies the flaws as CVE-2026-109618 and CVE-2026-109619 and rates both at 9.2 out of 10. CSA’s alert
There are fixes. Website owners should have their hosting provider or administrator apply them urgently, then check PHP’s follow-up guidance. For visitors, this is principally a problem on the website’s server; the PHP update belongs there.
What is PHP doing behind a website?
Think of a website as a restaurant. Your browser is the customer placing an order. The server is the kitchen preparing the response. PHP can be part of that kitchen: it runs the instructions that turn a request into a page or another result.
The PHP Foundation says PHP supports services including online stores, government websites and business software. That shared foundation explains why one engine-level flaw can matter across many otherwise unrelated services. The Foundation’s explanation
What went wrong? Two memory mistakes
These bugs concern how PHP manages its working memory and handles interrupted operations. The following analogies simplify the mechanics; they are not literal descriptions of PHP’s code.
1. A cleanup routine trusts unfinished work
In CVE-2026-109618, running out of allowed memory can interrupt an operation while internal data is only partly prepared. PHP’s cleanup can then act on that incomplete data as though it were valid. Researchers demonstrated paths from this memory corruption to remote code execution. PHP’s out-of-memory advisory
Imagine a kitchen stopping halfway through labelling storage boxes. The cleanup team assumes every label is complete and follows instructions it should never have trusted. The security failure comes from using invalid information during recovery, rather than simply running out of space.
2. An old reference survives after its memory is released
In CVE-2026-109619, a PHP worker can retain a reference to memory from an earlier request after that memory has been released. A later request reaching the same worker can use the stale reference before normal initialization replaces it. This is a use-after-free bug. PHP confirms memory disclosure and code execution with the web worker’s privileges. PHP’s stale-state advisory
Think of a cloakroom ticket that still points to a space after its original coat has gone. If that space is reused, trusting the old ticket can produce the wrong result. In software, an attacker may deliberately shape that reuse.
Infographic: from a request to real-world harm
A simplified explanation of possible exploitation. The two bugs are alternative paths; they do not have to happen together. A vulnerable installation is not proof of a successful break-in.
Why the impact can reach beyond a broken page
Remote code execution means an attacker can make the server run instructions of their choosing. Unauthenticated means a valid account is not required. The worker’s permissions shape what those instructions can reach; this does not automatically mean unlimited control of the whole machine. PHP’s impact assessment
The practical consequences could include exposed information accessible to that worker, altered website content, or interrupted service. These are possible consequences of that level of access, not claims that every affected website suffered them. A compromised service could therefore affect customers and staff who never knew PHP was involved.
There is urgency beyond the theoretical risk. In its 23 October update, CSA reported widespread exploitation attempts. Attempts and confirmed compromises are different: that warning does not tell us how many websites were successfully breached. CSA’s updated assessment
What website owners should do
Ask the person responsible for hosting to confirm which PHP installation actually serves the site and whether it contains the fixes. PHP’s 21 October releases were 8.2.35, 8.3.36, 8.4.27 and 8.5.12, for their respective branches. Distribution vendors may supply backported patches, so check the vendor’s advisory as well as the version label. PHP says all installations serving web requests are at risk, with the highest risk assessed for Apache’s mod_php setup. PHP’s update guidance
There is also a follow-up: on 23 October, PHP recommended disabling session.upload_progress.enabled pending its next regular bugfix release for an unusual remaining code-execution path. It requires particular configuration and runtime changes to the session serializer. Administrators should read that advice even after installing the critical updates. PHP’s session upload progress notice
Have the administrator verify the deployed fix and review for signs of compromise. Patching and investigating a possible earlier intrusion are separate jobs. CSA provides monitoring guidance; PHP warns that temporary settings do not provide a complete substitute for updating. CSA’s response guidance PHP’s advisory
For ordinary readers, a useful response is to follow a service’s official security notices. This report alone does not establish that your account or data was exposed.
What this teaches us about software bugs
The wider lesson is that error-handling code needs as much care as the normal path. Here, recovery from an interrupted operation could create another, more dangerous failure.
Maintaining shared software also requires people and time. The PHP Foundation says early signs of the memory problem appeared in 2024, while compatibility trade-offs, limited resources and decision-making delayed a fix. Later reports established concrete code-execution paths. Its account shows why finding a bug and delivering a dependable repair across an ecosystem are distinct challenges. The Foundation’s account
Sources
- PHP: 21 October critical security advisory and release guidance
- PHP: 23 October session upload progress notice
- PHP security advisory: RCE via OOM corruption
- PHP security advisory: RCE via stale global state
- The PHP Foundation: Today’s PHP Security Release, and How We’re Strengthening PHP Security
- Cyber Security Agency of Singapore: Critical Vulnerabilities in PHP (PHP2Shell)
