Is the PHP Security Flaw Fixed? What Website Owners Need to Know

Two serious security flaws in PHP prompted urgent warnings and updates on 21 October 2026. They can allow attackers to run code on vulnerable servers without logging in.
The fixes are available. Whether your website is protected depends on whether its hosting provider or administrator has actually installed and activated them.
What is PHP, in simple terms?
PHP is a programming language used behind the scenes to make websites work. It runs on the server: the computer that processes visitors’ requests and sends pages back to their browsers.
You might never see PHP, but your website or a service you use may depend on it. The Dutch National Cyber Security Centre warns that PHP is also embedded in network devices, management interfaces and other products.
What happened with PHP in October 2026?
Two vulnerabilities were disclosed: CVE-2026-109618 and CVE-2026-109619.
Both involve mistakes in how PHP manages its working memory. One can occur when PHP runs out of memory. The other involves leftover internal information being used after its memory has already been released.
Under certain conditions, attackers can exploit these mistakes to execute their own code. Both vulnerabilities received a severity rating of 9.2 out of 10.
Can hackers attack without a password?
Yes. The official PHP security advisory confirms that exploitation can happen without authentication.
In a demonstrated attack against one server configuration, the problem is triggered before the website’s own code starts running. That means the website’s login screen cannot stop that particular attack.
Have the PHP security flaws been fixed?
Yes. PHP released four security updates on 21 October:
- PHP 8.2.35
- PHP 8.3.36
- PHP 8.4.27
- PHP 8.5.12
These versions fix both vulnerabilities. Some suppliers also provide packages containing the fixes under different version numbers.
Older installations need particular attention. PHP 8.1 and earlier no longer receive regular PHP-project updates, although some vendors provide extended support.
Does this mean every PHP website was hacked?
No. A vulnerability creates an opportunity for an attack; it does not prove an attack happened.
However, CERT-EU reports that technical details and early demonstrations of exploitation are circulating. That makes prompt action important. Its advisory does not establish how many websites have been compromised.
What should website owners do now?
Ask your hosting provider or administrator to confirm whether your website uses PHP, which security update has been applied, and whether the live service is running the updated software.
Updating a website plug-in alone does not establish that PHP itself has been repaired.
If patching is delayed, temporary settings can reduce some risks, but official guidance says they do not provide complete protection.
The useful question now is: has the fix been verified on the server actually running your website? The existence of an update cannot answer that.
For broader security context, my analysis of the Bybit hack examines transaction approval risks, while my article on OpenAI’s Medicare breach looks at incident disclosure and reporting. These are separate incidents with different causes.
Sources and context
- PHP: critical security advisory and fixed releases (Primary source)
- PHP: CVE-2026-109618 — memory corruption advisory (Primary source)
- PHP: CVE-2026-109619 — stale global state advisory (Primary source)
- CERT-EU: affected versions, risk and recommended action (Primary source)
- NCSC-NL: operational guidance and affected software (Primary source)

