Audience: Vulnerability Managers, Security Operations, CISOs, DevSecOps Teams
Reading Time: Approximately 10 minutes

This situation is changing quickly; exploitation status and vendor guidance may be revised.

Subscribe to get these articles directly to your inbox when published

Executive Summary

PHP2Shell allows unauthenticated remote code execution against PHP installations that handle web requests, with potential access to files, databases, and connected services. PHP's maintainers list PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed as potentially at risk, with mod_php at highest risk. Researchers report that the vulnerable code dates back to PHP 5.4.0, released in 2012.

Security vendors reported exploit attempts before the fixes were released (see Exploitation Analysis). Fixed releases are available for PHP 8.2 through 8.5. PHP 8.1 and earlier receive no official PHP project release, but the PHP security team has published minimal source backports for 7.4, 8.0 and 8.1, and some Linux distributions and LTS vendors have shipped backported packages. Systems with no vendor-supported fix remain exposed, so organisations should identify affected runtimes and establish a remediation or isolation plan.

Immediate defender concerns: internet-facing PHP, embedded PHP in appliances, exploit attempts that began before fixes were available, and the way AI-assisted research shortened the path from a long-standing flaw to a working exploit.

Vulnerability Overview

The vulnerabilities involve two distinct PHP memory-handling flaws. CVE-2026-109618 concerns out-of-memory handling that can leave request state invalid during cleanup. CVE-2026-109619 concerns stale global state that can retain references to freed request memory and be consumed during a subsequent request handled by the same worker. The corresponding PHP Security Team advisories describe the technical details of each vulnerability.

CVE breakdown:

♦ CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): Remote code execution associated with improper handling of out-of-memory conditions. The reported attack path involves request processing being interrupted while request-related state is incomplete. Researchers demonstrated remote code execution over HTTP against Apache mod_php under the tested configuration. mod_php is rated highest risk, but this does not mean other execution modes are safe. PHP's advisory lists PHP-FPM, php-cgi, FrankenPHP and LiteSpeed as potentially at risk, and SentinelOne reports that the session upload-progress path is reachable on PHP-FPM where the application performs a suitable operation.

♦ CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): Remote code execution associated with stale global state and memory lifetime handling. State that should no longer be used may persist after its backing memory has been freed and may subsequently be consumed.

Disclosure timeline: PHP had scheduled a security announcement for 22 October 2026. Black Kite reports that an anonymous post on 20 October described the flaws and claimed a CVSS score of 10.0; PHP rated both flaws 9.2 under CVSS v4.0. PHP released fixes on 21 October 2026 at 14:00 UTC, ahead of the original date. Amazon Threat Intelligence reported a PHP2Shell exploitation attempt against one of its honeypots on 17 October, four days before public disclosure, and Help Net Security reports that it is not known how the actor obtained exploit details while the flaws were under embargo. Vendor reports differ on whether the exploit code in circulation works.

The vulnerability affects the PHP runtime rather than a single application. Researchers demonstrated unauthenticated remote code execution in the Apache mod_php configuration described in the technical reporting. PHP-based applications and tools, including content management systems, frameworks, database administration interfaces and hosting panels, may be exposed when they run an affected PHP version. Independent testing or exploitation of every product or version in these categories has not been reported.

Exploitation Analysis

Exploit attempts were reported before the fixes were released. Amazon Threat Intelligence recorded an attempt on its MadPot honeypot network on 17 October. Cloudflare reported early attacks at 07:43 UTC on 21 October, according to Sansec's timeline, and Hadrian reported exploitation at scale a few hours before the release, mostly through PHP's session upload-progress path. Coalition Security Labs reported that its first exploit-related requests reached its honeypots at 08:00 UTC on 21 October, more than five hours before the release. In the three hours after release it logged 133 requests abusing the upload-progress feature, compared with 28 in the hours before. About 2.5 hours after release it saw the first requests built to trigger the out-of-memory flaw behind CVE-2026-109618.

watchTowr reported observing exploitation attempts against both CVEs through its honeypot network. An earlier vendor statement was more cautious: Huntress reported no exploitation on its partner systems as of 20 October. Most of the public data so far comes from honeypots and vendor telemetry, which show attacker activity but not the number of compromised production systems.

Cloudflare deployed WAF rules for the known exploit vectors, available to all customers including free plans; Cloudflare has a commercial interest in WAF adoption. The PHP maintainers urged operators to update to fixed releases. The UK National Cyber Security Centre urged organisations to consider taking offline any system that cannot be fixed right away.

