Critical PHP Bugs Exploited: CISA Confirms Active Attacks

With two critical PHP bugs exploited in the wild, CISA on Monday gave U.S. federal civilian agencies three days to fix flaws that let an attacker compromise a server over the internet without credentials. TechCrunch reports the pair under the name PHP2Shell. For Cyprus firms running PHP on public sites, the comfortable patch window has closed.

What did CISA confirm about the critical PHP bugs exploited in the wild?

CISA said a pair of critical PHP vulnerabilities is under active attack, after researchers reported evidence of in-the-wild exploitation, and set a three-day deadline for U.S. civilian federal agencies. The PHP project had shipped fixes less than a week earlier. According to TechCrunch, the flaws let an attacker break in remotely, with no password needed.

CISA named no attacker, victim count or sector. Public reporting gives no CVE identifiers, CVSS scores, affected versions or vulnerable component, so read the PHP project’s own advisory before declaring any host clear. The deadline binds U.S. agencies, not a Limassol EMI, but confirmed exploitation moves PHP to the top of the patch queue.

Why did two critical PHP bugs sit unpatched for two years?

The bugs were first found two years ago. The nonprofit foundation that maintains PHP judged there was no practical way to exploit them, so they stayed open. Researchers called building a working exploit initially challenging, but not impossible.

Earlier this year, researchers at a security research firm TechCrunch names as Calif found a way to exploit both bugs with help from an AI model. Models that find flaws and chain them together turn long-deprioritized bugs into working attacks. PHP reportedly runs on about 70% of web-facing servers, yet the decades-old project is described as under-funded, with little money for security reviews.

For risk registers, “hard to exploit” is a judgment with an expiry date. Deferred findings in old pentest reports deserve a second look.

Does this reach Cyprus WordPress, fintech and iGaming stacks?

Yes, wherever an unpatched PHP runtime answers internet requests: WooCommerce shops, broker and CSP client portals, iGaming front ends. Updating WordPress core or plugins does not touch the PHP runtime underneath. On managed hosting, ask the provider for a dated confirmation of the fixed build.

In WordPress and CMS penetration testing we routinely find a staging subdomain or forgotten admin panel on an older PHP build than production. Emergency patching misses exactly those hosts.

Patch, isolate or take the site offline?

Patch today where you can confirm the fixed build; restrict or pull a portal where you cannot. TechCrunch reports that some governments and large companies took sites offline to patch.

• Map the execution path. nginx or Apache, PHP-FPM or CGI, control panels, containers and vendor appliances can each carry a separate PHP runtime.
• Use distribution advisories. Debian, Ubuntu and RHEL backport fixes, so an upstream version comparison can mislabel a patched package.
• Prove the fix is live. A new php -v result says nothing about running FPM workers; see why old PHP workers stay exploitable after the patch.
• Assume exposure. Exploitation was reported within a week of the fix. Preserve web and access logs, look for web shells and new admin accounts, and wait for published indicators.

For the board, the trade is a few hours of portal downtime against a breach that starts GDPR’s 72-hour notification clock and, for NIS2 significant incidents, a 24-hour early warning.

Neither NIS2 nor DORA sets a three-day patch deadline, but both expect documented vulnerability handling. Record when you learned, what you decided, who signed off and the evidence the fix is live. Auditors and any NIS2 penetration testing engagement will ask for that record.

FAQ

What is PHP2Shell?

It is TechCrunch's name for the two critical PHP bugs CISA says are being exploited. CISA did not use the name.

Is there a CVE for the PHP bugs CISA confirmed?

Public reporting gives no CVE identifiers, CVSS scores or affected versions. Check the PHP project's security advisories and your distribution's security tracker.

Does patching WordPress core fix the PHP bugs?

No. WordPress updates change application code, not the PHP runtime; you or your host must update PHP itself and restart the services that serve web requests.

Not sure which of your internet-facing hosts still run an old PHP build? An external network penetration test maps the forgotten ones before attackers do.