PHP Vulnerability October 2026: Check and Fix 2 CVEs

Originally published on Sitecheckly.

Two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, are listed by CISA as exploited in the wild. PHP was detected on 23% of analyzed sites in Sitecheckly’s October 2026 survey. Check the PHP version used by your application, compare it with the vendor advisory, and apply the vendor’s fixed release or mitigation. If you suspect compromise, follow vendor guidance and investigate.

For site owners researching a PHP vulnerability October 2026 warning, the important distinction is between detecting PHP and confirming exposure. A technology lookup is a starting point, not a verdict about whether your installation is affected.

What are the two PHP vulnerabilities, and which versions are affected?

Both vulnerabilities allow unauthenticated remote code execution, according to the CISA descriptions with their listings. That makes checking your installation and the applicable vendor guidance a priority.

CVE-2026-109618: PHP memory corruption

CISA describes CVE-2026-109618 as an out-of-memory corruption vulnerability that allows unauthenticated remote code execution. The CVE-2026-109618 NVD entry is a reference point for the vulnerability and its linked advisories.

Affected versions: see the vendor advisory. Do not assume that every PHP release is affected, or that a release is safe because its version number looks recent.

CVE-2026-109619: PHP stale internal request-state

CISA describes CVE-2026-109619 as a stale internal request-state vulnerability that allows unauthenticated remote code execution. Use the CVE-2026-109619 NVD entry to find the relevant vulnerability references.

Affected versions: see the vendor advisory. The survey does not establish affected-version ranges for either CVE.

For fixed releases and any applicable mitigations, start with CISA’s PHP alert and its vendor references. Use the vendor’s current guidance rather than guessing a minimum safe version.

Why does the CISA KEV listing matter?

Inclusion in the Known Exploited Vulnerabilities catalog means there is evidence of exploitation in the wild. These are not simply theoretical flaws awaiting a possible attack.

CISA added both PHP vulnerabilities on 2026-10-26 and set 2026-10-29 as the action deadline for US federal agencies. That deadline is not a universal legal requirement for every website owner. Other owners should assess their exposure and act promptly.

A KEV entry also does not mean your site was hacked. It establishes exploitation of the vulnerability, not compromise of every installation using the software.

For a related reference, see Sitecheckly’s list of PHP vulnerabilities exploited in the wild. Use it to identify advisories to investigate, not as proof that your own application is affected.

How widespread is PHP in the survey?

The October 2026 Sitecheckly survey used the Tranco top 10,000, list 7462X. Its ranking covered 2026-10-02 to 2026-10-31, and home pages were fetched on 2026-11-01. Of 10,000 domains, 4,934 could be analyzed.

The remaining domains were mostly CDN, DNS and API hosts outside the survey’s scope, sites asking crawlers to stay away through robots.txt, or sites blocking automated requests. The PHP usage page documents the survey context and detection results.

PHP appeared on 23% of the sites we analyzed, representing 1,130 sites. This describes detected technology in the survey. It does not establish that those sites:

• Used a version affected by either CVE.
• Were exposed to the conditions described in the vendor advisory.
• Had been compromised.

Do not use the detection figure as a vulnerability rate. To assess your application, you need its actual PHP version and the advisory that applies to it.

How can you check your PHP version?

Start with the application you need to protect. Your goal is to confirm the PHP version it uses, not merely find evidence that PHP exists somewhere in the hosting environment.

Check public information

Look at the page source and response headers for a disclosed PHP version. Treat a missing version as inconclusive: it does not prove that PHP is absent or that the application is safe.

You can also use the free Sitecheckly tech stack lookup to check the entered URL for detectable technologies. No sign-up is required. A public lookup may identify PHP without revealing the installed version.

For a separate check, run Sitecheckly’s passive security audit. It is also free with no sign-up. The security audit is separate from the home page’s combined SEO and AEO audit.

Each run covers one page: the URL you enter. It does not scan the whole site or investigate whether a server has been compromised. Do not treat a public audit as confirmation that either PHP CVE is fixed.

Confirm the application’s assigned version

Check the hosting control panel or application administration panel for the PHP version assigned to the application. If the panel does not show it, ask the hosting provider to confirm it.

Keep the request specific:

• Which PHP version does this application use?
• Does the vendor advisory identify it as affected by either CVE?
• Which fixed release or mitigation applies?
• Has that fix been deployed to this application’s environment?

Do not publish a diagnostic page that exposes server details just to obtain the version. Prefer the hosting panel or direct confirmation from the provider.

Once you have the confirmed version, compare it with the vendor advisory. If you cannot establish the applicable version range or fix, keep the issue open rather than marking it resolved from a public lookup alone.

How do you fix the flaws and respond to a possible compromise?

Use CISA’s PHP alert as the starting point for remediation and follow its references to the vendor’s current guidance. For the exact fixed release or mitigation, see the vendor advisory.

For self-managed PHP

Confirm whether your installed version is affected. Apply the vendor’s fixed release or the mitigation specified for your installation.

Keep a record of the advisory you followed, the change made, and the application environment covered. After the change, confirm the version used by the application and check that the application still works as expected.

For managed hosting

Ask the provider to confirm the applicable fix and whether it has been deployed. A useful response should address your application’s environment, not just say that the provider takes security seriously.

If the provider has not completed remediation, ask what vendor-supported mitigation applies and what you need to do. Do not substitute an assumed safe version for a documented answer.

If compromise is possible

Follow the vendor’s incident guidance. Review relevant logs, preserve evidence, and rotate potentially exposed credentials. Involve the hosting provider or an incident-response team where appropriate.

Do not treat installing a PHP security update as the entire incident response. Keep the remediation task and the investigation task separate: you need to address the vulnerable software and investigate any suspected compromise.

What to do next

• Confirm the PHP version assigned to your application.
• Match it against the vendor advisories for both CVEs.
• Apply or obtain confirmation of the applicable fix.
• If compromise is suspected, preserve evidence and begin an investigation with the appropriate support team.

Frequently asked questions

Does a KEV listing mean my site was hacked?

No. It means there is evidence that the vulnerability has been exploited in the wild, not that every site using the software was compromised.

Is the CISA deadline mandatory for every website owner?

The stated deadline is for US federal agencies. Other owners should assess their exposure and act promptly.

Can the survey tell me whether my site is vulnerable?

No. The survey describes technology detected on sampled home pages; it does not establish the version or security status of your installation.

Is a passive security audit an incident investigation?

No. Sitecheckly’s security audit is passive and checks the entered URL. Investigating a possible compromise also requires reviewing relevant logs and following incident-response guidance.

Want to see how your own site does? Run a free audit at sitecheckly.com.

Figures in this article come from Sitecheckly's own audit data; see the methodology.