What PHP has confirmed
On 21 October 2026, PHP announced security releases 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Its notice identifies web-serving PHP installations as at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers mod_php the highest-risk case. This is a runtime issue, so a website’s appearance or a recent content update does not establish that its PHP environment is fixed.[1]
CVE-2026-109618 concerns memory-exhaustion handling that can leave request data invalid. PHP’s advisory describes demonstrated remote code execution against mod_php before application code runs. It also explains why exposure and demonstrated exploitability differ across server interfaces; a configuration without a demonstrated exploit should not be treated as cleared.[2]
CVE-2026-109619 concerns request-owned state that can remain accessible after its memory is freed. A later request in the same worker may encounter it. The maintainers describe several conditions and paths, rather than one universal trigger. Use their advisory to assess the deployed configuration.[3]
Start with a service inventory, not a headline
Kooya’s recommendation: open one response record and list the services your organisation actually operates. Include customer websites, internal portals, staging systems reachable from outside, vendor-managed applications and older sites that still collect enquiries. Record who can change each environment. A marketing team may own the domain while a separate agency controls the runtime.
For a Philippine business working with an outsourced development team, the useful first action is a precise request with a named recipient and a reply deadline. Ask the provider to identify the environment rather than asking only whether the website is “safe.” Treat an unanswered request as unresolved.
- Service and hostname; business owner and technical owner.
- Hosting provider, server interface and currently running PHP build.
- Official release or vendor advisory covering both CVEs.
- Planned change, maintenance impact and verification owner.
Choose the correct update path
PHP directs operators to the fixed releases or their distribution/LTS vendor’s updated packages. Older branches may depend on vendor backports; PHP 8.1 and earlier are outside normal upstream support. A vendor package can carry a backported fix, so obtain the vendor’s advisory and exact package revision instead of deciding from the upstream-looking version string alone.[1]
Kooya’s recommendation: use your existing trusted deployment channel. Record the image or package revision used, the services it reaches, and the person authorising the change. Check that future deployments will also use the fixed build; changing a running machine while leaving an old deployment image in place can undo the work later.
Keep a recovery plan that preserves the security fix. If a business function fails after updating, investigate compatibility with the provider rather than silently restoring an exposed runtime. Record any temporary service restriction and how customers will be informed.
Verify the service that handles real requests
Kooya’s suggested acceptance record should show three separate things: the corrected build is installed, the serving processes have been replaced or restarted as required by the deployment method, and the business functions still work. A successful installation message answers only the first question.
Check every replica, pool or host included in the service. A command-line PHP check alone may describe a different binary from the one serving the website. Ask the operator to obtain runtime evidence through an authorised internal method; do not leave a public diagnostic page exposing environment details.
Then test a short list of legitimate user journeys: sign-in, enquiry submission, checkout if applicable, file upload where supported, and scheduled jobs. Record failures and timestamps. These are functional smoke tests, not a claim that the site has undergone a complete security assessment.
- Evidence of the fixed build for each serving environment.
- Restart or replacement completion recorded by the operator.
- Relevant user journeys checked after the change.
- Old deployable images and unpatched replicas accounted for.
If an immediate update is blocked
The maintainers state that updating is the only complete mitigation. Their configuration measures address particular paths and retain limitations. Do not treat a copied configuration snippet as equivalent to a patch.[2]
The stale-state advisory also explains that hiding warnings or disabling their display does not remove the underlying problem. Its mitigations depend on which path is involved. That is a reason to involve the responsible engineer, not to paste a generic workaround into every site.[3]
Kooya’s recommendation: identify the exact blocker—vendor availability, permissions, compatibility or an unknown owner—and assign an escalation. Consider restricting access to the affected service while the operator resolves it. The decision should account for business impact and technical exposure, with a specific review time. Do not describe a temporary restriction as completed remediation.
Send your hosting provider a concrete request
Use this as a working request: “Please confirm whether this service runs PHP, identify its web-serving build and server interface, and provide the official or vendor advisory showing coverage for CVE-2026-109618 and CVE-2026-109619. Confirm when the update and worker replacement completed, which instances were checked, and any remaining exceptions.”
Ask for a service-specific response. A provider-wide announcement is useful context, but your acceptance record should identify your environment. If the provider manages only infrastructure while your agency manages containers, make the handoff explicit. Kooya’s recommendation is to keep one accountable owner until all exceptions have a disposition.
Use our AI vendor selection guide to make ongoing supplier responsibilities and acceptance evidence explicit.
What the AI connection actually establishes
OpenAI reports that Calif identified a critical flaw using GPT-5.6 Sol through its Patch the Planet initiative, while Wiz independently discovered and reported both vulnerabilities. It says PHP maintainers led the fixes and release, with research and coordination support from partners. This is an attributed account of discovery and response, not evidence that an AI tool automatically repaired every affected site.[4]
Kooya’s analysis: faster discovery makes the path from alert to verified deployment more important. An AI assistant may help organise an inventory or draft a change record, but someone still needs authority over the system, a correct update path and evidence from the running service. Do not send private configuration or logs to an unapproved tool during the rush.
Keep patching and incident assessment separate
This article does not establish whether any particular Philippine organisation has been attacked. A demonstrated exploit in a maintainer advisory is different from evidence of compromise at your organisation. Avoid turning social-media reports into an incident claim.
Kooya’s recommendation: if your team finds suspicious activity, preserve relevant logs and involve its incident-response lead or qualified provider. Updating addresses the vulnerable software; it does not by itself prove that earlier activity was harmless. Keep investigation records separate from the patch-completion checklist, and communicate only what the evidence supports.
After the immediate work, retain the service inventory, fix evidence and unresolved exceptions. Use this response to clarify future maintenance ownership. A useful outcome is a repeatable way to move from a credible advisory to a checked deployment, without relying on whoever happens to notice the next headline.