PHP2Shell and the Binance Hack: What Happened and What Your Business Should Do Now

Two separate events, not one story

Last updated November 2, 2026. Both stories are still developing, so check the primary sources linked at the end.

In October 2026, two security stories collided in the headlines. First, the PHP project released emergency fixes for critical flaws nicknamed PHP2Shell, and Binance's founder warned crypto users to be careful. Then, on October 29, Binance reported a major security incident of its own. It is natural to assume the two are connected. Based on the reporting we reviewed, there is no evidence that they are. Binance's stated cause of its incident does not mention PHP, and the company and BNB Chain said their core systems were not affected by the PHP flaws.

Both events still matter to any business, for different reasons. One is about keeping software patched. The other is about the people and tools around your production systems.

What PHP2Shell is

On October 21, 2026, the PHP project patched two critical vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 on the CVSS v4.0 scale in the PHP project's own notice. According to the PHP project, they allow unauthenticated remote code execution, meaning an attacker could run commands on a vulnerable server through a crafted web request, without logging in.

• Who is affected. The PHP project says all PHP installations serving web requests are affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The highest risk was described for mod_php.
• The fixes. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• Older versions. PHP 8.1 and older no longer get project updates. The project published minimal backports for some older branches, and some vendors backported fixes themselves.
• No complete workaround. The project states that updating is the only safe choice. Interim settings such as limiting request sizes or disabling session upload progress reduce exposure but do not make an installation safe.

Has it been exploited?

Reports differ in strength, so it helps to separate them:

• The PHP project itself described a demonstrated exploit, which shows the bug is practical to use.
• Details leaked before the coordinated release, and proof-of-concept material circulated within days.
• Security vendors reported scanning and exploit attempts against internet-facing servers. In the reports we reviewed, one vendor said it saw failed attempts and no evidence of a successful compromise in the cases it examined.
• We did not find confirmed reports of crypto exchanges or wallets being compromised through these flaws.

The practical reading: attempts are real and automated scanning is likely, so unpatched servers should be treated as at risk even if no breach has been reported.

Why this matters for ordinary websites

PHP powers a large share of the web, including popular content management systems such as WordPress, Drupal and Joomla and shops built on Magento. The vulnerabilities sit in PHP itself, not in a plugin. That means updating a plugin or theme will not fix it. The server's PHP runtime must be updated.

If your site is on managed or shared hosting, your host controls the PHP version, so ask them whether the patched build is in place. If you run your own server or container, you update it yourself. Our comparison of Next.js and WordPress explains the maintenance trade-offs of different platforms.

A checklist for your PHP sites this week

1. Find every PHP site and server you run, including old staging sites, microsites and internal tools that people forgot.
2. Check the PHP version in your hosting panel, server command line or a deployment file.
3. Update to a fixed release (8.5.12, 8.4.27, 8.3.36 or 8.2.35) or the patched package from your operating system or hosting vendor. Restart PHP and the web server afterwards.
4. If you are on PHP 8.1 or older, confirm your vendor has backported the fix, or plan an upgrade. PHP 8.2 also reaches end of life on December 31, 2026.
5. Use interim measures only as a stopgap, such as the PHP project's published settings or a web application firewall. They are not a substitute for updating.
6. Review logs for unusual requests, new files or unexpected processes since mid-October. If anything looks suspicious, treat the server as compromised: isolate it, restore from a clean backup and rotate passwords and keys.
7. Confirm backups work and are stored where an attacker on the server cannot delete them.

What we know about the Binance incident

On October 29, 2026, Binance reported a security incident involving withdrawals from its systems. The details are still emerging, and the figures vary between sources because they measure different things:

• Amount. Reports range from roughly $5.7 billion to about $6.4 billion, depending on whether they describe assets moved, assets affected or assets stolen. Binance has not published a final figure. Some funds have reportedly been frozen.
• Cause. Binance said the incident may have involved a compromised DevOps engineer's laptop, which could have let an attacker reach a service container and submit unauthorised withdrawals. It also said it had found additional points of breach without naming them, and that it found no evidence that wallet private keys were leaked.
• Customers. Binance said it will cover all losses.
• Attribution. Blockchain analytics firms have reportedly attributed the attack to North Korea-linked actors, and at least one outlet reports an FBI alert saying the same. Treat attribution as reported rather than settled until you read the official statements.

We are not able to verify these claims independently, and they may change as investigators trace the funds.

The lesson both events share

Different events, same pattern: attackers rarely break the strongest part of a system. They go after what surrounds it. In the PHP case, that was servers that had not applied a critical update. In the Binance case, Binance's own account points to an engineer's laptop and an internal service. October also saw a run of supply-chain incidents, including a tampered extension in a developer tool marketplace, a package release built with stolen publishing tokens and hijacked automation workflows, according to security roundups.

For most businesses, that translates into a short list of habits:

• Patch quickly and track what you run. You cannot patch what you have forgotten. Set a target for critical fixes, such as 48 hours.
• Treat developer laptops and build systems as production. Use strong multi-factor authentication, disk encryption, up-to-date software and limited admin rights.
• Apply least privilege to people and services. A compromised laptop or container should not be able to move large amounts of value or data on its own.
• Require approval for high-impact actions. Large withdrawals, production deployments and permission changes should need a second person or a second factor. The same principle underpins our AI agent guardrails.
• Control your supply chain. Pin dependency versions, review extensions and plugins, protect publishing tokens and keep secrets out of code.
• Monitor and prepare. Alert on unusual activity and keep a written incident plan, with contacts and a practiced restore procedure.
• Be careful with fast-built code. Software produced quickly without review often skips these basics. See vibe coding versus production software.

Sources and how to get help

For primary information, start with the PHP project's own security announcements at php.net, and Binance's official statements. We drew on the PHP project's notices and on reporting and incident roundups from SafeDep, Cybersecurity News, CNBC and crypto.news.

This article is general information, not security or legal advice for your specific systems. If you would like help checking your websites, patching servers or hardening your build and deployment process, our website development and maintenance team can review your setup and give you a clear action list.