PHP Security: Critical CVEs of October 2026 for Business

What the October 21 PHP Releases Fixed

The PHP security team pre-announced a critical release on October 20 and published PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 on October 21. The two vulnerabilities affect the core interpreter and can enable remote code execution. In the most exposed configuration, the attack starts before application code runs. PHP states that no complete workaround exists, making an installed security fix essential.

The PHP Foundation's release explanation describes the vulnerabilities and the project's response. The official PHP release advisory provides the upgrade guidance.

Two Memory-Safety Failures in Request Handling

• CVE-2026-109618: PHP enforces memory_limit through longjmp(), which abruptly interrupts execution. Request data, such as a multipart upload, may be only partly initialized when this happens. Cleanup can then operate on uninitialized memory containing attacker-controlled values.
• CVE-2026-109619: internal state belonging to one request can survive after its underlying memory has been freed. A later request handled by the same worker may use that stale state.

According to the PHP Foundation and php.net, the demonstrated attack paths differ by configuration. For CVE-2026-109618 on Apache with mod_php, an unauthenticated request can trigger the flaw before any application code runs, and full remote code execution was demonstrated with default settings. On PHP-FPM, remote code execution was confirmed through application-level code paths, so exposure depends on what the application does. For CVE-2026-109619, a use-after-free and a worker crash were confirmed, and the reporter demonstrated remote code execution against a real-world application on Apache with mod_php.

php.net lists every PHP installation serving web requests as at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, and considers mod_php the highest-risk setup. None of the publications cited here describes a single exploit that works identically against all of these configurations. All of them need the fix, but the published evidence does not show the same attack path for each.

Application login checks cannot protect request processing that happens before the application starts. A vendor product can also contain an affected PHP runtime even when customers never see PHP in its interface.

Affected and Fixed PHP Branches

Source-only backports were made available for PHP 7.4, 8.0 and 8.1, without official binaries. Linux distributions and long-term-support vendors received patches in advance. A distribution may backport a fix without adopting the upstream release number, so its package advisory matters.

Exploitation Evidence Remains Time-Sensitive

At public release, the PHP Foundation said it had not identified a functional exploit. The Dutch government separately reported no signs of active exploitation when announcing its shutdowns. Neither statement establishes that exploitation was impossible elsewhere or later.

CERT-EU subsequently described circulating technical details and initial proofs of concept. Security vendor watchTowr reported exploitation activity in its honeypots from October 21, while Brandefense reported no confirmed exploitation that day. These reports describe different observations and do not establish mass compromise of PHP systems.

Why a Precautionary Outage Can Be a Defensible Decision

Temporarily removing an exposed service reduces opportunities to exploit an unpatched runtime. The Dutch shutdowns illustrate a deliberate availability trade-off while teams assessed and addressed the vulnerabilities. A shutdown announcement alone says nothing about whether an attacker succeeded.

The following official notices document precautionary action on October 21. Times are publication times in the Netherlands, CEST, rather than verified start times for each outage.

The UK NCSC alert recommends identifying PHP deployments, updating them and considering taking systems offline when immediate remediation is not possible. CERT-EU and the FBI Cyber Division likewise recommended isolation or shutdown when patching could not proceed immediately.

The University of Washington's central IT service documented a network-isolation approach on its official service status page: null routing, which discards traffic to systems still running vulnerable PHP. The systems kept running, with data and configuration unchanged, but stayed unreachable until patching was verified. Owners had to provide identifying details and their patched PHP version before isolation was lifted.

For business owners, the decision should compare the cost of a controlled interruption with the consequences of leaving a vulnerable service reachable. Network isolation can preserve the running system for investigation, but customers still experience an outage.

From PHP Code Execution to a Wider Compromise

The vulnerabilities directly enable code execution within an affected PHP process. Access beyond that process depends on its effective permissions and network reach. Secrets theft, lateral movement and ransomware are possible downstream scenarios, not confirmed outcomes of these disclosures.

Consider a conceptual path through an exposed customer portal. An attacker gains execution as the PHP service account, then reads configuration files that account can access. A readable .env file might contain a database password, which could allow access to customer records if the database accepts connections from that server.

The path could extend to cloud services or other systems only where available credentials and permissions permit it. This movement from an initially compromised system to another is called lateral movement. It is not an automatic consequence of PHP remote code execution.

The conceptual blast radius below shows the same path as a chain. Each step depends on a separate condition and does not follow automatically from the previous one.

The next table maps each attack surface to its possible business impact and the safeguards that limit it.

Secrets management reduces uncontrolled copies of credentials, but a secrets manager cannot hide every secret from a process legitimately authorized to retrieve it. Short-lived credentials and narrow permissions limit what stolen access can do. Network segmentation and outbound-traffic controls restrict where a compromised process can connect.

