Critical PHP Vulnerabilities in October 2026: Is Your Website Really Protected?
Your website works, orders are coming in and nobody is reporting problems. Yet a vulnerable PHP version could expose your application to compromise. The October 2026 security alerts show why simply saying a server is updated is not always enough.
Your website is running perfectly.
Customers can sign in. Orders are coming through. Forms work as expected.
Your IT provider tells you everything is up to date.
But there is one question worth asking:
Which PHP version is your website actually running, and does it include the latest security patches?
Since October 21, 2026, that question has become particularly important.
CERT-FR, part of France's national cybersecurity agency ANSSI, published an alert concerning two critical PHP vulnerabilities: CVE-2026-109618 and CVE-2026-109619.
The identified risk is serious: remote arbitrary code execution under the relevant exploitation conditions.
On October 22, CERT-FR also confirmed that proof-of-concept exploits were known for certain deployments.
This does not mean every PHP website has been compromised. But it does justify checking quickly, especially when the application is accessible from the internet.
Why a Working Website Can Still Be Vulnerable
This is one of the most common misunderstandings in IT.
We assume that a system working correctly is a secure system.
Yet a vulnerability can remain invisible for months.
A website may continue serving pages normally while relying on a component with a security weakness.
PHP is used by many web applications, including WordPress, online stores and custom-built business applications.
And PHP does not always run where you might expect.
It may be installed directly on a server, run through PHP-FPM, integrated with Apache or provided by a Docker image.
Updating the operating system therefore does not automatically guarantee that every PHP instance used by your business has been patched.
Which PHP Versions Are Affected?
According to CERT-FR alert CERTFR-2026-ALE-014, published on October 21 and updated on October 22, 2026, the affected versions include:
Unsupported PHP versions no longer receive security fixes from the PHP project.
However, some Linux distributions provide their own packages with backported security patches. You therefore need to check the package source and exact package revision, not just the version displayed by php -v.
Source: CERT-FR — CERTFR-2026-ALE-014
Five Checks Worth Making
1. Identify the PHP Version Actually Running in Production
On a server, php -v is a useful starting point.
But it shows the command-line PHP version.
It may not be the version used by your web server.
You also need to examine PHP-FPM services, Apache or Nginx configuration and, where applicable, Docker containers.
2. Check Forgotten Applications
Your main website is not always the biggest risk.
An old administration interface, a customer extranet, a staging environment or an accessible subdomain may use a different PHP version.
The objective is to identify every exposed instance, not just the main company website.
3. Verify Which Patches Are Actually Installed
Does a version look outdated?
Check the distribution's security advisories, installed packages and available patches.
In a Docker environment, fixing PHP inside a temporary container is not enough.
The image must be rebuilt, the updated version deployed and the running container verified.
4. Look for Signs of Suspicious Activity
An update fixes a vulnerability.
It does not prove that an attacker has never exploited the system.
If compromise is suspected, HTTP logs, application events, unusual file changes and outbound connections may require investigation.
Running a vulnerable version does not automatically mean a system has been compromised. These are two different situations.
5. Plan the Fix Without Breaking Production
On an e-commerce website or business application, an unplanned update can cause downtime.
Before deployment, prepare a backup, test dependencies, verify critical functionality and establish a rollback procedure.
The objective is not simply to update.
It is to reduce risk without creating a new production incident.
Can a WAF Replace the Security Update?
No.
CERT-FR describes temporary mitigation measures, including restrictions on multipart HTTP requests and disabling a specific PHP feature.
However, CERT-FR does not qualify these workarounds as sufficient protection for every situation.
They are not a replacement for security patches.
A web application firewall may reduce certain exploitation opportunities. It does not guarantee that a vulnerable application is protected.
The Question to Ask Your IT Provider
Instead of asking:
"Is our server up to date?"
Ask:
"Can you confirm every PHP version actually running in production, which patches have been installed and which applications remain exposed?"
The difference matters.
The first question invites a reassuring answer.
The second asks for verifiable evidence.
How Cyberhack Approaches This Type of Risk
A useful technical audit should go beyond running a scanner and handing over a list of CVEs.
You need to know where the vulnerability exists, whether the affected component is actually exposed, which business application is at risk and which fix should take priority.
This is the approach to visibility and prioritisation that we advocate at Cyberhack.
The objective is not to generate more alerts, but to turn technical risks into decisions people can understand and act on.
You can learn more about our approach on Cyberhack Platform.
Conclusion
The PHP vulnerabilities disclosed in October 2026 highlight a simple reality.
An available website is not necessarily a secure website.
And a server described as "up to date" does not guarantee that every application is running patched components.
Start by identifying the versions actually in use.
Verify the patches.
Prioritise exposed services.
And keep evidence of the work performed.
Because when an incident occurs, the question will not simply be whether an update was available.
It will be whether your business had actually checked its exposure.
