PHP2Shell vs Log4Shell and Heartbleed

Why compare them

Log4Shell and Heartbleed are the reference points people reach for when a new internet-wide flaw appears. The comparison is useful, but only if it changes what you do. PHP2Shell is not Log4Shell and not Heartbleed; the differences determine which inventory you need and which restart step you can forget.

Side by side

The scores are not directly comparable across scoring systems. PHP2Shell’s PHP-assigned CVSS v4.0 score is 9.2; NVD also publishes a v3.1 score for the same records. Log4Shell and Heartbleed use v3.1 in the table above.

What is similar

All three are internet-facing, require no account, and generated rapid scanning after disclosure. All three punish incomplete inventories: a patched application can still depend on an unpatched library or runtime.

All three also produce the same bad shortcut: “the application is up to date, so we are fine.” Log4Shell could sit inside a dependency that the application team did not own. Heartbleed sat in the TLS library below the application. PHP2Shell sits in the PHP runtime below the CMS or framework.

What is different

The patch location is different. Log4Shell is a dependency problem; Heartbleed is a TLS-library problem; PHP2Shell is a runtime problem. Updating WordPress, Drupal or a framework does not update PHP.

The restart requirement is different. Replacing a PHP package while an FPM master or container keeps old workers alive leaves the vulnerable binary in memory. The restart or rollout is part of the fix, not an operational afterthought.

The exploitation evidence is different. Log4Shell had mass exploitation quickly. Heartbleed produced mass scanning and credential theft. PHP2Shell has a KEV listing, a controlled honeypot demonstration and a public lab PoC, but no published victim count or confirmed mass compromise in the sources reviewed here.

The temporary controls are different. WAF rules can block known Log4Shell payload patterns. For PHP2Shell, the vulnerable path can run before application code, so a WAF is not a complete control. The PHP advisory’s interim settings reduce specific paths but do not replace the update.

What the comparison should change

• Inventory the runtime, not only the application. Check the web SAPI, CLI, cron jobs, containers and embedded PHP.
• Ask the vendor for the package revision and restart evidence, not just a version number.
• Treat a backport as a temporary path with a dated upgrade plan.
• Keep patch status, exploitation status and KEV status separate. A KEV listing is not a victim count; a missing victim count is not proof that nothing happened.

The patch tracker has the branch table. The dossier keeps the PHP2Shell evidence boundaries together. The vulnerability library has the Log4Shell and Heartbleed records used in this comparison.