Our engineering position is straightforward: patching PHP closes the identified runtime vulnerabilities. Application code, dependencies and infrastructure still need their own security controls.

The Business Cost Starts Before a Breach Is Confirmed

An emergency PHP update can create costs even when no intrusion occurred. Teams must assess exposure, arrange changes and investigate uncertainty while keeping customers informed. A security incident response plan should define who makes those decisions before an emergency begins.

For an ecommerce website, a controlled outage can interrupt checkout and order processing. In an ERP or trading system, the recovery decision must also consider pending transactions and reconciliation. Restoring HTTP responses does not prove that business records remain consistent.

If exploitation occurs, the consequences can extend beyond downtime:

• Code and intellectual-property theft can expose proprietary business logic.
• Client data leaks can trigger investigation, contractual disputes and notification duties.
• Unauthorized record changes can undermine balances, inventory or order status.
• Stolen deployment access can spread the incident through a software supply chain.
• Data theft or destructive access can enable extortion and ransomware.

Customer acquisition also needs coordination. After a prolonged outage, teams may need to check search visibility and pause paid campaigns that send visitors to unavailable pages. These operational consequences belong in the communication plan alongside technical recovery.

Clients need to know whether their service is affected, who owns the response and when to expect another update. Silence leaves them unable to manage their own commitments. Supplier due diligence should therefore assess communication and incident ownership as well as technical controls.

GDPR Data Breach Notification Depends on Evidence, Risk and Role

A vulnerable PHP version or precautionary shutdown does not by itself establish a personal data breach. GDPR imposes ongoing security duties, while breach notification depends on an actual personal data breach and the applicable risk threshold. NIS2 and DORA require separate scope assessments.

The following is operational guidance, not legal advice. Involve legal counsel and your data protection officer when assessing an incident.

GDPR Security Duties and Notification Triggers

The GDPR sets several relevant ongoing obligations:

• Article 5(1)(f): protect the integrity and confidentiality of personal data.
• Article 24: implement and demonstrate appropriate controller measures.
• Article 25: apply data protection by design and by default.
• Article 32: maintain security appropriate to the processing risk, including resilience and restoration capabilities.

Timely, risk-based patching supports these duties. Discovering an unpatched runtime requires action and assessment, but it does not automatically require a GDPR data breach notification.

Under Article 33, a controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach. The exception is where the breach is unlikely to create a risk to individuals' rights and freedoms. Article 34 generally requires communication to affected individuals when a breach is likely to create a high risk, subject to its exceptions.

A breach can concern confidentiality, integrity or availability. Investigations should therefore assess unauthorized changes and loss of access to personal data as well as theft.

A provider acting as a processor must notify the controller without undue delay after becoming aware of a personal data breach. The controller assesses its regulatory notification duties. A development or hosting provider's role depends on the actual processing arrangement, and the DPA should specify notification and assistance procedures.

Sector Rules and Security Frameworks

NIS2 establishes cybersecurity risk-management and incident-reporting duties for entities within its scope. Applicability depends on sector and other qualifying criteria under the relevant national implementation. It is not a universal obligation for every PHP operator.

DORA addresses ICT risk management, incident reporting and third-party ICT risk for covered financial entities. FinTech and trading businesses must assess their regulatory status rather than assume that their technology category determines coverage. Their ICT suppliers can also face contractual requirements arising from those obligations.

ISO 27001 and SOC 2 provide structures for demonstrating security controls. They are not universal statutory requirements, and neither replaces evidence that a particular runtime was patched. Webdelo does not hold ISO 27001 certification or a SOC 2 attestation.

Where Patching Responsibilities Belong

• SLA and SOW: define runtime ownership, support coverage, response targets and change responsibilities.
• DPA: defines processor notification, cooperation and assistance duties.
• Audit provisions: establish what records and supporting evidence customers can request.
• Incident playbook: names decision-makers for isolation, restoration and customer updates.

A common gap is a delivered application with no agreement covering runtime maintenance. The customer may assume the developer handles it while the developer assumes hosting is outside scope. That ambiguity should be resolved before the next security release.

Webdelo publishes its own service level agreement for support and maintenance as one example of how such a boundary can be described. It separates application code and deployment, which are our responsibility, from customer-managed infrastructure. It also states that customers are notified about high-risk vulnerabilities before exploitation is confirmed. The binding terms for each project are set out in the SOW.

How Webdelo Responded

As soon as news of the vulnerabilities emerged, our Software Development Department started an information campaign covering all clients we serve. For projects where Webdelo was responsible for technical support and ongoing development, our team completed the necessary PHP core upgrades to patched versions.

We informed every serviced client because responsibility for infrastructure differs between projects. Clients needed to determine whether PHP was present and who would act. The scope of our communications was broader than the scope of systems we maintain.

