PHP2Shell: two critical PHP flaws are being probed, and no crypto platform has been shown hit

Two critical flaws in PHP, the language behind most of the web, are being probed by attackers a day after the fixes came out, and so far no crypto exchange, wallet or custodian has been shown to be hit. The PHP project released patched versions on 21 October in the early afternoon UTC for the bugs, nicknamed PHP2Shell and tracked as CVE-2026-109618 and CVE-2026-109619. Both carry a CVSS v4.0 score of 9.2 out of 10 and allow remote code execution, according to the PHP security advisory on GitHub.

Coinbase and BitGo say they are not affected. BNB Chain says it does not use PHP. Binance says it put safeguards in place before the patch and has finished its remediation. Changpeng Zhao, Binance’s founder, told his followers to be “extra careful” on any website for a few days. Cloudflare’s chief executive, Matthew Prince, wrote on X that attempts to exploit the flaws across Cloudflare’s network went from thousands before the announcement to millions by early Thursday.

For crypto readers, the story is less about exchanges than about the long tail: WordPress shops that take crypto payments, self-hosted dashboards, block explorers and node front-ends that run PHP somewhere in their stack, and the phishing that tends to follow any widely covered bug.

PHP2Shell: what CVE-2026-109618 and CVE-2026-109619 do

The first flaw, CVE-2026-109618 (GitHub advisory GHSA-w8hw-w9fx-j79w), is a memory corruption bug that can be triggered when PHP runs out of memory while handling a request. The second, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), comes from stale global state that survives from one request to the next. Either one can let an attacker run code on the server, which is what “remote code execution” means and why both scored 9.2.

The setup that matters most is mod_php, the module that runs PHP inside the Apache web server. There, the advisory says, a single request from someone who is not logged in can start the attack before the website’s own code even runs, and the PHP team demonstrated code execution over HTTP with default memory limits. PHP-FPM, the process manager used with Nginx on many hosts, is considered susceptible, but no complete exploit had been demonstrated against it at publication. FrankenPHP and LiteSpeed’s LSAPI are likely susceptible and have not been validated.

That detail is why the usual advice of “update your plugins” does not cover this one. The bug sits in the PHP runtime on the server, under WordPress, WooCommerce or any custom code. Cloudflare makes the same point in its post: patch PHP itself, because updating the applications that run on it is not enough.

Fixed PHP versions and support status

Four fixed releases came out on 21 October, one per supported branch. The 8.6.0 release candidate published the same day (RC4) also carries the fixes, but it is a test build that PHP says should not run in production.

Linux distributions received the patches in advance, so Debian, Ubuntu or Red Hat packages may already carry them under their own version numbers. CERT-EU noted on release day that Remi’s repository, a common source of recent PHP builds for Red Hat-type systems, had no update yet. Software that bundles its own copy of PHP may also be exposed; CERT-EU points administrators to a GitHub repository kept by the Dutch NCSC that lists affected products.

The PHP team says that updating is the only complete mitigation. For servers that cannot be updated at once, it and CERT-EU list partial measures that reduce the risk without removing it: setting memory_limit to -1 in a way applications cannot override, keeping post_max_size at 8M or 32M, limiting request sizes at the proxy, turning off session.upload_progress.enabled, and on PHP 8.5 setting fatal_error_backtraces to 0. They advise against using the RLIMIT_AS or RLIMIT_DATA system limits.

Exploit attempts rose after disclosure, but no victim is named

Cloudflare says it switched on web application firewall (WAF) rules against the flaws at 03:02 UTC on 21 October, about nine hours before the public disclosure, and that it then saw attack traffic aimed at its customers, with attackers changing their payloads to slip past the rules. The Cloudflare blog post does not give a count. The protection is on by default for free-plan sites, through the “Generic Rules – Anomalous Execution” rules of the Managed Free Ruleset; paid customers need the Cloudflare Managed Ruleset in block mode.

