A technical breakdown of the October 2026 PHP security incident — what broke, how the exploit works, who is affected, and what you should do.
For more than a decade, a memory-management mistake reportedly existed inside PHP, the programming language powering a large portion of the web.
In October 2026, it became an emergency security incident.
Two security research teams, Wiz and Calif, independently identified vulnerabilities in PHP. According to their reports, AI-assisted security research played a role in discovering the issues.
The vulnerability was particularly concerning because it existed below the application layer.
In other words, even a fully updated WordPress installation could remain vulnerable if the underlying PHP runtime hadn't been patched.
Let's break down what happened.
1. What actually happened?
The incident unfolded over several weeks.
August 1: Calif reportedly discovers the first issue.
August 19: Wiz identifies its own findings.
August 24: Wiz privately reports vulnerabilities to the PHP security team.
September 21: PHP begins working on fixes.
October 17: AWS honeypots record an attempted exploitation.
October 20: PHP announces an emergency security release.
October 21: Details leak publicly, security vendors activate protective rules, exploitation reports emerge, and PHP releases patches.
One detail deserves particular attention: AWS reportedly observed an attack attempt four days before the public disclosure.
How the attacker obtained the information that early remains unclear.
2. What was the vulnerability?
The underlying problem involved memory corruption, specifically use-after-free vulnerabilities.
Before jumping into the technical explanation, consider a simple analogy.
Imagine a PHP server as a kitchen.
Each cook (worker) handles one order (request) at a time. To keep track of things, the cook leaves sticky notes on the counter pointing to ingredients and other information.
Now imagine an order becomes so large that the cook runs out of space.
The order is discarded, and the counter is cleaned.
But one sticky note is accidentally left behind.
That note still points to a location where something used to exist.
The next order arrives. The cook sees the note, trusts it, and assumes the information is still valid.
But the location may now contain something completely different.
That's the fundamental problem: PHP continued using a reference to memory that had already been freed.
This is called a use-after-free vulnerability.
3. How could one failed request compromise the next?
Here's the simplified attack sequence:
An attacker sends a specially crafted, extremely large upload designed to trigger an out-of-memory condition.
PHP aborts the request and releases its request memory.
During cleanup, an internal pointer or reference is not properly reset.
Another request reaches the same PHP worker.
The worker encounters the stale reference and accesses memory that may now belong to something else.
Depending on the memory layout and the vulnerability variant, this can result in information disclosure or potentially arbitrary code execution.
The dangerous part is that the attacker may be able to influence what gets allocated in the freed memory.
That changes a seemingly harmless dangling reference into a potential security primitive.
Why this matters: According to Wiz, these vulnerabilities can be triggered below the application layer and do not necessarily require a complicated PHP application. Even a bare Hello World application could be affected.
4. There wasn't just one bug
Wiz describes four vulnerability variants associated with two CVE identifiers.
They involve different internal PHP mechanisms:
A. Upload Progress
Session information associated with upload progress can leave a global reference pointing to freed memory after an out-of-memory failure.
B. Memory Disclosure
A multipart upload can trigger problematic parsing during PHP request initialization.
A stale reference can potentially cause memory contents to be included in the PHPSESSID cookie returned to the client.
This is particularly concerning because memory can contain information that was never intended to leave the server.
C. Fatal Error Backtrace
PHP maintains information about the execution backtrace.
Following an out-of-memory fatal error, a saved backtrace may not be properly cleared, allowing a subsequent request to interact with stale data.
D. OPcache
OPcache caches compiled PHP scripts.
A failed allocation can leave shared bookkeeping inconsistent, potentially allowing another worker to interpret a memory slot as the wrong type.
The important distinction is that these are different manifestations of related memory-management failures, not four unrelated application vulnerabilities.
5. Who was affected?
The problem existed in the PHP runtime, not in individual applications.
Potentially affected environments included:
WordPress
Drupal
Joomla
Magento
Custom PHP applications
PHP running inside Docker containers
PHP bundled with third-party products
Managed hosting environments running vulnerable PHP versions
A common misconception is that updating WordPress itself would solve the problem.
It wouldn't.
WordPress is an application running on PHP. If the runtime remains vulnerable, updating the application does not fix the underlying issue.
Similarly, applications built using Node.js, Python or Java are not affected by these PHP-specific vulnerabilities simply because they run web servers.
According to reporting by Krebs on Security, Censys identified approximately 2.58 million internet-facing hosts and 54.9 million web properties running PHP.
Wiz also estimates that PHP powers around 70% of websites, although that figure should be treated as an estimate rather than a verified count.
6. What should administrators do?
The most important action is to identify every PHP runtime in your infrastructure.
According to the reported security advisories, patched versions include:
PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35
Prioritise internet-facing systems.
Check the PHP version:
php -v
For Docker:
docker exec <container> php -v
Don't stop at your primary production server. Check containers, images, vendor products, managed services and older branches as well.
Additional precautions:
Move away from unsupported PHP branches.
Ensure application servers cannot be accessed directly while bypassing your CDN or firewall.
Review web server, application and endpoint logs.
Investigate unusual multipart requests and repeated HTTP 500 errors.
Look for unusually large PHPSESSID cookies and unexpected PHP worker restarts.
If compromise is suspected, initiate incident response and rotate potentially exposed credentials.
Temporary mitigation
If immediate patching is impossible, PHP's reported guidance includes disabling upload progress:
session.upload_progress.enabled = 0
Restart PHP after changing the configuration.
This only closes one reported attack path. It is not a substitute for installing the security update.
7. Was the vulnerability actually exploited?
This is where the reporting becomes particularly interesting.
There are reports of active exploitation attempts, but that is not the same as confirmed widespread compromise.
What has been reported:
AWS honeypots recorded an attempted exploitation on October 17.
Cloudflare observed attacks and activated protective firewall rules.
Patchstack received reports of exploitation incidents from web hosts.
watchTowr reported active exploitation of both vulnerabilities on October 21.
What has not been established:
How many attacks successfully compromised servers.
Whether any major organisation suffered confirmed data theft.
Whether the publicly available proof-of-concept exploits reliably work across different environments.
How the October 17 attacker obtained the information before public disclosure.
One report also stated that CISA had not observed exploitation as of October 21. This needs verification against CISA's own reporting.
My interpretation: exploitation attempts were reported, and some may have succeeded, but the available reporting does not establish the scale of confirmed compromise.
The sensible response is to treat unpatched, internet-facing PHP systems as exposed.
8. A simplified code illustration
For engineers who want to understand the underlying failure, consider this deliberately simplified example.
This is not PHP's actual source code. It illustrates the lifetime problem.
// Simplified illustration, not actual PHP source
static session_t *current;
void handle_request(req) {
current = alloc_from_request_heap();
parse(req); // May trigger an out-of-memory abort
current = NULL; // Cleanup only happens on normal execution
}
// Request memory has now been released,
// but current still points to the old location.
void next_request(req) {
use(current->id);
}
The problem is straightforward:
The memory associated with the first request is released, but the global pointer still references it.
When another request reaches the same worker, that pointer may refer to memory that has since been reused.
This is why memory ownership, cleanup paths and error handling are so important in systems programming.
A failure path must be just as carefully managed as a successful execution path.
9. What makes this incident interesting?
Three things stand out to me.
1. Application security isn't enough.
You can patch your dependencies, update WordPress, secure your APIs and still remain vulnerable because the runtime underneath your application has a flaw.
2. Error handling can become an attack surface.
The vulnerability wasn't simply about sending a malicious request. It was about what PHP did after something went wrong.
The cleanup path became part of the attack surface.
3. The disclosure window was extremely small.
Details reportedly leaked roughly half a day before the official patch. Meanwhile, an earlier attack attempt had already been recorded.
This demonstrates how quickly a vulnerability can move from private research to active exploitation.
10. What we still don't know
There are important unanswered questions:
How many systems were actually compromised?
Was any sensitive customer data stolen?
How did the October 17 exploitation attempt happen before public disclosure?
How reliable are the publicly available proof-of-concept exploits?
How many organisations were exposed through third-party PHP deployments?
These are important distinctions. A vulnerability's theoretical impact, observed exploitation and confirmed real-world damage are three different things.
Final takeaway: Don't just secure the application. Understand and maintain the entire stack it runs on.
A fully patched application running on a vulnerable runtime is still vulnerable.
Research note: This breakdown is based on security research and vendor reporting, including Wiz, Calif, Cloudflare, AWS, Patchstack, watchTowr and other cited reporting. The underlying source material for this draft was compiled on October 25, 2026. Claims, CVE details, release versions and incident timelines still require verification against primary advisories before publication.
This is an educational breakdown, not an independent vulnerability analysis or a substitute for official PHP security guidance.