PHP2Shell Explained: What CVE-2026-109618 and CVE-2026-109619 Mean for Digital Asset Organizations

PHP2Shell is the name for two use-after-free vulnerabilities in the PHP interpreter itself, tracked as CVE-2026-109618 and CVE-2026-109619. Because the bugs sit in the language runtime and not in application code, a well-written application on a vulnerable PHP build is still exposed.

The scope is very wide. PHP runs on about 69.7% of websites whose server-side language is known, and reporting indicates the affected code paths go back to PHP 5.4. CISA states that the flaws affect all PHP installations serving web requests. This includes Apache with mod_php, PHP FastCGI Process Manager (PHP-FPM), php-cgi, FrankenPHP and LiteSpeed. PHP considers mod_php the highest-risk setup.

Researchers from Calif, Wiz and OpenAI found the flaws with AI-assisted research tools and reported them to PHP in August 2026. Coordinated disclosure was set for October 22.

The disclosure timeline shifted as events unfolded:

• October 17: Amazon's honeypot network recorded an exploitation attempt from an anonymized IP address, four days before public disclosure. It is still not clear how the actor obtained the exploit details.
• October 20: A pseudonymous user leaked details of the flaws on the Hacker News forum. PHP published an advance notice the same day.
• October 21: PHP moved the release forward by one day and shipped fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. A proof-of-concept video that one research team released by mistake added more public detail on the flaws.
• October 22: Exploit attempts rose from tens of thousands to millions within about a day of the release.
• October 26: CISA added both CVEs to the KEV catalog.

In practice, the patch window closed before most teams could act on it. Any organization that patched after October 17 should assume its servers were exposed during that gap.

Both flaws come from the same root cause. PHP handles some fatal errors with longjmp(), a C function that jumps out of the current code path at once. When that jump happens at the wrong moment, PHP leaves memory in an unsafe state. An attacker can then shape that memory to take control of the process.

• CVE-2026-109618 (RCE through out-of-memory corruption): A crafted multipart request can force PHP to run out of memory while it is still setting up request data. PHP then exits with that data only partly initialized, and the cleanup code reads or branches on invalid values. Under Apache mod_php, this can happen before any application code runs.
• CVE-2026-109619 (RCE through stale global state): PHP keeps global state that points to memory owned by a request. If PHP does not reset that state before it frees the memory, the next request on the same worker can use the stale pointer. PHP's advisory for this CVE confirms session-related RCE against both mod_php and PHP-FPM, and lists memory disclosure as a confirmed impact.

PHP also published a separate informational advisory for CVE-2026-115560 on October 23. This third issue affects only unusual session configurations, and the October 21 releases do not fix it. PHP recommends setting session.upload_progress.enabled=0 until its next routine release. This is the same setting it already listed as a mitigation for CVE-2026-109619.

Several factors make PHP2Shell more serious than a typical CVE:

• No authentication required: An attacker needs only network access to a page that PHP processes. The attacker needs no account, no user interaction and no flaw in the application.
• No complete workaround: The PHP project says in its release notes that "There are no complete mitigations, updating is the only safe choice."
• Confirmed exploitation: Beyond the CISA KEV listing, honeypot operators reported 35 successful in-the-wild exploits that led to attacker command execution.
• A long tail of unsupported versions: PHP 8.1 and older will receive no official release. Teams on those branches must upgrade, use a vendor backport or isolate the host. PHP 8.2 itself reaches end of life on December 31, 2026.

One public test makes the risk concrete for this industry. A developer put a Bitcoin private key on a server running unpatched PHP 8.4.26 and invited anyone to take it. A researcher exploited PHP2Shell and extracted the key in about 19 hours. The prize was small, but the lesson is direct: secret material on a PHP host is only as safe as that host's patch level.

Smart contracts, blockchains and offline cold storage are not affected by PHP2Shell. The exposure sits in the off-chain systems around them. In digital asset organizations, PHP most often appears in these places:

