PHP Vulnerability: What Crypto Projects Should Check and Tell Their Community

TL;DR:

• PHP2Shell, the critical PHP vulnerability behind this week's warnings, is a pair of flaws in PHP, the language behind most websites, that let an attacker run code on a server without logging in. PHP shipped fixes on October 21, 2026, and attackers started probing for unpatched servers the same day.
• For crypto, the danger isn't the blockchain. Smart contracts and cold wallets don't run PHP, but project websites, blogs, claim pages and support portals often do, and a hijacked site can show users a fake "connect wallet" pop-up called a wallet drainer.
• Crypto teams have two jobs this week: check every website and vendor that touches users, and tell the community what you found. The patch belongs to engineering; the statement belongs to marketing and community.
• That second job is already being rewarded in public. When PancakeSwap posted that it doesn't use PHP, Binance co-founder CZ shared it and wrote that "most projects should at least post a confirmation like this."
• Below you'll find the 4-Layer Web Check for your sites, hosts, scripts and secrets, plus what a good community statement says, so you can be done (and say so) within 48 hours.

More than half of the crypto websites one security firm checked run on the software at the center of this week's security scare. When the Web3 security firm SlowMist scanned 1,488 crypto-industry domains, 793 of them (53.3%) showed direct signs of PHP (SlowMist). SlowMist notes that a fingerprint alone doesn't prove a site can be exploited. It does show how many crypto teams now have a question to answer.

The flaw lives in web servers, so the risk for a crypto project lives in its websites and in its silence. No exchange or wallet has reported losses tied to PHP2Shell as of October 24, 2026. The open questions are whether a forgotten landing page could start serving a drainer, and whether users hear from you before they hear rumors. This guide is for founders, marketing leads and community managers who need both answers this week, without a security team's vocabulary.

Start with what PHP2Shell actually is, in plain terms.

The PHP vulnerability is a server bug, not a blockchain bug

PHP2Shell is the name for two critical flaws in the PHP interpreter, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 out of 10. They let an attacker run code on a web server with crafted web requests and no password. Because the bugs sit in PHP itself, every site built on it is in scope, whatever CMS or plugins it uses (PHP).

The first bug corrupts memory when PHP runs out of it while reading an incoming request. The second lets leftover data from one visitor's request be reused by the next request on the same server process. Both were found with the help of AI tools by the security firms Calif and Wiz, credited alongside OpenAI, and details leaked online before the planned October 22 disclosure. The security firm watchTowr confirmed the leak on October 20, and PHP moved its fix up a day (watchTowr).

Exploitation attempts started before most teams knew. Amazon's threat intelligence team caught one on its decoy servers on October 17, four days before disclosure, and now reports "broad exploitation attempts in the wild" (AWS Security Blog). The FBI issued a public warning on October 23 (FBI IC3). Here is where things stand:

PHP's own advisory is blunt: there is no complete workaround, and updating is the only safe choice (PHP).

The exposure for crypto sits on your websites, not on-chain

A crypto protocol's most valuable code rarely touches PHP. Smart contracts run on the blockchain and go through security audits, wallets sign on users' devices, and most modern app frontends are built in JavaScript. The PHP lives one layer out, in the places teams set up fast and update rarely: the WordPress blog, the campaign landing page, the old airdrop claim site, the help desk, the forum. PHP runs 69.3% of websites whose server language is known, and WordPress alone runs 39.6% of all websites (W3Techs).

That layer matters because users trust it. A visitor who lands on your official blog has no reason to doubt a "claim your rewards" button, which is exactly what makes a hijacked project site more dangerous than a fake one. Wiz, one of the firms that found the bugs, also warns that the memory leak can expose "passwords, authentication tokens, API keys and certificates" from the server, even without a full takeover (Wiz).

Our own site, lunarstrategy.com, runs on Webflow, so the server patch is Webflow's responsibility. Most crypto teams have a mix like this, and the risk sits in the rows nobody owns. The app usually has an engineering team watching it, while the blog belongs to marketing, the claim page to a campaign that ended months ago and the help desk to a vendor nobody has emailed since onboarding.

A hijacked crypto site drains users fast, and 2025 showed how

Wallet drainers are malicious scripts that ask a visitor to connect a wallet and sign a transaction that hands over their tokens. They stole $83.85 million from 106,106 victims in 2025, according to Scam Sniffer, the anti-scam firm whose wallet-drainer data crypto media track every month, and its report lists compromised frontends of legitimate platforms as one of the ways drainers reach users (Scam Sniffer). Four incidents from 2025 show the pattern PHP2Shell could repeat:

• PEPE's official website (December 2025): the Web3 security firm Blockaid found Inferno Drainer code injected into the memecoin's own site (Cointelegraph). This is the closest match to the PHP2Shell risk: a token's marketing site turned against its holders.
• CoinMarketCap (June 2025): a homepage "doodle" image pulled in malicious code that showed visitors a wallet-connection pop-up on one of crypto's most visited sites (CoinDesk).
• Cointelegraph (June 2025): days later, a fake token airdrop pop-up appeared on the news site itself, promising rewards to anyone who connected a wallet (Decrypt).
• Curve Finance (May 2025): attackers breached the domain registrar and pointed curve.fi to a decoy that asked users for wallet signatures. Curve's post-mortem explains how it warned users through its official channels (Curve).

None of these needed a smart contract bug. Each needed control of a page users already trusted, which is what an unpatched PHP server hands over.

The 4-Layer Web Check: what to audit

The check below follows the path a drainer would take to your users, from the servers you run to the code you load from others. Each layer gets the same three labels, so a founder, a marketer and an engineer can split the work and report back in the same format.

01 · Your own PHP sites: "Which of our websites run PHP, and are they patched?"

• Check: list every domain and subdomain you control, including old campaign, claim and testnet pages. Ask the owner of each one for the PHP version, then update to a fixed release and restart every PHP process.
• Trap: updating WordPress, the theme or plugins doesn't fix this. The patch is in PHP itself, one level below.
• Done when: each live PHP site shows a fixed version, and anything you can't patch is offline, as the NSA and CISA advise.

02 · Hosts and managed platforms: "Who patches the servers we don't run ourselves?"

• Check: for shared hosting, agencies and managed WordPress, ask for written confirmation of the PHP version. For hosted builders and docs platforms, read their status page or security notice.
• Trap: on shared hosting you can't patch PHP yourself. Only the host can.
• Done when: every vendor has replied in writing, with a date.

03 · Third-party scripts and widgets: "What code from other servers runs on our pages?"

• Check: list the chat widgets, analytics, price tickers and embeds your sites load. Coinbase's chief security officer said Coinbase is also checking its third-party suppliers, the same layer CoinMarketCap learned about the hard way (Jeff Lunglhofer, Coinbase).
• Trap: your server can be fully patched while a script you load comes from one that isn't.
• Done when: unknown or abandoned scripts are removed, and the rest come from vendors who have confirmed their status.

04 · Secrets on PHP servers: "What could have leaked before we patched?"

• Check: list the API keys, database passwords, tokens and certificates stored on any PHP server that was exposed, and rotate them as a precaution.
• Trap: patching stops new leaks but doesn't revoke what may already be out.
• Done when: exposed secrets are rotated and access logs show nothing unusual since October 17.

Cloudflare and other firewall providers have pushed rules that block known attack patterns, and attackers are already changing their payloads to get around them (Cloudflare). A firewall buys time; it isn't a patch.

Silence costs more than the bug, so post your status

Once the check is done, the second job begins, and it isn't technical. Users can't see your servers. All they can see is whether you said something, and trust is built on what they can see. In a week when the FBI and CISA are issuing warnings and Binance's co-founder is telling people to be careful on any website, saying nothing reads as either negligence or something to hide.

The projects that answered first set the bar. PancakeSwap posted within hours that it "does not use PHP anywhere in our tech stack, and our platform is not affected" (PancakeSwap). Trust Wallet and BNB Chain posted similar notes, and Coinbase's security chief described what the team had checked, not just the conclusion. CZ then pointed his followers at the PancakeSwap post:

"Most projects should at least post a confirmation like this."

Changpeng Zhao (CZ), co-founder, Binance (X, October 22, 2026)

What makes a good statement is well documented. The Security Alliance (SEAL), the white-hat group behind the SEAL 911 emergency line, tells teams to "ship only confirmed facts", to say what users should and shouldn't do, and to state when the next update comes (SEAL). Its templates allow "user funds are safe" only if that's true (SEAL templates).

Whatever the 4-Layer Web Check found, the post should say what you checked, whether the app and smart contracts were affected, what users should do and where your official links live. Brief your community moderators so they answer with the same words, and post it on X, Discord, Telegram and your status page.