The figure in many headlines comes from Prince. In a post on X at 01:25 UTC on 22 October, he wrote that Cloudflare saw thousands of attempts in the ten hours before the announcement, tens of thousands in the 45 minutes after it, hundreds of thousands within two hours, and “millions now”. Those are attempts, not successful break-ins. About one website in five routes its traffic through Cloudflare, according to the company as cited by Cointelegraph, so its view is wide but not complete.

Other signals point the same way without settling the scale. Cloudflare’s chief technology officer, Dane Knecht, spoke of early attacks, as reported by Fortune. Amazon found an exploitation attempt dating back to 17 October, four days before release, Bitcoin.com News reported, citing an AWS security blog post. “Defenders should not assume the public disclosure date is the earliest date of exploitation,” Amazon’s chief information security officer CJ Moses said, according to the same report. CERT-EU said public technical details and early proofs of concept were circulating. The US Cybersecurity and Infrastructure Security Agency (CISA), in its 21 October alert, said it had not observed exploitation at the time it published.

Government agencies in the Netherlands and Finland took some websites offline as a precaution, Fortune reported, citing Reuters; Decrypt reported the same. The FBI’s cyber division and the NSA urged updates. Fortune described confirmed breaches as “limited and unfolding” and named no victim.

Two numbers are often mixed up. PHP runs on about 69% of websites whose server-side language is known, according to W3Techs figures quoted by Cointelegraph. That is a measure of use, not of exposure, as Cointribune points out: a site on a patched or non-mod_php setup is not in the same position as an old Apache server. Fortune reports that Palo Alto Networks counted 22.6 million potentially vulnerable instances, a figure from a single outlet.

How the release was rushed by a leak

PHP pre-announced the security release on 20 October and scheduled it for 14:00 UTC the next day. According to Decrypt, the coordinated release had first been set for 22 October and was brought forward after details leaked. CERT-EU puts the publication of the fixes at 13:30 UTC on 21 October.

OpenAI has put itself at the centre of the discovery. Its president, Greg Brockman, said the bug had sat in PHP for 14 years and that a limited version surfaced in 2024 but “wasn’t considered significant”, Decrypt reported; the outlet’s writer called the message a PR stunt. Fortune gives a fuller account: the AI red-team firm Calif found the first issue on 1 August with OpenAI’s GPT-5.6 Sol, OpenAI then investigated and found more, and the cloud security firm Wiz found the first issue on its own on 19 August using several models, Google’s Gemini 4 Argon among them. OpenAI led a coalition with Wiz, Calif, the PHP Foundation, Cloudflare and several US agencies, according to Fortune. Cloudflare’s post names Calif, Wiz, OpenAI and Quarkslab as the four organisations that disclosed the flaws, and the GitHub advisory credits four reporters by their handles.

This is not the WordPress bug from July. That one, known as wp2shell (CVE-2026-63030 and CVE-2026-60137), was fixed in WordPress 6.9.5 and 7.0.2. PHP2Shell sits one layer lower and needs a PHP update, whatever the WordPress version.

What Coinbase, BitGo, BNB Chain and Binance said

Coinbase’s chief security officer, Jeff Lunglhofer, wrote on his personal X account on 21 October at 20:32 UTC that “Coinbase completed a sweep of our environment and has found no evidence of any exposed PHP instances.” He added that the company was also working with its third-party suppliers for extra assurance. BitGo is unaffected as well, Bitcoin.com News reported, without quoting the company.

BNB Chain said its tech stack “does not use PHP”, according to Coingape, which also reported that a Trust Wallet staff member, Felix Fan, said the wallet’s stack has no PHP. The blockchain security firm SlowMist urged exchanges, wallets and DeFi platforms to check their infrastructure, EthNews reported, while noting that the attack activity seen so far does not show whether any crypto platform was breached.

Changpeng Zhao posted on 21 October at 22:06 UTC: “Call me paranoid, but be extra careful visiting ANY web site in the next few days.” In the same post he named the two CVEs and said some web administrators are slow to apply security patches.

Binance’s official account followed on 22 October at 06:18 UTC. The exchange said its security teams “implemented proactive safeguards ahead of the official patch release and completed the necessary remediation” and that it continues to monitor the situation. It did not say whether any of its systems ran a vulnerable PHP version, so “remediation” could mean patching, filtering or a check that found nothing.

