Critical PHP Vulnerabilities: What Happened and What to Do

Security researchers and monitoring providers have observed active exploitation attempts, but public reporting has not yet identified confirmed victim compromises. Sophos reports no evidence of compromise. Researchers at Previdian say reliable code execution looks harder than first expected. Treat that as borrowed time. Attack volume keeps climbing, and NSA expects attackers to weaponize the flaws.

What CISA Recommends

CISA’s direction is simple and straightforward: patch now. Organizations that can’t update right away should take PHP-based systems offline until they can.

Systems running PHP 8.1 or older require special attention because those branches are no longer supported by the PHP project. Organizations should upgrade to a supported PHP release or verify that their operating system or LTS vendor has provided a backported security fix.

The agencies also recommend these steps:

• Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install the corresponding patched package supplied by your OS or LTS vendor.
• Inventory every system that relies on PHP. PHP often runs inside other software, so start with internet-facing systems.
• Add enhanced logging across your network.
• For systems that were internet-facing while vulnerable, review available web, PHP, EDR and operating-system telemetry for suspicious activity. Patching prevents future exploitation of these flaws, but organizations should separately determine whether a vulnerable system was targeted before it was updated.
• Replace end-of-life PHP services that can’t be patched.
• Use a web application firewall for partial protection until the update is in place.

Configuration changes can close off specific attack paths. PHP is clear that only an update fully fixes the flaws. For the newest flaw, the PHP Foundation advises setting session.upload_progress.enabled to 0 until its next release.

What HBS Recommends

Call your developer or vendor first. Reach out to whoever built or supports the applications and websites on your PHP systems. Ask them to confirm the patched PHP version works with their code. Then have them apply the update or work alongside your IT team while it happens.

Pull exposed systems off the internet until they’re patched. This follows CISA and NSA guidance. Take affected systems offline, or remove their public access, until the update is in place. A few hours of downtime costs far less than a compromised server.

Know why your MSP may not patch this alone. PHP updates can change how applications behave. A site that ran fine yesterday can break after an upgrade. For that reason, many managed service providers can’t safely perform these upgrades without the application or website developer involved.

Your MSP can help identify affected systems, restrict public access and coordinate remediation. Because PHP version changes can affect application compatibility, application owners, developers or software vendors should be involved in testing and approving changes where appropriate.

Get Help from HBS

HBS can help you find the systems running PHP, lock down public access, and coordinate the update with your developers and vendors. Contact HBS today to get your PHP exposure under control.