What Happened
On October 21, the PHP project released an emergency security update to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which can lead to unauthenticated remote code execution (RCE); both were rated CVSS v4.0 9.2. PHP officially stated that, before the fix, all PHP installations providing external web services could be affected.
On October 20, vulnerability details leaked before official disclosure, and the patch had not yet been released. The PHP security team had to move the emergency release from the originally scheduled October 22 to October 21 at 14:00 (UTC).
More alarming is that attacks may have predated disclosure. Amazon's threat intelligence team reported that on October 17 they observed exploitation attempts targeting php2shell in their MadPot honeypot network, four days before public disclosure.
SlowMist also issued security reminders and recommendations immediately after PHP's official advance notice.
What Are the Two Vulnerabilities?
CVE-2026-109618 (OOM Memory Corruption): When PHP runs out of memory, the processing flow is interrupted, and the data at hand is only half-prepared. During cleanup, PHP treats these half-finished products as complete data, resulting in memory corruption.
CVE-2026-109619 (Stale Global State): After a request is processed, the memory has been freed, but the related state "remains in place." When the same worker process takes on the next request, it may use this expired state before normal initialization. Officials have confirmed that this can be used to attack PHP-FPM and achieve remote code execution.
From the attack path perspective, the danger of this type of vulnerability lies in the fact that attackers do not need to first obtain a site account, nor do they need to break through business-layer login, permission, or API Key verification. Sending a crafted request to a PHP application exposed on the public internet may allow arbitrary code execution with the privileges of the web service process.
Scope of impact: PHP 5.4 through 8.5.11 are all affected. The fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 8.1 and earlier versions have ceased regular upstream support, so patches cannot be expected through regular channels, and migration to still-supported versions should be undertaken.
Why is the whole world nervous?
Because PHP is simply too ubiquitous. According to W3Techs statistics, among websites whose server-side language can be identified, 69.3% use PHP. Familiar systems such as WordPress, WooCommerce, and Magento all run on it underneath.
Reactions from various countries also illustrate the problem—the Netherlands National Cyber Security Centre once precautionarily shut down websites; the South Korean Presidential Office convened an emergency cybersecurity meeting, and the government raised the cybersecurity alert level.
In addition, according to reports, almost all official websites of North Korea, including official media and government portal sites, have been offline for more than 24 hours, and it is not yet known whether this is related to the vulnerability incident.
Impact on Web3
This is not an issue that concerns only traditional website operations and maintenance. For Web3, even if on-chain contracts have no vulnerabilities, the large number of "off-chain components" surrounding contract operations, including front-end pages, APIs, custodial wallets, signing services, airdrop claim pages, operations backends, and data services, are often built with PHP (WordPress, WooCommerce, Magento, etc.). The absence of vulnerabilities in the contracts themselves does not mean these components are secure.
According to statistics from MistEye, the threat intelligence system under SlowMist, among the 1,488 crypto industry-related domains it scanned, 793 had direct PHP fingerprints, approximately 53.3%. It should be emphasized that this only indicates that PHP is used, and does not mean these websites have vulnerabilities or have been compromised.
1. Platform side: Several typical risk paths
Frontend tampering to trick users into signing.
If the servers of DeFi, wallet-type websites, or airdrop pages are compromised, attackers can replace the RPC addresses, authorization targets, contract addresses, or signing prompts on the page, turning a normal transaction into a malicious authorization, malicious contract interaction, or fake deposit process. Attackers do not need to breach the contract; they only need to make users sign a malicious authorization themselves.
Key and credential leakage.
After a server is compromised, attackers may read configuration files, database passwords, API tokens, environment variables, and more. If the backend uses PHP to connect to node RPC or hot wallet services, once API keys or session tokens leak, this can escalate to hot wallet assets being transferred or signing permissions being abused.
Backend and API takeover.
Trading platforms, NFT marketplaces, cross-chain bridges, payment gateways, and node service providers usually have operational backends, as well as KYC/risk control interfaces, deposit address allocation, withdrawal review, ticketing systems, and more. After obtaining permissions, attackers may tamper with configurations, steal user data, create high-privilege accounts, or bypass business processes.
Lateral movement through the supply chain.
The privileges of a PHP process usually do not equal the highest privileges on the server, but if it can read CI/CD keys, container runtime sockets, database credentials, or cloud access tokens, the scope of attack may expand from a single web node to databases, build systems, or even the entire production account.
Payment plugins and third-party services.
It is understood that crypto payment solutions such as Binance Pay, Crypto.com Pay, BitPay, CoinGate, and CoinPayments all have WooCommerce integrations, and unpatched servers carry severe exposure risks. Third-party services such as RPC, block explorers, and data analytics platforms may also become entry points if their backends or operations systems run on affected PHP environments. Of course, RPC nodes, smart contracts, block explorers, and wallets themselves do not inherently depend on PHP; it depends on the specific product's tech stack.
However, it is important to note that a compromised server does not necessarily mean on-chain assets have been stolen. From a web service breach to actual financial loss, it depends on whether attackers can access sensitive credentials, signing processes, administrative privileges, or user interaction points. Whether hot wallets are isolated from the web layer, whether keys are stored in HSMs/KMSs, and whether permissions are minimized directly determine the upper limit of potential losses.
2. Regular users: Should you withdraw your coins?
No need.
The reason is simple:
This vulnerability affects server environments that meet specific conditions; it does not mean all users' wallets are at risk.
Browsing a website and connecting a wallet is not the same as private key exposure. The vulnerability itself cannot directly crack users' wallets or signatures.
The fact that a project may use PHP does not mean it has already been compromised. There is no reason to assume every trading platform has been breached, let alone to withdraw all assets because of this. What users truly need to watch out for is whether the websites they visit have been compromised. Users cannot determine whether a website has been patched, so this incident serves as a reminder: do not blindly trust website interfaces. Attackers may also exploit public attention to spread fake login pages, fake compensation portals, and malicious wallet connection requests.
If a project officially confirms that its website or backend has been compromised, users should follow the disclosed actual impact to decide whether to pause interactions, check for abnormal transactions, and revoke suspicious approvals. If it is confirmed that signing private keys or seed phrases have been leaked, it must be handled as a key compromise incident—merely changing passwords or disconnecting from the website is not enough. Users of trading bots, automated execution tools, or cloud deployment services should also pay attention to whether relevant services have released affected versions or credential rotation notices.
How to respond
1. Platforms and project teams:
Step one: Take stock of your assets and upgrade as soon as possible
Inventory all public and internal network PHP assets: hosts, container images, Kubernetes workloads, legacy CMS, admin backends, partner-hosted environments, third-party plugins, and managed services. Technical fingerprints can only serve as clues and cannot be directly treated as a conclusion of "confirmed vulnerability."
Upgrade to 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, or apply the equivalent patches provided by distributions, cloud providers, or managed service providers. For those using 8.1 and earlier versions, request a backport from the vendor or migrate as soon as possible. Neither "the legacy environment is stable" nor "the application is rarely updated" can reduce the risk of this vulnerability.
After upgrading, rebuild container images, perform rolling restarts or replace all PHP worker processes, and verify the runtime version actually handling requests in production—not just the version on the build machine or command line.
Step 2: What to do if you can't upgrade for now
First, reduce the exposure surface to buy time, but this cannot replace patching:
Isolate PHP applications exposed to the public internet, or add network authentication and access control at the ingress layer.
Disable unnecessary file uploads, and reject unneeded multipart/form-data requests at the WAF or web server layer.
Some security recommendations also include: setting memory_limit=-1, disabling session.upload_progress.enabled, and on PHP 8.5, additionally disabling fatal_error_backtraces. These configurations have business and availability side effects; test them first, and restart all PHP workers after each change.
Step 3: Check for compromise and rotate credentials
For affected services that were once exposed to the public internet, investigate using logs, endpoint monitoring, and anomalous network connections—for example, PHP processes suddenly spawning system commands. If suspected compromise is found, preserve evidence first, then handle it according to the incident response process.
Assume the worst case: for servers that were not patched in time, rotate API keys, session keys, TLS certificates, database passwords, cloud access tokens, CI/CD credentials, RPC/API keys, webhook secrets, and third-party tokens, and check for any anomalous usage records.
If a confirmed compromised software version has been installed or run in the environment, upgrading or reinstalling alone does not prove the risk has been eliminated; you must also investigate credential leakage and persistence backdoors, and if necessary, rebuild a clean environment.
Step 4: Secure the asset control plane
Patching PHP should not be the only action. More importantly, ensure that "a compromised web machine will not drag down the fund system":
Completely isolate the private keys of hot wallets, collection wallets, and critical signing services from web nodes. Use HSMs, MPC, dedicated signing networks, or least-privilege KMS policies.
Place web services, signing services, on-chain nodes, databases, and build systems into different network segments and identity boundaries.
During incidents, temporarily tighten high-risk operations such as withdrawals, address whitelist changes, admin privilege escalation, API Key creation, and risk control rule modifications, enabling manual review or delayed activation when necessary.
For services that execute automatically on-chain, adopt independent signing, multi-signature approval, transaction amount limits, and emergency shutdown mechanisms based on business needs.
Check website static resources, JavaScript packages, reverse proxy configurations, DNS/CDN rules, and transaction construction services to confirm that no malicious scripts have been inserted or replaced.
2. Ordinary users:
Use official entry points: Recently, try to access platforms through bookmarks or official channels, and be wary of any links sent under the guise of a "security incident."
Don't just look at the domain and interface: Even for familiar dApp domains, page scripts, transaction parameters, and RPC configurations may have been replaced by intruders on the server side.
Verify item by item before signing: The receiving address, the chain, the approval amount, the contract being called, and the transaction simulation results. Be especially careful with approve and setApprovalForAll, and be even more cautious with unlimited approval amounts.
Be wary of "compensation," "migration," and "re-verification": During incidents, prompts such as "re-login," "re-verify wallet," "migrate assets," and "claim compensation" may appear. Do not act solely based on in-site pop-ups; cross-verify through multiple official channels of the project.
Layer your assets: Use hardware wallets for large holdings, separate limited-capacity wallets for daily interactions, and regularly clean up approvals. This way, even if a frontend or platform is compromised, any single loss has a cap.
Stop first when something looks off: If you encounter unusual signature requests, unexpected approval prompts, or suspicious website behavior, pause first and verify through official channels.
Final thoughts
Login-free remote code execution vulnerabilities like PHP2Shell, once they break through the Web layer, can turn traditional server intrusions into frontend poisoning, identity impersonation, abuse of signing permissions, hot wallet risks, and even lateral movement at the supply chain level.
For platforms, three things are top priority: upgrade to patched versions, isolate legacy environments that cannot be patched for now, and audit keys and asset control planes. After upgrading, treat hunting for signs of intrusion as part of incident response. For users, during this period, trust the page interface a little less blindly and take an extra look before signing every transaction. But don't panic excessively either: a vulnerability existing does not mean assets are necessarily threatened; a server compromise does not necessarily lead to on-chain fund losses. What really determines the scale of risk is which credentials attackers can obtain, how much privilege those credentials carry, and how quickly the project can isolate and revoke those permissions. For Web3 projects, security building is not just about finding ways to prevent attacks from happening, but also considering: when a component is truly compromised, can the impact be confined locally so that risk does not spread to core business and asset operations.
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
