Following the public disclosure of PHP2Shell (CVE-2026-109618 and CVE-2026-109619), Imperva Threat Research observed a sharp increase in scanning and exploitation attempts across protected environments. What had been a small number of unsuccessful probes before disclosure quickly grew into widespread automated activity targeting sites across industries and regions.
Before public disclosure, Imperva participated in the coordinated disclosure process with Wiz, OpenAI, and Calif. The researchers shared confidential vulnerability details, enabling us to assess existing protections, develop dedicated detection and mitigation rules, and prepare diagnostic testing against proof-of-concept exploits.
Our involvement began with a confidential briefing from Wiz on October 12. We deployed dedicated monitoring rules that same day and refined them as our analysis progressed. When PHP announced the lifting of the embargo on October 21 at 13:38 UTC, Imperva immediately enabled the full set of PHP2Shell protection rules. Existing protections had already covered the early probing attempts.
Below, we trace the disclosure and attack timeline, then examine the scale, targeting, and client behavior observed during the first 24 hours of activity.
The First 24 Hours in Numbers
During the first 24 hours of observed activity, Imperva recorded:
482,342 requests
122,311 attack sessions
21,998 targeted sites
103 targeted countries
The activity was broad but relatively shallow: each attack session contained approximately 3.9 requests, and targeted sites received an average of nearly 22 requests during the observation period. This pattern is consistent with opportunistic spray-and-pray scanning, in which attackers probe many sites for potentially vulnerable deployments.
These figures describe observed traffic and targeting. They do not represent confirmed successful exploitation or compromised sites.
How the Activity Developed
The aggregate figures show the scale of targeting, while the hourly distribution shows how quickly activity intensified. The chart below traces observed request volumes alongside key disclosure and patch-release milestones.
Figure 1: PHP2Shell-associated requests by hour, with disclosure and patch-release milestones. All times are UTC.
Following the initial increase, request volume rose sharply and reached a pronounced peak before declining. Activity continued after the peak, with several smaller spikes during the remaining observation period.
This pattern is consistent with an initial burst of automated scanning and exploitation attempts followed by continued activity at lower volumes. The timing alone does not establish what triggered each spike or whether the requests came from the same tools or actors.
Targeting Concentrated in the United States
Sites in the United States accounted for 64.5% of targeted sites, making it the clear center of the observed activity. Indonesia was the second-most targeted country, followed by Australia, Germany, and the Brazil.
Despite this concentration, associated activity reached sites across 103 countries within 24 hours. The geographic distribution shows how quickly scanning and exploitation attempts spread beyond a single region once vulnerability details became public.
These percentages reflect the distribution of targeted sites within Imperva’s observations. They do not, by themselves, establish a deliberate attacker preference for particular countries.
Education and Financial Services Lead Industry Targeting
The activity reached organizations across a wide range of industries. Business accounted for the largest share of targeted sites at 34.3%, followed by Education and Financial Services.
The distribution shows that targeting was not limited to sectors traditionally associated with high-value financial or government data. Instead, activity extended across industries likely to operate large or publicly accessible PHP environments.
Automation Drives Early Activity
The clients associated with the traffic further support an assessment of heavily automated activity. Almost half of the observed activity came from clients classified as browser impersonators, which present themselves as legitimate browsers. Most of the remaining activity was split between known bots and clients using the Go HTTP library.
The prominence of browser impersonation suggests that many of the tools generating this traffic were designed to blend into normal web activity. At the same time, the substantial use of Go-based clients is consistent with purpose-built, high-speed tooling used to scan large numbers of targets.
Imperva Customers Remain Protected
As detailed in our initial analysis, Imperva Cloud WAF customers are protected against PHP2Shell out of the box. Elastic WAF customers receive protection following the applicable software update. WAF Gateway customers receive protection following the applicable software and ADC security-content updates.
Existing protections covered the early unsuccessful probing attempts. Imperva also developed and refined dedicated PHP2Shell rules before public disclosure, enabling the full set immediately after the embargo was lifted.
Organizations should apply the relevant PHP security updates to remediate affected deployments. WAF protections provide a compensating control while that remediation takes place.
Imperva Threat Research continues to monitor PHP2Shell activity and refine protections as scanning tools, exploitation techniques, and attacker behavior evolve. These findings capture the first 24 hours of observed activity; the volume and distribution may change as further activity emerges.
A family of runtime memory safety vulnerabilities, with impacts ranging from worker crashes and data disclosure to pre-authentication remote code execution.
Introduction
Researchers from Wiz, OpenAI, and Calif jointly disclosed PHP2Shell (CVE-2026-109618 and CVE-2026-109619), a set of memory safety vulnerabilities involving PHP’s session handling, OPcache class caching, and fatal-error backtrace generation. Successful exploitation can lead to full remote code execution in the affected PHP environment without authentication or user interaction. Other demonstrated effects include worker crashes, arbitrary file reads, and server-memory disclosure.
When we think about memory-corruption vulnerabilities, we often picture bugs buried in complex application code. PHP2Shell is different: the vulnerabilities live in PHP’s own runtime, and several can be reached without the application itself doing anything wrong. In many cases, PHP2Shell exploits the timing of PHP’s response to memory exhaustion. Processing stops, but internal state is not always cleaned up consistently. Pointers or cache entries left behind can become accessible during subsequent processing, turning a failed operation into an opportunity for exploitation. In the session-related attacks the researchers demonstrated, an endpoint that does nothing more than echo “OK” can still be affected. The vulnerable processing happens before a single line of application code runs.
PHP2Shell is believed to affect PHP versions dating back to PHP 5.4.0, although not every release has been individually tested and verified. With PHP used by over 69% of websites whose server-side programming language is known, the potential exposure is substantial. Organizations should consult the relevant security advisories for confirmed affected ranges and apply vendor-provided fixes as soon as possible.
CVE Overview
PHP2Shell encompasses two reported vulnerabilities involving PHP’s handling of abnormal request termination. Both are classified as CWE-824: Access of Uninitialized Pointer, carry a CVSS v4.0 score of 9.2 (Critical), and can lead to remote code execution without authentication or user interaction.
CVE-2026-109618: Remote Code Execution via Memory Exhaustion
PHP useslongjmp()to abort request processing when an out-of-memory (OOM) error occurs. Some execution contexts do not properly account for this interruption, leaving request memory in an uninitialized state. Subsequent request cleanup may read or branch on that memory. Multiple strategies for triggering memory exhaustion can consistently reach this condition and lead to remote code execution.
Reported by: Calif, Wiz, OpenAI, and Quarkslab.
CVE-2026-109619: Remote Code Execution via Fatal Errors
PHP also useslongjmp()to abort request processing following fatal errors. Some execution contexts leave global state pointing to memory that is freed at the end of the request. Subsequent requests may read or branch on this invalid state, potentially leading to remote code execution through multiple triggering strategies.
Reported by: Wiz, Calif, and OpenAI.
It’s worth noting that the attack complexity in both vulnerabilities is high, which means that the attacker must overcome a built-in security protection for the exploit to work. Triggering the bug is much easier than turning it into code execution. Memory exhaustion can leave PHP holding a pointer to freed memory. A later request must reach the same Apache worker and place carefully shaped data into that freed space. If the timing or placement differs, the worker may crash or respond normally instead of executing a command.
The Common Thread: Bailouts Leave Stale State
PHP handles certain fatal conditions, including exceeding its configured memory_limit, through an internal mechanism known as a bailout. Rather than completing the current operation normally, PHP aborts it and transfers control to an error-handling boundary.
The problem arises when that bailout occurs after PHP has published a pointer or allocated a cache slot, but before the corresponding cleanup or completion bookkeeping runs. The result is a partially initialized, or stale, state that remains accessible after the operation has failed.
In worker-based deployments, including Apache prefork environment, a process can serve multiple requests. A subsequent request reaching the same worker may therefore encounter a pointer to memory that an earlier request has already freed.
The OPcache finding involves a related but distinct problem: an abandoned class-cache slot in shared memory. Worker-local state and shared-cache state have different lifetimes, so the conditions required to exploit each finding must be assessed separately.
Reaching the Runtime Before Application Code Runs
Three of the five demonstrated exploitation techniques use PHP’s session upload-progress feature as a remote trigger.
This feature updates session state while PHP parses a multipart request body, before the application begins executing. Crafted multipart requests can therefore influence session processing and memory consumption during this pre-application phase.
In these attacks, memory exhaustion interrupts session processing at a point where cleanup is incomplete. Later processing on the same worker encounters the stale state, resulting in a crash or memory disclosure.
This explains why an application does not necessarily need to implement vulnerable business logic to be exposed. However, it does not mean every finding affects every PHP endpoint: enabled features, application behavior, worker routing, and deployment configuration still matter.
Exploitation Techniques
Session Decoder Use-After-Free
The session decoder finding involves bookkeeping used during session unserialization. PHP makes that bookkeeping accessible through module globals, but memory exhaustion can interrupt processing before it is properly cleared.
The attack first builds a large session through the upload-progress mechanism, then forces memory exhaustion during session decoding. Request cleanup frees the underlying memory while leaving stale bookkeeping accessible.
A subsequent request reaching the same worker uses the dangling context, resulting in invalid memory access and a worker crash.
OPcache Stale Class-Cache Pointer
The OPcache finding affects the persistence of compiled class information into shared memory. A memory bailout at a particular point leaves an allocated but unpublished class-cache slot behind.
The attack manipulates later cache reuse and places crafted structures in request memory. A stale class lookup then interprets attacker-controlled data as PHP internal structures, influencing class constant resolution.
In an application flow, a file operation using the affected constant is redirected to an attacker-selected path. This produces an arbitrary file read within the worker process’s access permissions.
The practical consequences depend on what that process can read. Application configuration files, database credentials, API keys, and other secrets may be exposed, but the finding does not automatically grant access to every file on the host.
Stale Session Module-data Pointer – Use-After-Free
This finding affects the session handler state referenced by PHP’s internal pointer.
Memory exhaustion during session handling leaves the pointer referring to freed memory. A follow-up request on the same worker influences subsequent memory allocation, and PHP later dereferences the stale pointer.
Such an attack can produce a worker crash, demonstrating that invalid session state can remain reachable across requests.
Stale Session-ID Pointer – Memory Disclosure
The session ID finding follows a similar pattern but produces information disclosure rather than a crash.
After memory exhaustion leaves stale session ID state, attacker-influenced memory is interpreted as a string with an oversized length. PHP then returns the resulting value through a Set-Cookie: PHPSESSID response header.
An attack can expose approximately 67 KB of process memory. Its contents depend on the worker’s state at the time of exploitation and may include internal runtime data or sensitive information processed by the application.
Fatal-Error Backtrace – Use-After-Free
With fatal-error backtraces enabled, a fatal error can trigger a use-after-free during backtrace generation. The effect is a worker crash.
This finding should be distinguished from the session upload-progress attacks. It requires the relevant backtrace setting and a fatal-error trigger; it does not share the same remote prerequisites as the three session findings.
From Memory Corruption to Remote Code Execution
The overall impact of PHP2Shell extends beyond service disruption and data disclosure. Successful exploitation can lead to remote code execution in the affected PHP environment.
The individual findings demonstrate different ways that invalid runtime state can be accessed or influenced. Their standalone effects should be distinguished from the complete code-execution outcome.
Code execution occurs within the security context of the compromised process. It does not automatically imply root access, but it can allow an attacker to access application data, modify resources available to that process, and pursue further compromise.
Mitigation and Detection
Applying vendor-confirmed PHP fixes is the primary remediation. Organizations should consult the relevant security advisories for confirmed affected ranges, fixed releases, and vulnerability-specific guidance.
Where patching is delayed, organizations should assess temporary exposure-reduction measures:
Disable relevant PHP features where practical. After compatibility and performance testing, consider applying the following settings in the active php.ini file. These temporary measures target features used by the demonstrated exploitation techniques and should not be treated as complete workarounds for either CVE.
opcache.enable = 0
session.upload_progress.enabled = 0
These settings disable OPcache and session upload-progress tracking, respectively. Disabling session upload-progress tracking removes the described trigger for three of the five reported exploitation techniques. These measures do not replace patching or establish that the environment is fully protected.
Review fatal-error backtrace configuration. Assess whether the relevant setting is enabled and follow vulnerability-specific guidance.
Restrict exposure where practical. Limit access to affected services while remediation is evaluated and deployed.
Apply least privilege. Restrict the PHP process’s access to files, credentials, and connected services to reduce the consequences of compromise.
Security teams should correlate suspicious request activity with PHP memory-exhaustion errors and worker crashes. Investigation leads include unusually large multipart payloads, excessive field counts, anomalous session-related parameters, and unexpectedly large PHPSESSID response values.
If exploitation is suspected, incident response should assess possible code execution as well as data disclosure. Review unexpected child processes, application-file changes, persistence mechanisms, unusual outbound connections, and potential credential exposure.
Imperva’s Response and Customer Protection
The researchers shared vulnerability details confidentially with Imperva ahead of public disclosure, enabling Imperva to verify its protection and begin monitoring customer traffic before the announcement. During this pre-disclosure monitoring period, Imperva observed no traffic matching the monitored PHP2Shell exploit patterns.
Imperva Web Application Firewall provides a compensating control by inspecting request and response patterns associated with the demonstrated exploits, including anomalous multipart payloads, repeated session-related fields, abnormal response headers and suspicious session upload-progress activity.
Imperva WAF solutions provide a virtual patch to organizations – Cloud WAF customers are protected against this vulnerability out of the box. Elastic WAF customers receive the same protection following a software update. WAF Gateway customers are protected following a software update and an ADC security content update.
For more details, refer to the relevant release notes:
Imperva provides a testing page where customers can enter their URL to receive an initial assessment. The result is preliminary and may require further analysis to confirm exposure.
Imperva’s Threat Research team continues to monitor traffic to determine whether additional protections are needed.
Conclusion
PHP2Shell highlights how a runtime’s handling of exceptional conditions can become a security boundary failure. When processing stops at the wrong moment, stale pointers and incomplete cache state can remain accessible beyond the operation that created them.
The resulting impacts range from worker crashes and sensitive data disclosure to pre-authentication remote code execution. Organizations should identify affected deployments, apply vendor-confirmed fixes, reduce unnecessary exposure, and investigate suspicious activity for signs of both data access and code execution.
The recent buzz around Anthropic’s Mythos model has been intense, and for good reason. Early reports suggest a model that significantly advances automated reasoning over large codebases, vulnerability discovery, and exploit generation. Some are already calling it a “game changer” for offensive security.
But like most breakthroughs in AI, the reality is more nuanced.
Let’s unpack what Mythos is, why it’s getting so much attention, and where the real impact will (and won’t) be.
What Is Mythos, and Why It Matters
At its core, Mythos is designed to operate deeply within software systems:
It can reason across entire codebases, not just snippets
It demonstrates strong capabilities in multi-step vulnerability discovery
It can potentially chain findings into realistic exploit paths
This is what sets it apart from earlier models. Traditional LLMs often struggled with:
Context fragmentation (limited memory of large systems)
Superficial pattern matching (vs. true reasoning)
Weakness in multi-stage attack logic
Mythos appears to push beyond that, closer to what human security researchers do when analyzing complex systems.
That’s the hype. Now let’s put it into perspective.
1. Closed Systems Still Have a Natural Advantage
One of the most important constraints, often overlooked, is access.
Organizations running:
Licensed binaries
Closed-source products
SaaS platforms
are inherently less exposed to this class of AI-driven analysis.
Why? Because Mythos appears to be most effective when it has full visibility into the source code. Without that:
Reverse engineering binaries is still hard and lossy
SaaS environments expose only interfaces, not logic
This creates a natural barrier for attackers.
Although “security through obscurity” isn’t a solution, in practice:
Open-source projects and exposed codebases will feel the impact first
Closed vendors still need to worry, but they’re not suddenly transparent overnight
2. The Real Pressure Point: Time-to-Mitigation
AI doesn’t just change what attackers can do, it changes how fast everything happens.
And this is where security vendors feel the most pressure. The challenge isn’t whether vulnerabilities exist, it’s how fast vendors can respond once they’re discovered.
The new race:
AI/ human finds vulnerability →
AI Exploit is generated quickly →
Attack traffic emerges earlier →
Defenses must adapt in near real-time.
This shifts the competitive advantage to vendors that can:
Automate security workflows to
Rapidly understand new attack patterns
Generate mitigations
Deploy protections before mass exploitation
3. The Budget Reality: AI Red-Teaming Isn’t Cheap
One of the least discussed aspects of Mythos is cost.
Running such a model at scale involves:
High compute costs
Expensive infrastructure
For example, Anthropic admitted that “Across a thousand runs through our scaffold, the total cost was under $20,000” for finding vulnerabilities in OpenBSD.
Significant human validation effort
And that last part is critical.
Every finding still requires:
Verification (is it real?)
Reproduction
Impact assessment
Which means more security engineers per finding, not less.
Organizations will need to start budgeting for:
AI-assisted red teaming
Dedicated pipelines to process findings
Integration into SDLC workflows
This mirrors what we’ve already seen with GitHub Copilot-style assistants and AI-based code analysis tools.
Implication for attackers:
These “doomsday” capabilities are not evenly distributed.
Otherwise, teams risk wasting cycles on low-quality reports and missing real vulnerabilities buried in noise. Ironically, AI will be needed to defend against AI-generated reports.
5. Not All Vulnerabilities Are Equal
Another important nuance:
Finding a vulnerability ≠ exploiting it at scale.
Even with Mythos:
Many findings will be low impact
Exploitation may require environment specific conditions
Real-world constraints (auth, rate limits, monitoring) still apply
This is where traditional security layers still matter:
WAF, API protection, Bot protection
Identity protection
Data protection
Threat reputation
Mythos increases discovery capability, but doesn’t eliminate defense in depth.
Final Thoughts
The Mythos model presents a meaningful step forward. It brings AI closer to acting like a real security researcher, capable of deep reasoning and complex analysis.
But it’s not a universal “break everything” button.
Closed systems still provide friction
Costs limit widespread misuse
Defensive technologies remain highly relevant
Operational processes (triage, mitigation) become the real bottleneck
The hype focuses on capability. The reality is about constraints and execution.
And as always in cybersecurity, the winners won’t be those with the best tools, but those who can operationalize speed, from detection to mitigation, at scale.
Login
