PHP2Shell: It’s official – CISA confirms exploitation of critical PHP vulnerabilities

The vulnerabilities – known as PHP2Shell and which could lead to unauthenticated remote code execution – were added on 26 October.

“The vulnerabilities affect all PHP installations serving web requests, including Apache with mod_php (Note: PHP considers this highest risk), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed,” CISA said.

“Organisations should immediately update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 to fix these vulnerabilities.”

Cyber agencies from the Five Eyes alliance, including the Australian Signals Directorate’s Australian Cyber Security Centre, have been warning anyone and everyone running any version of PHP to act since the vulnerabilities first emerged last week.

Experts were similarly alarmed, particularly given that around 70 per cent of all websites use some version of PHP, and many installs are likely running on forgotten servers.

“So the question this week is this: do you know where all your PHP is running? If yes, this is an afternoon of updates,” application security firm Detectify said last week.

VIEW ALL

“If no, the risk is in the systems you’ve forgotten: an old marketing site, a hosting control panel, a device with PHP built in. And speed matters more than ever.”

For anyone who has not yet addressed the issue, speed of action may no longer be enough. For its part, CISA has set a three-day deadline for government agencies to patch, a timeline any other organisation, private or public, would be wise to follow if it can.

“Administrators should prioritise upgrading to the patched versions of PHP, including 8.5.12, 8.4.27, 8.3.36, or 8.2.35, depending on their release branch. The reality is that many organisations are likely running older, unsupported versions, which introduces the additional complexity of upgrading applications, addressing compatibility issues, or working with vendors to obtain supported fixes,” Ramy Rahman, senior principal solutions engineer at security governance firm ArmorCode, told Cyber Daily.

“For systems that cannot be patched immediately, compensating controls need to be applied to reduce exposure. This could include disabling vulnerable functionality, restricting access, deploying IPS signatures where available, and monitoring for suspicious activity. If a vulnerable system cannot be adequately protected, taking it offline may be the only responsible option until the risk can be addressed.”

Admins and other security leaders also need to consider any activity that may have occurred prior to PHP’s initial disclosure. Web server logs need to be reviewed, and any unusual PHP child processes investigated.

However, as time goes on, attackers are likely to be well aware of how best to exploit any unpatched system, Rahman warned.

“Some of the initial exploitation attempts appeared premature or opportunistic. We are now entering a period where attackers have had more time to understand the vulnerability, refine their techniques, and identify systems that remain exposed,” he said.

“Any reconnaissance conducted against vulnerable PHP environments last week may already have given attackers a list of potential targets. If those systems are still running the same vulnerable versions, it likely means the organisations either haven’t identified the exposure or haven’t been able to remediate it.

“The advice hasn’t fundamentally changed since last week, but the urgency has. Organisations should assume that attackers are becoming more effective as time passes and that systems left unpatched are increasingly attractive targets.”