A WordPress dashboard can report that every plugin, theme and core file is up to date while the server underneath remains vulnerable. That is the central problem with PHP2Shell: the weakness is in PHP itself, in code that processes an incoming request before WordPress has an opportunity to handle it.
Two flaws, CVE-2026-109618 and CVE-2026-109619, were disclosed on 21 October 2026. Both have a CVSS v4.0 score of 9.2 (Critical). On 26 October, CISA added both to its Known Exploited Vulnerabilities (KEV) catalogue. This is no longer a question of whether attackers might try: exploitation has been reported in the wild, although success still depends on the server’s configuration and build.
Quick answer: Updating WordPress, a theme or a security plugin does not fix PHP2Shell. The server owner or hosting provider must deploy a patched PHP runtime (or a vendor-confirmed backport), restart the affected PHP workers and check for signs of compromise. A WordPress security scanner is useful for investigating what an attacker may have left behind; it cannot, by itself, certify the PHP engine as fixed.
The Essentials in 60 Seconds
- Two vulnerabilities, one lower layer. PHP’s out-of-memory processing and request-state handling can, under exploitable conditions, lead to remote code execution without a WordPress login.
- The initial fixed upstream versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Older supported-branch versions need updating; PHP 8.1 and older need a supported-branch migration or a specifically verified vendor backport.
- Active exploitation is confirmed. Both CVEs entered CISA’s KEV catalogue on 26 October 2026. The risk is real even though an exploit that works on one configuration may fail on another.
- A third issue needs separate attention. CVE-2026-115560, described by PHP on 23 October, has an unusual session-configuration prerequisite and was not fixed by the 21 October releases. PHP advises disabling session upload progress until its next bug-fix release where appropriate.
- Detection and remediation are different jobs. Guardian Gaze for WordPress can surface suspicious code, file changes and injected database content; PHP patch validation belongs with the host or server administrator.
What Happened: The Timeline That Matters
| Date | Development | Why it matters |
| 21 October 2026 | PHP released fixes for CVE-2026-109618 and CVE-2026-109619 and published technical advisories. | An upstream patch became available for supported PHP branches. |
| 23 October 2026 | PHP described a separate session upload progress issue, CVE-2026-115560. | A residual, configuration-dependent path needed its own mitigation. |
| 26 October 2026 | CISA added both PHP2Shell CVEs to the KEV catalogue. | Evidence of in-the-wild exploitation changed patching from urgent to immediate. |
| 27–29 October 2026 | National cyber authorities and vendors updated their alerts to reflect exploitation. | Defenders gained stronger grounds for retrospective log review and incident triage. |
The PHP security team, NHS England cyber alert and Microsoft Security Response Centre update support the chronology. The dates matter because an organisation that patched on disclosure day still needs to ask what happened before the update was applied.
How the two PHP2Shell vulnerabilities work
Both flaws affect PHP’s management of request memory, rather than a WordPress feature such as the login page, REST API or media library.
| Vulnerability | What goes wrong | Potential impact |
| CVE-2026-109618 — out-of-memory corruption | During certain memory-allocation failures, PHP can abort an operation while request data is only partly initialised. Later cleanup may interpret that invalid state as usable data. | A carefully controlled failure may produce remote code execution or a process crash. |
| CVE-2026-109619 — stale global state | A long-running PHP worker can retain references to memory from a completed request. A later request may touch that memory before the state is reset. | Under the necessary producer-and-consumer conditions, a use-after-free condition may be exploitable for remote code execution. |
The original advisories give the detailed mechanics: GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp. A CVSS score of 9.2 describes the severity of a successful compromise; it does not mean exploitation works reliably against every PHP deployment.
Why WordPress Is Affected Even When It Is Fully Patched
An incoming request normally passes through three distinct layers:
| Layer | Main responsibility | Where to fix it |
| Web server / reverse proxy | Accepts and routes HTTP requests. | Hosting provider, infrastructure team or server administrator. |
| PHP runtime | Parses request bodies, manages sessions and memory, and executes PHP scripts. This is the vulnerable layer. | Update PHP or install the vendor’s confirmed backported package. |
| WordPress application | Runs core functionality, plugins and themes after PHP has started processing. | Update WordPress and its components for their own vulnerabilities. |
Some of the demonstrated PHP2Shell paths are reached while PHP is parsing a multipart form request, before normal WordPress code executes. A site does not need to offer a visible upload form for the engine to receive such a request. That also means a WordPress-level plugin or firewall should not be advertised as a reliable substitute for patching an engine-level flaw.
Does The Web Server Configuration Affect Exploitability?
Yes. The PHP project assesses the highest demonstrated risk for Apache with mod_php, where it validated unauthenticated exploitation under normal conditions. PHP-FPM, often deployed behind Nginx, has different worker behaviour and some paths require particular frontend or configuration conditions. FrankenPHP, LiteSpeed/LSAPI and other PHP integrations must also be assessed; absence of a universal public exploit is not proof that a configuration is unaffected.
This distinction should guide investigation, not delay remediation. Teams need to record the PHP version, the actual web-facing PHP handler, relevant vendor package builds and whether updated workers are running.
Which PHP Versions Fix PHP2Shell?
The initial upstream fixes published on 21 October are:
| PHP branch | First fixed upstream release | Operational note |
| PHP 8.5 | 8.5.12 | Update and restart the serving workers. |
| PHP 8.4 | 8.4.27 | Update and restart the serving workers. |
| PHP 8.3 | 8.3.36 | Update and restart the serving workers. |
| PHP 8.2 | 8.2.35 | Update now; plan migration before 8.2 security support ends on 31 December 2026. |
| PHP 8.1 and older | No ordinary upstream supported-branch release | Move to a supported branch or verify a vendor-supplied backport against both CVEs. |
Do not rely on the version string alone. Debian, Ubuntu, hosting control panels and long-term-support suppliers may backport a security fix while retaining an older upstream version number. Conversely, a patched package on disk does not mean existing PHP-FPM or Apache processes have loaded it. Check the vendor security advisory and the running service. Containers need rebuilding and redeployment with fixed images.
A Practical Response Plan For WordPress Owners And Security Teams
1. Establish Who Controls The PHP Layer
For managed or shared hosting, ask the provider to confirm both CVE identifiers, the package or PHP runtime currently serving your site, the patch deployment date and whether its workers have restarted. A generic reply that ‘WordPress is updated’ is insufficient.
For a VPS, dedicated server, cloud VM or container, assign the task to the system administrator or DevOps team. Include staging sites, forgotten subdomains, secondary WordPress installations and any PHP-based services sharing the same host.
2. Verify The Version That Serves Web Requests
Inside WordPress, Tools → Site Health → Info → Server can show the PHP version used by the site. Administrators can also check the installed packages, web server configuration and service process inventory. A command-line php -v is a useful clue, not definitive proof: the CLI executable may differ from the runtime configured for Apache or PHP-FPM.
For vendor-backported versions, retain the security bulletin or package changelog showing that CVE-2026-109618 and CVE-2026-109619 are both covered. Validate service restarts after deployment, then test critical functions such as checkout, contact forms, media uploads and authentication.
3. Patch The Runtime, Restart Workers And Verify
Use the fixed package for the PHP branch you actually run. Restart or recycle the affected PHP workers and web server components as appropriate. Rebuild container images and replace running containers instead of assuming an updated host protects a bundled PHP runtime. For hosted platforms, obtain written confirmation from the supplier.
If a system is internet-facing and cannot be fixed promptly, assess whether it should be isolated or temporarily removed from public access. National cyber authorities recommend this where the residual exposure cannot be adequately controlled.
4. Use Temporary Controls Only To Reduce Exposure
The PHP project’s interim guidance includes disabling session upload progress, controlling multipart/request sizes and related parsing limits, and reviewing memory-handling configuration. A network or CDN web application firewall may filter some known malicious request patterns. These controls do not remove the vulnerable engine code and may affect legitimate functionality.
Do not copy emergency memory-limit changes into production without a capacity and availability assessment. The PHP advisory discusses memory_limit=-1 in specific configurations but explicitly warns that it is not a complete fix; an inappropriate setting can shift memory exhaustion to the operating system. Use the vendor’s full guidance and test the impact before making temporary changes.
5. Investigate the Exposure Window, Not Just the Current Patch Level
Once patching is confirmed, identify the dates on which the site was publicly accessible with a vulnerable runtime. Preserve relevant web, WAF, PHP-FPM/Apache and operating system logs. Look for anomalous multipart requests, repeated PHP crashes, unexpected worker child processes, newly written PHP files, unfamiliar administrator accounts and outbound connections. One unusual request is not evidence of a breach; multiple correlated signals deserve escalation.
Where a compromise is suspected, preserve evidence before deleting files, isolate the affected instance, investigate neighbouring sites on the same host and rotate exposed credentials after containment. A clean WordPress scan by itself is not a forensic clearance.
The Third CVE: Why Patching The First Two Is Not The Entire Story
On 23 October 2026, PHP published an informational notice on CVE-2026-115560, a separate session upload progress issue. Exploitation requires an unusual combination: an application configures one session serialisation handler, switches it to another at runtime and has session upload progress enabled. PHP described it as an unlikely remote-code-execution path and recommended session.upload_progress.enabled=0 until a subsequent regular bug-fix release. It was not fixed by the PHP releases of 21 October.
Do not treat this third issue as proof that the patches for CVE-2026-109618 and CVE-2026-109619 are ineffective. They are separate vulnerabilities with separate preconditions. Keep the runtime patched and review the additional configuration advice with your hosting provider.
What Could Indicate A Compromised WordPress Site?
PHP2Shell exploitation takes place below WordPress, so evidence may be scattered across layers. Defenders should correlate:
- Web and WAF logs: unusual or repeated multipart form submissions, unexpected request-body patterns and attempts against sites with no corresponding upload feature.
- PHP and operating system logs: memory-exhaustion errors, segmentation faults, process restarts, abnormal worker behaviour or an unexpected shell process launched by Apache/PHP.
- Filesystem changes: newly created PHP scripts in uploads or writable directories, changes to known-good core, plugin or theme files, and suspicious must-use plugins.
- WordPress state: unauthorised administrators, unexpected plugin installations, unfamiliar scheduled jobs, injected database options or redirects.
- Network activity: connections from the web server to unusual external endpoints, especially when they coincide with a new file or process.
These are investigation indicators, not PHP2Shell-specific proof. Ordinary deployments, other vulnerabilities and malicious plugins can generate overlapping symptoms. Conversely, successful exploitation may leave little visible evidence in WordPress logs.
For a broader verification strategy after an incident, see our WordPress backdoor detection guide.
How Guardian Gaze Helps Detect Suspicious Changes After Exposure
Guardian Gaze addresses two complementary views: the evidence inside a WordPress site and the exposure visible from outside an organisation. Neither view replaces direct host patch verification.
Guardian Gaze for WordPress: Investigate Malware, Files And Database Content
The Guardian Gaze WordPress plugin provides several checks that are relevant after a possible PHP2Shell compromise:
| Guardian Gaze capability | What it can reveal | Important limit |
| Malware and backdoor scanning | Suspicious PHP code or known backdoor patterns in accessible WordPress files, themes, plugins and uploads. | A payload can exist outside the WordPress paths the plugin can inspect. |
| File integrity monitoring | Added, removed or modified files compared with trusted references or established baselines. | A baseline taken after compromise may already include malicious changes. |
| Database malware scanning | Injected scripts, malicious redirects, obfuscated content and suspicious records in supported WordPress tables. | It does not reconstruct all attacker activity or scan host memory. |
| WordPress component vulnerability checks | Known CVEs affecting the installed WordPress core, plugins and themes. | This is not a test for PHP2Shell in the underlying PHP runtime. |
| Additional paid protection and analysis | Depending on the plan, AI-assisted code analysis, richer activity logging, file controls and a web application firewall. | A WordPress-level firewall must not be relied upon to stop a pre-application PHP engine exploit. |
A sensible post-exposure workflow is to run a fresh full scan, review severe findings, verify known-good files independently, inspect the database and check any administrator or plugin changes. Compare results with web-server and host logs. A clean result means no matching artefact was found within the scan’s visibility; it does not mean the host was never exploited. Guardian Gaze’s published features and WordPress.org listing describe the current product scope.
Guardian Gaze Enterprise: Map the External Footprint And Prioritise Review
For teams managing many domains, websites or suppliers, Guardian Gaze Enterprise attack surface management discovers internet-facing assets, identifies observable technologies and associates applicable vulnerabilities with risk intelligence. That can help teams locate forgotten PHP-backed services and prioritise host owners for investigation.
But an external scan cannot always read the actual PHP package build or detect a vendor backport. If the runtime is hidden or a fingerprint is inconclusive, external observations should trigger validation by the asset owner, not a definitive claim that a host is vulnerable or safe. Enterprise provides visibility and prioritisation; server-side evidence is still necessary for closure.
This is the product boundary that matters: Guardian Gaze for WordPress checks for suspicious consequences within the site; Guardian Gaze Enterprise helps identify externally visible assets and risks; the hosting team fixes and verifies PHP.
PHP2Shell Is Not Wp2shell
The names are similar but the vulnerable components are different. PHP2Shell refers to October 2026 PHP-engine issues CVE-2026-109618 and CVE-2026-109619. wp2shell refers to a separate July 2026 WordPress core exploit chain involving CVE-2026-63030 and CVE-2026-60137. Patching WordPress addresses the latter; patching PHP addresses the former. A WordPress estate therefore needs two distinct patch and verification processes. Our earlier wp2shell incident-response case study explains the WordPress-layer investigation.
PHP2Shell FAQ
Is WordPress itself vulnerable to PHP2Shell?
The two October CVEs are in PHP, not WordPress core. A WordPress site can be exposed because it runs on an affected PHP runtime, even when WordPress and its plugins are current.
Does updating WordPress or installing a security plugin fix PHP2Shell?
No. A patched PHP runtime (or confirmed vendor backport) and restarted PHP workers are required. A security plugin can help reveal evidence of compromise but cannot replace that action.
Which PHP versions are patched?
The first fixed upstream releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. A distributor may supply equivalent backported fixes. Confirm both CVEs in the package advisory rather than relying only on the displayed version.
Is PHP2Shell being actively exploited?
Yes. CISA added both CVEs to its KEV catalogue on 26 October 2026, and national authorities have acknowledged in-the-wild exploitation reports. This does not mean every exploit attempt succeeds against every PHP configuration.
Can Guardian Gaze detect a PHP2Shell attack?
It can help detect suspicious post-compromise artefacts, such as web shells, altered WordPress files and injected database content. Its published WordPress vulnerability checks focus on WordPress core, plugins and themes, not direct validation of the PHP2Shell engine flaws. Host and runtime logs are necessary for a complete investigation.
What if my hosting provider has not patched PHP?
Ask for a written remediation and backport status, review the provider’s temporary controls, and assess the case for isolating the site until a fix is applied. Do not treat a WAF rule or a clean malware scan as a permanent remedy.
The Real Lesson: Know What Runs Beneath The Site
PHP2Shell is a reminder that a healthy WordPress dashboard does not automatically imply a secure web server. An application can be fully updated while a shared runtime, hosting image or appliance remains exposed. The priority is to identify every public-facing PHP deployment, apply the correct fix, verify the running workers and review the exposure window.
Guardian Gaze can add useful evidence: the WordPress plugin helps investigate suspicious changes inside a site, while Enterprise helps teams maintain visibility over the assets and vendors that may need attention. Neither replaces the PHP patch. That separation is what makes an incident-response plan dependable.
Check your WordPress site: Install the free Guardian Gaze plugin to scan for malware, backdoors, file changes and suspicious database content.
Review your wider exposure: Request a Guardian Gaze Enterprise risk rating to help identify internet-facing assets and prioritise investigation across your organisation.