PHP Security Patches Are Out. Why Sites Still Need a Server Check

The PHP security update fixes two critical vulnerabilities, but a release announcement does not mean every website is protected. The immediate question for organisations is whether every internet-facing server, hosted service and bundled product is now running a fixed build.

What does the PHP security update fix?

The PHP development team says two flaws can, in certain conditions, let an unauthenticated attacker run code on a server. The vulnerabilities are CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on the CVSS v4 severity scale. PHP’s advisory says the risk is highest for Apache installations using mod_php, where a demonstrated exploit can trigger before application code runs.

PHP powers server-side functions on websites and web applications. A successful attack could therefore compromise the server behind a site, rather than merely change what a visitor sees in a browser. The advisory describes technical conditions in memory handling and request state; it does not mean that every PHP site has been breached.

Which versions are fixed, and who still needs to act?

PHP’s current fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The project says all PHP installations serving web requests should be updated. Organisations using Linux distributions, long-term support packages, managed hosting or software that bundles PHP need to check the relevant supplier’s patched package, because the version number and update route can differ.

Older PHP branches need extra care. PHP 8.1 and earlier no longer receive standard updates from the PHP project, though some operating-system and long-term support vendors may provide backported fixes. Administrators should confirm the vendor’s specific security notice and whether that fix is installed; simply seeing an older major version does not prove that a backport is absent.

Why a patch being available is only the first step

The UK National Cyber Security Centre says organisations should identify PHP across their infrastructure, prioritising systems exposed to the internet, and update to a fixed version. That inventory needs to include forgotten test servers, appliances and third-party services, not only the main website. A hosting provider may have to apply the change for customers, while a business running its own stack will need to schedule and verify it.

If an update cannot be applied immediately, the PHP Foundation lists temporary measures that reduce exposure to particular attack paths. It stresses that these measures do not make an installation safe; an update is the complete fix. The NCSC says organisations unable to update should use the temporary mitigations, and consider taking a system offline if they cannot apply them quickly. It also advises checking for signs of compromise before or during remediation.

What is known about real-world impact?

Authorities have described urgent patching and precautionary service interruptions, but those steps are not proof that a particular website was successfully attacked. The Associated Press reported that some government services were temporarily limited while organisations worked through updates. Japan’s government said it had received no reports of damage linked to the flaw at the time of its statement.

Cloudflare’s chief executive told AP that the company had seen millions of attempts to exploit the vulnerability after it was announced. That is a reported volume of attempts, not a verified count of successful intrusions. The NCSC says it will continue monitoring for effects on UK organisations. The public evidence cited here does not establish how many servers remain exposed or whether a specific breach came from these flaws.

What should website users do?

Visitors generally cannot install a server-side PHP patch themselves. If a public service is temporarily unavailable, check that organisation’s official status page or announcements. Website owners and administrators should ask their host or technical team which PHP runtime is in use, which fixed release or vendor backport was installed, and whether the running service was restarted and checked afterwards.

For personal account protection more broadly, CrispNG’s guide to practical cybersecurity habits covers steps such as using unique passwords and enabling two-factor authentication. Those habits do not repair a vulnerable server, but they can reduce other common account risks.

Sources and guidance

• PHP development team: security advisory, affected configurations and fixed versions
• UK National Cyber Security Centre: actions for organisations and incident checks
• PHP Foundation: how the vulnerabilities were investigated and fixed
• Associated Press: government service interruptions and response updates