These statements cover the companies’ own systems. Lunglhofer’s mention of suppliers points to where exposure can remain for a large platform: vendors and outside tools it does not run itself. Some outlets have run pieces asking whether users should pull funds from exchanges. Nothing published so far supports that: no exchange has reported an incident, and none has been named by researchers or agencies.

CERT-FR and ACN alerts for France and Italy

France’s CERT-FR, part of the national cybersecurity agency ANSSI, published alert CERTFR-2026-ALE-014 on 20 October and updated it on 21 October. It says the two CVEs can allow remote arbitrary code execution and that fixes are available from the publisher. In Italy, the CSIRT of the national cybersecurity agency ACN published alert AL07/261021/CSIRT-ITA on the evening of 21 October, titled “PHP2Shell: sanate vulnerabilità critiche in PHP”.

Neither France’s AMF nor Italy’s Consob had published anything on the flaws when this article was written. For crypto firms in Europe, the national alerts are the reference to keep in an incident file, and the place to watch for an update on exploitation.

If you run a crypto site, node front-end or payment plugin

Most of the risk in crypto sits with smaller operators: a merchant running a crypto payment gateway on WooCommerce, a project hosting its own explorer or staking dashboard, a validator with a PHP admin page. The official advisories give a clear order of work.

1. Update PHP on the server or in the container image to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution’s patched package. A WordPress or plugin update alone does not fix this.
2. On shared hosting, ask the host which PHP build your account runs and when it was patched.
3. Look for PHP you did not know you had: crypto payment plugins, wallet or invoice dashboards, self-hosted block explorers, node and staking front-ends, admin panels and Docker images built on PHP base images.
4. On PHP 8.1 or older, move to a supported branch, apply a vendor backport, or take the system off the internet, as CISA recommends.
5. If you cannot patch today, apply the partial settings listed above, put the site behind a WAF (Cloudflare’s free plan includes the rules) and watch for PHP worker processes that start shells, a sign CISA lists for compromise.

Treat any server that handled private keys, API keys for exchange accounts or hot-wallet credentials as a priority. A PHP bug does not reach keys stored elsewhere, but a compromised payment page can change the deposit address shown to customers without touching the wallet itself. Earlier this week, the eMudhra weak-key case already had crypto teams updating bots and servers, and this morning the Railway breach asked every user of that hosting platform to rotate secrets.

What wallet and exchange users should do now

Keys held on a hardware wallet are not exposed by a web-server bug. Risk comes from the pages you visit. A site taken over through PHP can inject a wallet drainer script or swap a deposit address, and the attacker does not need your keys if you sign the transaction for them.

Check every receiving address on the device screen as well as in the browser. Open exchanges from a bookmark rather than from search results or links in emails. Turn on withdrawal address allowlists and, where the exchange offers one, an anti-phishing code that appears in its genuine emails. Expect messages about a “PHP security update” that ask you to log in or reconnect a wallet; no exchange needs you to do that because of this bug. Our guide on how to spot and report crypto scams covers the common forms these take, and no genuine message will ask for your recovery phrase: our seed phrase security guide explains how to keep it offline.

There is no reason, on the facts published so far, to move funds in a hurry. A rushed withdrawal to a mistyped or swapped address is a more likely way to lose money this week than an exchange breach that nobody has reported.

What is still unknown, and the next dates

The number of servers actually compromised is not known, and no crypto platform has reported or been shown to have suffered an intrusion through PHP2Shell. Prince’s “millions” counts attempts, and Cloudflare has published no breakdown of how many succeeded. Binance has not said what its remediation consisted of, and BitGo has not been quoted directly. Beyond the four GitHub handles and the companies named in the press, the people who reported the bugs are not identified.

The next date is set by the PHP calendar: PHP 8.2 stops receiving security fixes on 31 December 2026, so sites still on that branch have about ten weeks to move. Watch the CERT-FR and ACN pages and CISA’s Known Exploited Vulnerabilities catalogue for any confirmation of exploitation in the wild, which would change the advice from urgent to compromise assessment.