Cyber expert warns businesses to act now over critical PHP security flaws or risk further attacks

Zain Javed, director of strategic growth & cyber services at Citation Cyber , examines the risks posed by critical PHP vulnerabilities that could leave organisations exposed to remote attacks.

“The concern here is not simply that PHP is widely used. It is that the vulnerabilities sit within PHP itself and can, in certain configurations, allow an unauthenticated attacker to execute code remotely on the server.

“That potentially gives an attacker a route into the underlying server without first needing a username, password or legitimate account.

“For organisations running internet-facing PHP systems, the priority should be to identify exactly where PHP is being used and get the security updates applied as quickly as possible. The NCSC’s advice is very clear that where organisations cannot remediate immediately, taking the affected service offline should be considered.

“That might sound extreme, particularly for organisations providing public services, but sometimes the security decision is between temporarily losing availability and potentially giving an attacker control of a server. In that situation, taking a service offline can be the responsible decision.”

Why is this vulnerability so significant?

“The scale is what makes this particularly concerning. PHP sits behind a huge number of websites and applications, including platforms such as WordPress, Drupal and Joomla, as well as many bespoke applications that organisations may not even realise are running PHP underneath.

“The challenge for security teams isn’t just pressing an update button. It is knowing where every instance of PHP exists across the organisation, including old websites, legacy systems, development environments, hosting platforms and third-party products.

“That asset visibility problem is often where organisations get caught out. You cannot patch something you don’t know you have.”

Should organisations be concerned that attacks are already beginning?

“Organisations should absolutely be concerned these types of attacks. Once details of a critical vulnerability and a working exploitation technique become public, attackers will start scanning the internet very quickly looking for systems that have not been updated.

“We have seen this repeatedly with high-profile vulnerabilities. The window between disclosure and mass exploitation is getting smaller.

“Organisations should therefore not only patch, but also review logs and monitoring from before the update was applied. Patching closes the vulnerability going forward, but it does not tell you whether somebody exploited it yesterday or earlier the same day.

“Security teams should be looking for suspicious requests, unexpected processes, newly created accounts, unusual outbound connections and any other signs that a server may already have been compromised.”

What does the AI element of this discovery tell us?

“For me, this is probably the most interesting part of the story. These flaws had reportedly existed within PHP for more than a decade, yet frontier AI models helped researchers understand them and develop working exploits far faster than would traditionally have been practical. That is a major shift for cyber security.

“AI isn’t creating vulnerabilities that weren’t there before. What it is doing is dramatically reducing the time and expertise required to find, understand and potentially exploit them.

“The positive side is that defenders have access to the same technology. In this case, AI helped researchers find the vulnerability, work with the maintainers and get a fix prepared before widespread exploitation was known to have taken place.

“The concern is what happens when attackers have exactly the same capability. We could move towards an environment where newly disclosed vulnerabilities are analysed, weaponised and targeted at scale within hours rather than days or weeks. That means organisations need to become much faster at vulnerability management and patching as well.”

What should businesses do now?

“The first priority is asset discovery. Organisations need to identify every internet-facing system running PHP, not just their main website. That includes applications, APIs, old microsites, development environments and third-party products which may bundle PHP without making it obvious.

“Once identified, affected systems should be updated immediately to the patched versions. I would also recommend reviewing logs for evidence of suspicious activity, checking that backups are current and tested, and making sure incident response teams know which systems are affected.

“Where an organisation relies on a hosting provider, web developer or managed service provider, they should be asking them directly whether they are affected and whether the patch has been applied.

“This is also a good reminder that vulnerability management is not simply an IT housekeeping exercise. When a vulnerability can potentially give an unauthenticated attacker remote control of a server, the speed at which an organisation can identify and patch its systems becomes a genuine business resilience issue.”

What does this mean for smaller organisations using WordPress or other PHP-based platforms?

“Small businesses should not assume this is only an issue for large organisations with their own servers. Many SMEs will use WordPress or another PHP-based application but rely entirely on a web agency or hosting provider to manage the underlying infrastructure.

“The important question is therefore: who is responsible for updating PHP? If you don’t know the answer, now is the time to find out.

“Businesses should their hosting provider or web developer and ask whether their environment is affected, what version of PHP is running and whether the security update has been applied.

“For organisations managing their own infrastructure, the patch should be treated as urgent.”

Is taking a website offline an overreaction?

“Businesses naturally don’t want to take websites or public services offline because of the operational and reputational impact. But if you have an internet-facing server exposed to a critical remote code execution vulnerability and cannot patch or properly mitigate it, leaving it online can present a greater risk.

“Taking something offline temporarily while it is secured can be inconvenient. Recovering from a full server compromise, data breach or ransomware incident can be significantly worse.

“The important thing is that this should be a risk-based decision, not a knee-jerk reaction. Organisations need to understand whether they are affected, whether the system is exposed and whether they can safely patch it.”