AI acceleration factor: Wiz Research stated that frontier AI models substantially reduced the effort needed to turn a long-standing flaw into a working exploit.

Exposure Analysis

Asset classes that warrant investigation include the following. These are examples of products that commonly run on PHP, not confirmed-vulnerable products; check each vendor's own guidance:

♦ Public-facing web servers running an affected PHP version

♦ Hosting control panels such as cPanel and Plesk, where the deployed product or component uses an affected PHP runtime

♦ Network appliances and firewalls such as pfSense and OPNsense, where an affected PHP component is present and exposed

♦ Database administration tools such as phpMyAdmin and Adminer, where the deployment uses an affected PHP runtime

♦ Backup consoles such as Bacula-Web and Bareos WebUI, where the deployed application and PHP configuration are affected

The presence of a product in one of these categories does not, by itself, establish that a particular installation is vulnerable. Confirm the PHP version, configuration, product implementation and vendor guidance before classifying an asset as affected.

Potential attack path: An attacker may attempt to exploit an exposed PHP endpoint to execute code with the privileges of the PHP worker. Depending on the permissions, credentials, network access and controls available to that process, a successful compromise could provide opportunities to access application data, interact with connected databases or services, obtain accessible credentials, or move laterally. These are potential post-exploitation outcomes, not a claim that every successful exploit results in all of them.

Operational Challenges

Because exploitation can occur before application-level authentication logic executes, application authentication does not prevent the demonstrated mod_php attack path. The risk varies by PHP execution mode and by which code paths an application exposes, but Datadog's analysis describes default PHP configurations as affected, and configuration changes only reduce specific attack paths. WAF rules may reduce exposure, but they are not a substitute for installing a fixed PHP release.

Some vulnerable assets are likely to run end-of-life PHP versions; practitioners quoted by Help Net Security expect a long tail of embedded and unmaintained installations that will never be patched. The official fixed releases identified by the PHP Security Team are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp). For PHP 8.1 and older, the PHP project has published no official release. Community-maintained repositories may lag the release: Help Net Security reported on 21 October that the volunteer-run Remi repository would not have updates that day and advised switching to distribution packages or building from source; check the repository's current status. The PHP security team has released minimal source backports for 7.4, 8.0 and 8.1 for those who build from source or have no LTS vendor, and some distributions and LTS vendors have shipped backported packages; Ubuntu, for example, lists fixed packages from 14.04 to 26.10, with the oldest releases shown as +esm package versions. Verify the exact patch, its maintainer and the supported deployment procedure before treating remediation as available.

Distribution packages often keep the upstream version number and backport the fix, so a version check against 8.2.35, 8.3.36, 8.4.27 or 8.5.12 can misreport a patched package as vulnerable. Check the distribution's CVE tracker or package changelog instead. Vendor appliances present an additional challenge because the PHP runtime may be maintained by the appliance supplier rather than directly by the customer.

Exploit attempts were reported before the fixes were released (see Exploitation Analysis), so attackers were active before administrators could apply fixes. Patch deadlines counted from the vendor release date therefore understate the period of exposure, which supports emergency change procedures for exposed systems. This is a reading of vendor reports, not a measured exploitation timeline.

Visibility Gaps and Control Failures

Organisations may overlook vulnerable runtimes when inventories focus on applications rather than their underlying components. PHP may be installed directly, bundled with an application or embedded in an appliance. These are potential inventory gaps to assess; the extent depends on each organisation's asset-discovery processes and vendor visibility.

Asset discovery can be incomplete when tools rely on HTTP response headers to identify PHP versions, particularly where version banners are suppressed. Agent-based discovery may also be unavailable on appliances that do not support agents. These are potential visibility gaps to assess in an organisation's environment; they should not be interpreted as findings that every scanner or inventory system necessarily misses these assets.

Prioritisation breaks down when exposure data lacks context on which PHP instances face the internet versus which sit behind internal segmentation. Legacy PHP 5.x and 7.x installations may have unclear ownership or no documented upgrade path. Organisations should verify asset ownership, network reachability and available remediation options.

Detection and Monitoring Opportunities

Logging recommendations:

♦ Capture and retain reverse-proxy and web-server request metadata for PHP endpoints, including Content-Type, Content-Length and user agent. Where request-body logging is necessary for investigation, apply suitable privacy, data-minimisation and sensitive-data controls. Search multipart POST requests for the PHP_SESSION_UPLOAD_PROGRESS form field. ELLIO observed it alongside hundreds of empty file fields, form field names nested dozens of levels deep, bodies of a few hundred kilobytes, and user agents such as php2shell-scan/109618. Applications that use PHP's upload-progress feature send this field in legitimate uploads, so treat it as a lead for investigation, not proof of exploitation.