Runtime ownership belongs in the same operational discussion as deployment and hosting. Webdelo DevOps and Infrastructure is relevant to that discussion. Ongoing support reduces uncertainty because the team already knows the stack and deployment context.

After a runtime change, a CRM system may need its business workflows revalidated. A corporate website may need checks on lead forms and connected services. The validation scope should follow the product's actual business functions.

Our technical leadership includes Webdelo CTO Andrew Popov. For customers, the useful governance question is whether technical ownership remains clear after delivery. That responsibility should be explicit when agreeing on web development and subsequent support.

The completed PHP upgrades describe a specific maintenance action. They are not a claim that every product component is invulnerable or that no compromise could have occurred before patching.

A Patch Management Process With Named Owners

Prioritize exposed PHP runtimes, install a fixed release or verified vendor build, and isolate systems that cannot be patched promptly. Then validate the running environment and investigate relevant indicators. This vulnerability management process needs both technical owners and a business decision-maker.

1. CTO or infrastructure lead: establish exposure. Inventory internet-facing applications first, then internal services and vendor products that bundle PHP. Include containers and PHP-based applications such as WordPress, Drupal, Nextcloud and phpMyAdmin.
2. Operations lead: verify the runtime serving requests. Check installed packages and the active web-serving PHP runtime. Inspect the distribution or vendor changelog for backported fixes. A hidden or outdated HTTP banner does not establish patch status.
3. Engineering lead: deploy the fix. Use PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 or a later release containing the fixes, or a verified patched vendor build. Move end-of-life deployments to a supported branch. Review dependencies and apply required security or compatibility updates.
4. Business owner and security lead: contain anything still exposed. Remove unpatched services from public networks or take them offline when necessary. Record the decision owner and remediation deadline. Changing session.upload_progress.enabled is not an adequate substitute for patching.
5. Release owner: validate the change and rollback plan. Restart or replace affected workers and containers so the patched runtime is actually running. Test critical workflows and integrations. A rollback must not silently restore public exposure to the vulnerable runtime.
6. Security lead: preserve evidence and investigate indicators. Retain web server and PHP logs, deployment records and available process telemetry. Examine unexpected shell launches or downloads initiated by PHP processes. Avoid treating either a clean log search or a suspicious request as conclusive by itself.
7. Incident lead: respond to evidence of compromise. Isolate affected systems and investigate reachable credentials and resources. Rotate secrets when exposure is established or reasonably suspected, and revoke affected sessions or tokens. Tighten credential permissions, segmentation and outbound access.
8. Legal and customer owners: report and communicate. Assess regulatory and contractual duties using the evidence and applicable scope. Tell customers what is confirmed, what action was taken and what remains under investigation.

The following command checks the PHP executable in the current shell environment:

php -v

That result may differ from the version used by PHP-FPM, Apache or an application container. Record both the relevant package evidence and the runtime actually serving production traffic. Keep diagnostics private rather than exposing a public phpinfo() page.

Enterprise Vulnerability Management Should Produce Verifiable Records

A reliable partner communicates critical exposure proactively, acts within its agreed support scope and provides evidence of the work. Reassurance alone cannot establish patch status. B2B customers should ask for records that connect the affected environment to the completed change.

• Runtime evidence: the active PHP version or patched package build for each relevant environment.
• Change evidence: patch date, deployment record and validation results.
• Exposure inventory: identified applications and vendor-bundled runtimes, with unresolved items clearly marked.
• Investigation coverage: available logs, retention periods and monitoring limitations.
• Credential decision: whether secrets were rotated and the reasoning behind that choice.
• Responsibility record: named runtime owner and communication consistent with the DPA, SLA and incident playbook.

Warning signs include version claims based only on public banners, no named maintenance owner and statements that patching PHP makes the whole application secure. Another is a partner who cannot distinguish an exposure assessment from an investigation into a suspected breach.

We favor ongoing support because it establishes maintenance ownership before emergency work is necessary. It also gives customers a clearer basis for planning changes and obtaining evidence, without assuming that every incident will be inexpensive or simple.

Discuss a technical security and support review of your business-critical software with Webdelo to clarify runtime ownership, patch verification and incident responsibilities.

A Calm Response Starts With Clear Ownership

CVE-2026-109618 and CVE-2026-109619 require urgent runtime remediation, but their disclosure does not establish that every PHP service was breached. The Dutch shutdowns were precautionary. The business priority is to verify exposure, apply the fix and assess consequences using evidence.

Webdelo informed all serviced clients and completed the necessary PHP core upgrades in projects under our technical support and ongoing development. For every business-critical system, the durable outcome should be clear maintenance ownership, verifiable changes and a communication plan that distinguishes confirmed facts from possible risks.