PHP2Shell Vulnerabilities: Why Digital Asset Businesses Should Pay Attention

PHP has released an emergency security update to address two critical vulnerabilities known as PHP2Shell. Under certain conditions, an attacker could send malicious requests without a website account or password and exploit PHP's request handling to make the server run code of their choosing. This could allow them to read data or change website content. CERT-EU has advised organisations to update affected systems as soon as possible. [1]

“be extra careful visiting ANY web site in the next few days, as some web admins are not always up-to-date with security patches.”

Changpeng Zhao (CZ), Binance founder, X post. [2]

CZ's X post about the PHP vulnerabilities. [2]

For digital asset businesses, the checks should include websites, admin tools and third-party services used in day-to-day operations. These systems may hold customer information or connect to payment and wallet services. A compromise could expose that data or disrupt business operations.

What is PHP2Shell?

PHP is a programming language commonly used to build websites and web applications. When someone submits a form or requests information, a server may use PHP code to process the request and return a response. Websites can also use other technologies, so having a website does not necessarily mean a business uses PHP.

The PHP project's security advisories identify two flaws in the runtime that executes PHP code. CVE-2026-109618 concerns error handling when a request runs out of memory. CVE-2026-109619 concerns internal state that is not properly cleared after a request, allowing a later request to access invalid memory. [3, 4]

Both can lead to remote code execution, meaning the server runs code chosen by an attacker. That code generally runs with the permissions of the account that handles web requests. The consequences therefore depend on which data the account can read, which files it can change and which other systems it can reach.

Why has it drawn so much attention?

The scope of the investigation can be wider than expected. PHP may be embedded in management interfaces, appliances and third-party software as well as websites. In its incident information repository, the Dutch National Cyber Security Centre, NCSC-NL, advises organisations to check these dependencies separately. Some products require updates from their vendors. [5]

Application login controls may not stop the attack. The official PHP security advisory identifies Apache mod_php as the highest-risk deployment, with a demonstrated exploit that triggers before application code runs. Password checks or multi-factor authentication within the application may therefore never get a chance to intervene. The PHP Foundation has also confirmed code execution on PHP-FPM through specific application code paths. Businesses should check that PHP environments serving web requests include the fixes. Exploitation conditions depend on the deployment, configuration and application behaviour. [3, 6]

Attack attempts have also been observed. Amazon Threat Intelligence reported that its honeypot systems detected an attempt as early as October 17, before the patches were released. AWS noted that it was unclear whether those attempts would have succeeded against real-world systems. For businesses, the practical implication is that investigations should look back before public disclosure, while keeping attempted exploitation distinct from confirmed compromise. [7]

Where digital asset businesses should look

PHP2Shell affects the server running a website or backend service. If the web service account can read customer records, access API credentials or modify website files, an attacker could use those permissions to steal data, alter pages or disrupt payment and wallet services. A compromised server does not mean that the cryptography protecting a blockchain or wallet has been broken. [3, 4]

For example, an attacker could replace the receiving address on a payment page with their own. A customer who sends funds to that address would pay the attacker, even if the customer's private key had never been stolen.

On smart contract platforms such as Ethereum, an altered page could also trick a user into signing a malicious transaction or granting a malicious contract permission to transfer specified tokens. These scenarios generally still require the user to make a transfer, sign a transaction or grant an approval. A compromised website alone does not establish that the user's wallet is under an attacker's control. Ethereum.org's security guidance recommends checking recipient addresses, transaction details and contract spending limits. [8]

A breach of an operational backend could also expose stored API credentials, which a system uses to authenticate requests to wallet or payment services. Whether an attacker could use them to move funds depends on the operations they permit and on any independent approvals, address restrictions and signing controls. Credentials limited to reading data pose different risks from credentials that permit withdrawals.

As of October 26, 2026, our review of public disclosures has not identified a digital asset theft that a project operator or security firm has confirmed and explicitly attributed to PHP2Shell. AWS has reported attempts against its honeypots, while noting that it was unclear whether they would have succeeded against real-world systems. [7]

Businesses should check whether their public website is isolated from operational systems, whether service accounts have only the permissions they need, and what their API credentials allow. Independent checks between payment initiation, receiving-address changes and final signing also deserve attention.

Digital asset security reviews should therefore cover both key protection and everyday business systems. Older admin tools, temporary services and externally maintained projects warrant particular attention when they remain operational and can access sensitive information but rarely appear in routine security reviews.

Is Cregis affected?

Cregis’s systems and official website are unaffected by the PHP2Shell vulnerabilities.

How businesses should respond

Identify where PHP is used and who maintains it. Include public websites, content management systems, internal admin tools, container images and third-party products. For each service that may use PHP, establish its runtime version, internet exposure, maintenance owner and update source. Ask external developers and hosting providers to confirm their exposure and remediation progress. The NCSC-NL recommendations specifically call for separate checks of third-party images and embedded runtimes. [5]

Patch the PHP runtime and verify that the fix is active. PHP has released versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12 with fixes. Install the appropriate fixed release for the branch in use, or a vendor package that explicitly includes the fixes. Updating a website plugin or business application alone may leave the underlying PHP runtime unpatched. For branches outside official support, confirm whether a vendor offers backported fixes or plan an upgrade. The official update guidance explains the available routes. [9]

Reduce exposure if an immediate update is not possible. CERT-EU advises organisations to consider isolating affected internet-facing applications from public networks until fixes are applied and verified. Access restrictions, firewall rules and configuration changes can reduce exposure to some attack paths, but a complete fix still requires an update. Temporary protection alone is not a reason to close the issue. Follow the official security guidance and assess the operational impact of each measure. [1]

Investigate suspicious activity alongside remediation. For systems with confirmed exposure, preserve and review request logs, unexpected processes and file changes. AWS recommends looking back to at least October 17. If suspicious activity is found, investigate whether service accounts or related credentials were accessed and follow the incident response process. Installing an update alone does not resolve a possible earlier compromise. The AWS response guidance provides investigation pointers. [7]

Protecting digital assets also means maintaining the business systems connected to wallets and payment services. Keeping those systems up to date and limiting what they can access helps reduce the impact of a website or backend breach on customer data and financial operations.

References

[1] CERT-EU. Security Advisory 2026-018: PHP vulnerabilities.

[2] Changpeng Zhao (CZ). X post on PHP vulnerabilities, October 2026.

[3] PHP. RCE via OOM corruption (CVE-2026-109618).

[4] PHP. RCE via stale global state (CVE-2026-109619).

[5] NCSC-NL. PHP2Shell incident information repository.

[6] The PHP Foundation. Today's PHP Security Release, and How We're Strengthening PHP Security.

[7] Amazon Threat Intelligence. Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot.

[8] Ethereum.org. Ethereum security and scam prevention.

[9] PHP. News Archive 2026: PHP security announcements.