♦ Monitor PHP-FPM and Apache worker crashes and abnormal restarts, in particular SIGSEGV or SIGABRT terminations that coincide with multipart POST requests. This indicator comes from a single practitioner write-up and is not PHP2Shell-specific; worker crashes have many benign causes.

♦ Monitor PHP memory-limit and out-of-memory events where the relevant logs and telemetry are available. If you apply the memory_limit=-1 interim mitigation, PHP will no longer log memory-limit errors, so rely on operating-system out-of-memory and worker-crash telemetry instead. Correlate these events with unusual requests, unexpected child processes and other indicators rather than treating any single event as proof of exploitation.

Threat hunting: review web-server, reverse-proxy and application logs back to at least 17 October 2026, the date of the earliest exploitation attempt reported so far (against a honeypot), and extend the search window where earlier exposure or suspicious activity warrants it. Investigate requests consistent with out-of-memory exploitation, child processes spawned by PHP workers and unexpected outbound connections from web tiers. Correlate these signals with endpoint and network telemetry where available. Do not treat an individual indicator as conclusive evidence of compromise.

Post-exposure checks: patching does not remove an attacker who gained access before the fix. For internet-facing hosts that were exposed between 17 October and the time of patching, check web roots for new or recently modified PHP files, review cron jobs and scheduled tasks for new entries, review outbound connections from web tiers, and rotate any credentials or secrets readable by the PHP worker, such as database passwords and API keys in configuration files or environment variables.

Detection engineering: establish baselines for PHP worker memory consumption and investigate unusual deviations alongside other indicators of compromise. Coalition's honeypot telemetry reported requests associated with exploitation of the upload-progress feature. Keep the detection logic aligned with the specific behaviour described in the research for each CVE; do not assume that a single request pattern covers both vulnerabilities or that the absence of that pattern rules out exploitation.

Remediation and Prioritisation Guidance

Immediate actions: upgrade affected installations to a fixed PHP release appropriate to the deployment: PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (PHP advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp). For PHP 8.1 and older, use a vendor-supported backport where one exists, or the PHP security team's source backports for 7.4, 8.0 and 8.1 if you build from source; there is no official PHP release for these branches. Where a system cannot be remediated promptly, assess whether it can be isolated from untrusted networks or taken offline until a supported fix is available. Confirm the fix through the relevant vendor or package-maintainer guidance.

Interim mitigations where patching is delayed: summaries of PHP's advisories by Arctic Wolf, SentinelOne and SOCRadar list configuration changes that reduce exposure to specific attack paths without making an installation safe. For CVE-2026-109619, set session.upload_progress.enabled=0 in php.ini, or in an FPM pool or server configuration that applies before request parsing, and restart every worker; on PHP 8.5, also set fatal_error_backtraces=0. This blocks the confirmed paths but not other variants. For CVE-2026-109618, SentinelOne's summary lists setting memory_limit=-1 administratively so that applications cannot override it, together with lowering post_max_size to the smallest value your applications' legitimate requests need; the advisory gives no fixed figure, so the right value depends on your setup. This is also a partial measure. Test any change before deployment, because memory_limit=-1 removes the per-request memory cap. These settings are as reported in the vendor summaries above; confirm them against PHP's advisories (GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp) for your PHP version before applying.

Prioritisation order:

♦ Tier 1: Internet-facing PHP installations running an affected version. Prioritise emergency remediation. Hackerstorm's recommendation is to patch or effectively isolate these systems the same day where operationally feasible, because exploit attempts were reported before fixes were released. Check the live CISA Known Exploited Vulnerabilities Catalog for current listing status and do not delay remediation while awaiting catalogue inclusion.

♦ Tier 2: Appliances and hosting or administration control panels that contain an affected PHP runtime. Confirm the affected component and version, contact the vendor for a supported firmware or software fix, and restrict management interfaces to trusted networks where possible.

♦ Tier 3: Internal PHP installations running an affected version. Assess whether they can be reached from compromised internal systems or other untrusted network segments, then prioritise patching or effective isolation according to reachability, privileges and business impact.