• Marketing and corporate websites: Many company sites, blogs and documentation hubs run on WordPress or Drupal, both built on PHP. These sites often share a domain, a content delivery network (CDN) account or a deployment pipeline with the product.
• Support and help desk portals: Self-hosted ticketing and knowledge base tools collect identity documents, account details and screenshots from users. Some also connect to internal user lookup APIs.
• Admin panels and back-office tools: Internal dashboards for compliance review, withdrawal approval queues, reporting and database management (such as phpMyAdmin) are often PHP applications. These tools sit close to the systems that move funds.
• Vendor and legacy systems: Know Your Customer (KYC) onboarding portals, payment gateway plugins, billing systems and older exchange components may run PHP, even when the core engineering team has never touched it.
• Staging and forgotten hosts: Old campaign sites, test copies and acquired-company infrastructure often run outdated PHP with no clear owner.

On its own, a compromised marketing server may look low-impact. The risk comes from what that server can read and reach. An attacker with code execution on a PHP host can:

• Steal secrets from the host: Environment files and configuration often hold exchange API keys, cloud credentials, remote procedure call (RPC) provider keys, database passwords and tokens for custody or signing services.
• Tamper with user-facing frontends: An attacker who controls a site that loads wallet-connect scripts, or that shares a domain with the app, can inject malicious JavaScript. This turns a trusted page into a wallet drainer or a phishing page.
• Move laterally: A PHP host that sits on a flat network can become a foothold toward internal APIs, hot wallet infrastructure or administrator workstations.
• Abuse privileged workflows: A compromised admin panel can let an attacker approve changes, alter withdrawal allowlists or pull customer data for targeted social engineering.

This pattern is not new. In Halborn’s Top 100 Digital Asset Hacks report, off-chain causes, such as compromised keys, signing workflows, social engineering and vendor infrastructure, drove 96% of H1 2026 losses, up from 36% in 2021. PHP2Shell is a new entry point into that same category. Because on-chain transactions are near-instant and irreversible, an off-chain foothold that reaches signing authority can cause losses that no one can reverse.

Treat PHP2Shell as an active incident, not a routine patch cycle. Work through these steps in order:

1. Inventory every PHP installation: Start with internet-facing hosts, then internal tools, staging copies and anything a vendor or agency runs for the organization. Check the package version, not only php -v. Linux distributions often backport fixes while the reported PHP version stays lower.
2. Update to a fixed release: Install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or the patched package from the operating system vendor. For PHP 8.1 and older, upgrade to a supported branch or use a vendor backport.
3. Restart every PHP process: Fully restart PHP-FPM pools and Apache. A graceful reload can leave old workers running vulnerable code.
4. Isolate what cannot be patched today: Take the host offline or restrict it behind a VPN or an IP allowlist. Set session.upload_progress.enabled=0 in php.ini or the FPM pool configuration. Treat the host as still exposed, because PHP says no setting fully mitigates the flaws.
5. Hunt for signs of compromise: Review logs from October 17 onward. Look for unusual multipart POST requests, clusters of PHP worker crashes or segmentation faults, new processes spawned by the web server user, unexpected files in web directories and changes to JavaScript served to users.
6. Rotate reachable secrets: Assume that any credential readable by an exposed PHP host may be compromised. Rotate API keys, database credentials, cloud access keys and service tokens. Review withdrawal allowlists and signing-policy changes made since October 17.
7. Confirm third-party status in writing: Ask hosting providers, agencies and software-as-a-service (SaaS) vendors that run PHP for the organization to confirm the patch date and any findings.
8. Cut the path to funds: Confirm through network segmentation that no PHP host can reach signing infrastructure, key management systems or hot wallet services directly.

You probably don’t think you run PHP, and that’s the problem. Halborn's clients build their core stacks in Go, TypeScript and Rust. PHP still lingers on their marketing sites, support portals, admin panels and back-office tools, and those systems can often reach API keys, wallet infrastructure or user-facing frontends. That gap between the code an engineering team owns and the attack surface it actually runs is where PHP2Shell does damage.

Halborn covers both sides of that gap, from cloud, applications and infrastructure to smart contracts, protocols and key management. For PHP2Shell, that work starts with an exposure assessment: a risk-ranked inventory of every internet-facing PHP system, its version and its setup, with end-of-life builds flagged. Remediation support follows, with a patch plan, guidance for versions that will get no official fix, and a retest that confirms each fix landed. A compromise assessment then shows whether attackers got in after October 17 and guides the rotation of keys and credentials. 

PHP2Shell shows that a digital asset organization's security is only as strong as the least visible server with a path to its keys. To assess your PHP2Shell exposure, reach out to Halborn.