PHP Security Update: Fixed Versions and Checks for India Websites

What the critical PHP security update changes

As checked at the start of 22 October 2026 IST, the PHP project’s security announcement lists PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 as the releases fixing two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. The announcement is dated 21 October. These are released fixes, not a rumoured future update or a promise that every hosting provider has already installed them.

The PHP team says the vulnerabilities can allow unauthenticated remote code execution. In plain language, an attacker may be able to make an affected web-serving PHP process run code without first signing into the website. That is why a site owner should treat the runtime update as separate from a normal design, plugin or content update.

This matters to India-based developers, agencies and small businesses using PHP-backed applications on shared hosting, a VPS or managed infrastructure. The country does not change the software flaw; the useful local question is who controls the runtime and can confirm that a vendor-supported fix is actually running. We have not tested an exploit, audited your hosting account or measured a patch’s performance.

The fixed versions, and what their numbers mean

The upstream fixed releases are 8.5.12 for the 8.5 branch, 8.4.27 for 8.4, 8.3.36 for 8.3 and 8.2.35 for 8.2. Compare the complete version, not just the first two numbers. A control panel that says “PHP 8.4” identifies a branch but does not establish that the 8.4.27 upstream fix, or an equivalent documented vendor backport, is active.

An upstream version number is not the only possible evidence. PHP’s official installation guidance explains that Linux distribution packages can contain provider-added patches. The security announcement also says distributions and long-term-support vendors received patches in advance. Ask the provider for its security advisory and exact package/build confirmation rather than automatically labelling a patched distribution package unsafe because its displayed upstream number looks older.

The distinction works both ways: the existence of a vendor backport is not proof that your account has it. Record the provider’s confirmation for the specific server, application and runtime. A generic message saying an update is “available” is different from evidence that it has been applied.

Why this is a runtime issue, not a login-password fix

The official advisory describes one flaw involving corrupted internal state during out-of-memory handling and another involving stale internal state across requests. Those descriptions explain the priority without requiring an exploit walkthrough. Both concern PHP’s own processing of web requests, not merely a weak password in an individual application.

PHP identifies web-serving setups including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed as at risk. Its assessment gives mod_php the highest risk in the demonstrated scenario, but that is not a reason to assume the other listed setups are safe. Use the advisory’s affected scope rather than a reassuring label such as “managed” or “behind HTTPS.”

Changing a password, installing an application plugin or displaying a secure-connection icon does not replace the PHP fix. These are different layers of protection. The current sources do not justify a claim that a particular Indian website has been compromised, and this article makes no such claim.

What to ask your hosting provider before calling the update complete

First identify the runtime that serves the website’s web requests. If an administrator uses a command-line PHP tool for maintenance, its version is not automatically evidence about the separate PHP process serving visitors. Ask your host or developer to confirm the effective web runtime for each relevant site, pool or container, using their authenticated administration tools. Do not expose a public diagnostic page that reveals server details.

Then ask for the exact installed package or build, the applicable vendor advisory covering both CVEs, and confirmation that running services are using that patched build. Follow the vendor’s documented activation or restart procedure through the authorised administrator; merely downloading a package does not prove an already-running process has changed. This guide does not prescribe shell commands or alter anyone’s production server.

Have the responsible operator check the application’s important journeys after the change: sign-in, forms, file uploads if used, and any business-critical workflow. Retain a tested recovery copy before maintenance, but do not regard reverting to an affected runtime as a satisfactory security outcome. If compatibility prevents an immediate fix, escalate to the hosting provider and security team rather than claiming the problem is solved.

End-of-life PHP and the limits of temporary workarounds

PHP’s support page says 8.2 and 8.3 are in security-fixes-only support, while 8.4 and 8.5 remain in active support at this check. PHP 8.2’s security support ends on 31 December 2026. Patching the immediate vulnerability and planning a supported-branch migration are related but distinct jobs. Do not postpone the current fix while treating a future migration as if it were already complete.

The upstream security announcement says PHP 8.1 and older no longer receive routine project updates. It describes exceptional minimal source backports for 7.4, 8.0 and 8.1, and notes that some distribution or long-term-support vendors supply their own fixes. Those exceptional patches do not restore the normal lifecycle of an end-of-life branch. Ask the actual vendor what it supports and plan migration accordingly.

The PHP team states that only an update provides a complete fix; its temporary measures reduce exposure to particular attack paths but do not make an installation safe. CERT-EU recommends urgent patching and, where that is not feasible, considering isolation of internet-facing resources until the fix is applied and verified. Any such operational decision belongs with the authorised provider or security team. We are not reproducing configuration workarounds or exploit details here.

Important Points / Key Information

Use the following checks to separate released software from a confirmed protected deployment.

• PHP’s announcement names 8.5.12, 8.4.27, 8.3.36 and 8.2.35 as the upstream fixes for both CVE-2026-109618 and CVE-2026-109619.
• A branch label such as PHP 8.4 is not a complete patch-level or vendor-backport confirmation.
• Check the actual web-serving runtime, the provider’s package/build evidence and the activation of the patched process.
• A vendor backport can be valid, but must be documented for the exact installed package; do not assume it is present.
• Temporary mitigations are not a complete fix. End-of-life support and migration need separate attention.
• Status here means “upstream fixes released”; this publication does not certify that your host is patched or that your website was attacked.

Examples / Supporting Information

Consider a small-business site in India whose panel shows only “PHP 8.4.” The owner has identified the branch, but still needs the host to confirm either 8.4.27 or a package with the documented equivalent fix for both vulnerabilities, plus confirmation that the web process is using it. The panel label alone cannot settle that question.

Now consider a Linux distribution package that retains an older-looking upstream version while the vendor’s bulletin documents both fixes in its package revision. That evidence should be evaluated against the installed build, not dismissed solely because its version string does not match an upstream tarball. Conversely, a bulletin about another package or a pending update is not proof of protection for the site in question. These are explanatory scenarios, not results from hosting accounts we tested.

The current evidence is the PHP project’s security announcement, its changelog and support lifecycle, its distribution-installation guidance, and CERT-EU’s advisory updated on 21 October. The project announcement is dated 21 October while the checked changelog headings show 22 October; we retain that source-date distinction rather than inventing a single exact release time. The patch identifiers agree across the checked documents.

Illustration disclosure: the hero is an original photorealistic AI-generated illustration of generic server-maintenance equipment. It is not a photograph of a vulnerable PHP installation, a real security incident, a hosting provider or a tested product.

Conclusion

The useful response to this PHP security update is evidence about the runtime, not confidence from the website’s appearance. For India website owners, confirm the exact patched build with the responsible host or developer, verify that the running web service uses it, and keep recovery and application checks part of the maintenance process.

The upstream fixes are released, but deployment remains a separate, provider-specific fact. If that fact is not yet established, keep the status unresolved and escalate through authorised support rather than describing a dashboard label or a temporary workaround as a completed fix.