Treat WAF rules and other temporary network mitigations as interim risk-reduction measures, not as substitutes for installing a fixed PHP release. Their effectiveness depends on the specific rule, deployment and attack path; do not assume that protection will last for a predictable number of hours. Reassess the controls after applying the vendor's fix.

Hackerstorm Analysis

The underestimated element is the pre-patch exposure. Reports from Amazon, Cloudflare, Hadrian and Coalition place exploit attempts before PHP released its fixes, and Amazon's earliest observation is dated 17 October. Patch service-level agreements counted from the vendor release date therefore start after exposure began, and an organisation that patched within hours may still need to check for earlier compromise. How the actor behind the earliest attempt obtained exploit details while the flaws were under embargo is not known.

Verification is the second gap. Distribution backports keep upstream version numbers, PHP may be embedded in appliances and container images, and each runtime reads its own configuration, so a host can look patched or unpatched from the wrong evidence. Confirm the fix from the distribution's CVE tracker or changelog, check the settings each web-facing runtime actually loads, and restart workers after any change. Runtime-level inventory remains necessary: organisations cannot prioritise components they have not identified.

Wiz stated that frontier AI models substantially reduced the effort needed to turn a long-standing flaw into a working exploit, and researchers report that the affected code dates back to PHP 5.4.0. That does not establish that every version since was equally exploitable, or that AI alone drove the observed attacks. It does suggest that older code in long-lived components deserves fresh review.

Related articles

Ensure you understand the latest KEV additions to cover off any potential gaps in your remediation activities.  View all weekly reports here

Further Reading

The following resources offer technical analysis to help integrate CISA KEV data into operational triage workflows and stay aligned with updated mitigation guidance.

About Hackerstorm

Hackerstorm is a vulnerability intelligence platform providing CVE reports and enriched vulnerability data, including KEV status, EPSS and ransomware signals, for security practitioners, researchers and developers. Further information is available at www.hackerstorm.com.

Author Information

Timur Mehmet | Founder & Lead Editor

Timur is a veteran Information Security professional with a career spanning over three decades. Since the 1990s, he has led security initiatives across high-stakes sectors, including Finance, Telecommunications, Media, and Energy. Professional qualifications over the years have included CISSP, ISO27000 Auditor, ITIL and technologies such as Networking, Operating Systems, PKI, Firewalls. For more information including independent citations and credentials, visit our About page.

Contact: This email address is being protected from spambots. You need JavaScript enabled to view it.

Editorial Standards

This article adheres to Hackerstorm.com's commitment to accuracy, independence, and transparency:

• Fact-Checking: All statistics and claims are verified against primary sources and authoritative reports
• Source Transparency: Original research sources and citations are provided in the References section below
• No Conflicts of Interest: This analysis is independent and not sponsored by any vendor or organization
• Corrections Policy: We correct errors promptly and transparently. Report inaccuracies to This email address is being protected from spambots. You need JavaScript enabled to view it.

Editorial Policy: Ethics, Non-Bias, Fact Checking and Corrections

Learn More: About Hackerstorm.com | FAQs

Media Contact

Hackerstorm Press Office
Website: https://www.hackerstorm.com
Data feeds: https://www.hackerstorm.com/search-insights/cisa-kev-cve-data

Sources

♦ PHP Security Team advisories: CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) and CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)

♦ watchTowr Intelligence: PHP remote code execution / PHP2Shell

♦ Coalition Security Labs: Security alert: critical PHP vulnerabilities

♦ Datadog Security Labs: PHP2Shell: critical vulnerabilities in PHP

♦ Cloudflare: PHP vulnerabilities and WAF protection

♦ Wiz Research: PHP2Shell: AI uncovers critical RCE vulnerabilities affecting PHP

♦ UK National Cyber Security Centre: PHP security guidance

♦ CISA: Known Exploited Vulnerabilities Catalog

♦ Hackerstorm CVE reports: CVE-2026-109618 and CVE-2026-109619

♦ Help Net Security

♦ Amazon Threat Intelligence

♦ Sansec

♦ Black Kite

♦ SentinelOne

♦Arctic Wolf Labs

♦ELLIO

♦ Ubuntu

♦ SecurityWeek (Hadrian observation)

♦ The Hacker News (Huntress statement)

♦ SOCRadar

Several sources above are security vendors with commercial interests in the products they describe (including Wiz, Cloudflare, Coalition, Datadog, SentinelOne, Arctic Wolf, Sansec, Hadrian, watchTowr, Huntress, ELLIO, SOCRadar and Black Kite). Their figures are reported as the vendors' own observations.