Critical PHP Security Vulnerabilities: Is Your Business Application Protected?

What the NCSC alert actually says

On 21 October 2026, the UK National Cyber Security Centre published an alert about critical security issues affecting PHP. The two identifiers are CVE-2026-109618 and CVE-2026-109619. PHP's advisories rate both critical with CVSS 4.0 base scores of 9.2.

CVE-2026-109618 concerns out-of-memory handling interrupting PHP while internal request data is only partly initialised. Cleanup may then treat invalid data as valid. CVE-2026-109619 concerns request-owned state surviving after its backing memory has been freed, allowing a later request in the same worker to use stale state. Under the necessary conditions, the resulting memory corruption may permit unauthenticated remote code execution.

That description matters. It is not a flaw in one WordPress plugin, Laravel controller or customer's bespoke feature. It is below application code in the runtime. Nor does it mean every PHP site is equally exploitable: build, extensions, server integration, allocator layout and request behaviour affect exploitation. The defensible response is inventory and remediation, not either panic or dismissal.

Which versions need attention?

The NCSC says organisations using any PHP version should assess exposure and update to a fixed release. PHP issued fixes in 8.2.35, 8.3.36, 8.4.27 and 8.5.12. An operating-system vendor may backport a correction while retaining a version string that looks older, so verify the vendor advisory and package changelog rather than comparing numbers blindly.

Support status is a separate issue. At the time of writing, the official PHP support table says PHP 8.2 receives critical security fixes only until 31 December 2026; 8.3, 8.4 and 8.5 have later support dates. PHP 8.1 and older are outside upstream support. Applying an emergency backport to an obsolete branch may reduce the immediate risk without creating a sustainable platform.

Do not limit discovery to repositories named after PHP frameworks. PHP may be bundled into appliances, administration tools, content systems and old internal services. An application inventory that lists products but not runtimes cannot answer the first incident question.

What remote code execution could mean

Remote code execution means an attacker may be able to make the server execute commands without first authenticating. The immediate boundary is normally the web-worker identity, but that is not a harmless sandbox. It may read application configuration, reach a database, call internal services or access credentials supplied to the process.

Impact therefore depends on architecture. Least-privilege database accounts, segmented networks, workload identity and constrained file permissions can reduce movement. They do not make the runtime vulnerability acceptable. Defence in depth limits consequences while the patch process removes the known flaw.

A successful patch also does not evict an attacker who arrived earlier. If an exposed host may have been vulnerable, review evidence for compromise, persistence and credential theft. Rotate credentials based on exposure and findings, not as a ritual that destroys useful evidence before investigation.

A practical response order

1. Find the runtime. Inventory internet-facing PHP first, then internal systems and bundled products. Record the live runtime and server integration, not only a lock file.
2. Establish exposure. Identify reachable endpoints, worker configuration, privileges, data and downstream access.
3. Apply a fixed vendor build. Use the appropriate PHP or platform-vendor update and follow its restart instructions so old workers do not remain live.
4. Mitigate if patching is temporarily impossible. Use only the temporary measures in the PHP advisory and record what each does not protect. A workaround is a time-limited risk decision.
5. Assess compromise. Examine relevant logs, process creation, unexpected files, accounts and outbound activity before declaring recovery.
6. Verify production. Confirm the version actually serving requests, exercise application journeys and monitor failures after rollout.

The NCSC says systems that cannot be updated or mitigated promptly may need to be taken offline. Availability loss is painful, but leaving an exposed route online is also a business decision with potentially larger consequences.

Why patching fails even when an update exists

Teams frequently update a container definition but leave old replicas running, patch command-line PHP while the web server loads another installation, or update a test slot without completing production rollout. Evidence should identify the binary and package used by the live worker.

Compatibility fear creates another delay. If every security update requires a major project, the application has accumulated change risk. Regular servicing, automated tests and reversible deployments keep emergency changes small. Maintenance is therefore a security control, not merely housekeeping.

Shared hosting and managed platforms change who performs part of the update, not who must verify the outcome. Ask what the provider patched, when instances restarted and whether application-owned packages still require action.

Questions to ask your software provider today

• Which production, staging and internal systems run PHP, including bundled products?
• Which live versions and package sources are in use?
• Are they fixed for CVE-2026-109618 and CVE-2026-109619?
• Who monitors PHP, framework and package advisories?
• What is the target time for critical internet-facing updates?
• How is a change tested, deployed, restarted and verified?
• What logs would support a compromise assessment?
• Is the current branch supported after the immediate fix?

“Automatic updates are enabled” is not complete evidence. Automation can fail, be scoped to the operating system only, or defer restarts indefinitely. Ask for the resulting state.

This is not an argument against PHP

Widely used, actively maintained platforms occasionally contain severe defects. PHP's maintainers issued corrected releases and public advisories. That response is evidence of an ecosystem doing necessary security work, not proof that another runtime can never fail.

The broader lesson is ownership. A technology choice creates a continuing obligation to know what is deployed, follow its lifecycle, test updates and respond when maintainers publish a fix. Changing language does not remove that obligation.

Preserve evidence while restoring service

Incident response and patching can conflict. Restarting workers, rebuilding hosts and rotating credentials may remove volatile evidence, yet delaying remediation leaves exposure open. Give one incident lead authority to sequence containment, evidence capture and recovery according to the organisation's risk and capability.

Useful evidence depends on the deployment but may include reverse-proxy and web-server requests, process creation, authentication and cloud-control-plane activity, changed files, scheduled tasks, unexpected accounts and unusual outbound connections. A lack of one log source is not proof of safety. State what was available, its retention and the confidence it supports.

Do not copy untrusted files into normal analysis environments or run public proof-of-concept tools against production. If compromise is suspected and the organisation lacks appropriate capability, the NCSC recommends seeking qualified incident-response assistance. C3 Software does not present this article as incident-response or penetration-testing advice.

After recovery, preserve a timeline: first possible exposure, deployed fix, worker restart, evidence reviewed, credentials changed and service restored. That record supports later decisions and exposes monitoring gaps before the next vulnerability.

Turn this incident into a durable capability

After the urgent work, record runtime and dependency ownership, subscribe to authoritative advisories, define severity-based response targets and rehearse a safe patch. Include unsupported systems in an upgrade roadmap rather than allowing the incident ticket to close over the underlying risk.

Related C3 guides cover security responsibility after launch, identifying unsupported business software and third-party dependency risk.

Measure readiness before the next critical patch

Track the time required to identify affected assets, approve remediation, deploy, restart and verify. Measure internet-facing systems separately because their response target is usually shorter. Record assets whose ownership or version could not be established; uncertainty is a finding, not a reason to exclude them. Review the result with technical and business owners.

Exercise the process with an ordinary servicing update. Confirm that contacts respond, tests provide useful confidence, rollback assumptions remain valid and production evidence can be collected without exposing version detail publicly. A routine update is a safer place to discover that the only deployment account belongs to a former supplier.

Metrics should improve decisions rather than reward volume. “One hundred patches installed” says little if the only vulnerable public server was missed. Prefer coverage, elapsed response and overdue high-risk exceptions, with enough context to prevent teams gaming the number.