Keep the statement factual and short. Claim only what you verified, never promise "funds are safe" for systems you haven't checked, and pin it where new members land first, because the same question will keep arriving for days. Our guide to crypto community management covers how to set that up before you need it.

If something already looks wrong, treat it as a fund-risk incident

A changed page, a pop-up you didn't build or a user report of a strange signature request is no longer a patching problem. It means someone may already control a page your users trust, and every minute it stays up is a minute a holder can sign the wrong transaction. SEAL's runbook for a compromised frontend says to treat it as a risk to user funds and to move in this order (SEAL):

• Take it down: pull the site offline or redirect it to a holding page before you investigate.
• Warn everywhere at once: tell users on X, Discord, Telegram and your status page not to interact with the domain or approve any transactions until further notice.
• Look for the signs: CISA flags PHP processes launching shells or downloading tools (CISA), and watchTowr adds new web shells, unexpected scheduled jobs and new accounts tied to PHP.
• Rotate before you restore: a patched server can still hold an attacker's foothold, so change every credential first.
• Help affected users: publish the affected addresses and guidance on revoking token approvals, and say what happens next.

Speed matters more than polish here. A short warning in the first hour protects more users than a full post-mortem the next day, and Curve's quick redirect to a new domain is a good model of how to keep users on a safe path while the investigation runs.

Where to start this week

Today, list every domain your project owns and name one owner for each, because unowned sites are where drainers end up. Tomorrow, run layers 01 and 02 of the 4-Layer Web Check and collect written confirmations from your hosts. On day two, finish layers 03 and 04, then post the statement that matches what you found, using the same words on every channel. After that, set a calendar reminder for December 31, 2026, when PHP 8.2 stops receiving security fixes, and plan to retire the old microsites nobody uses.

Keep your community calm when the next headline hits

PHP2Shell won't be the last security headline that sends crypto users into your Discord asking whether their funds are safe. Lunar Strategy has worked with more than 300 crypto projects, and our Crypto Community Management service covers exactly that moment: 24/7 moderation by a dedicated team, crisis response, and a strategic lead who aligns what your moderators, your X account and your founders say. If you need help with the public statement itself, our PR and strategic messaging team handles the wording and the media.

Talk to our community team →

24/7 moderation and crisis response for Discord and Telegram: tell us your channels and launch calendar, and we'll map coverage with you.

Frequently Asked Questions

Is PHP2Shell a crypto hack?

No. PHP2Shell is a vulnerability in PHP, the programming language behind most websites, not in any blockchain, token or wallet. It affects crypto only where a project or vendor runs PHP on a web server, such as a WordPress blog or a claim page. As of October 24, 2026, no exchange or wallet has reported losses tied to it.

Do I need to move my crypto off exchanges because of PHP2Shell?

PHP2Shell doesn't touch blockchains, and the large exchanges that commented said they don't run exposed PHP or had already fixed it: Coinbase reported no exposed PHP instances and Binance said it completed remediation. The practical risk for users is phishing through hijacked websites, so avoid connecting a wallet through pop-ups or links you didn't expect.

Does PHP2Shell affect sites built on Webflow, Next.js or Vercel?

Webflow is a hosted platform that applies security patches to its own servers, so its customers don't patch PHP themselves. Vercel's official runtimes for Next.js and other apps don't include PHP. The exposure sits in self-hosted or shared-hosting PHP, most often WordPress, and in third-party tools that run on PHP servers.

Is PHP 7.4 vulnerable to PHP2Shell?

Yes. Every PHP version from 5.4 onward is affected. PHP 7.4, 8.0 and 8.1 are past end of life and only received minimal source patches, not official releases, and 7.3 or older gets nothing. CISA advises taking systems on PHP 8.1 or earlier offline until they are upgraded to a supported, fixed version.

What is CVE-2026-115560?

CVE-2026-115560 is a third remote code execution flaw PHP disclosed on October 23, 2026, in the session upload progress feature. PHP calls it an unlikely attack path, but it affects even the versions released on October 21. Until the next regular release, PHP's fix is to set session.upload_progress.enabled=0 in php.ini and restart every worker.

Who discovered PHP2Shell?

The security firms Calif and Wiz found the flaws independently in August 2026 with the help of AI tools, and PHP credits them alongside OpenAI and one more researcher. The details leaked online before the coordinated disclosure planned for October 22, which is why PHP released its fixes a day early, on October 21.