On 21 October 2026, the PHP project released emergency security updates (PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35) to address two critical vulnerabilities collectively referred to as PHP2Shell. Both issues are rated CVSS v4.0 9.2 and can permit unauthenticated remote code execution on PHP installations that serve web requests.

Incident Overview

The vulnerabilities affect the PHP runtime itself rather than a specific application, CMS, or framework. An attacker does not necessarily need a vulnerable WordPress plugin, Laravel route, or custom application sink. The conditions can be reached during PHP’s request initialization, error handling, or cleanup phases—before application-level authentication or validation logic executes. PHP identifies the highest risk with Apache mod_php, where a demonstrated exploit can be triggered by an unauthenticated request before any application code runs. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed deployments are also in scope.

• CVE-2026-109618 — RCE via out-of-memory (OOM) corruption. Out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Subsequent cleanup may treat the incomplete state as valid, enabling memory corruption that can lead to code execution.
• CVE-2026-109619 — RCE via stale global state / use-after-free. Request-owned internal state can survive after its backing memory has been freed. A later request handled by the same long-lived worker may then use the stale reference.

There is no complete configuration-only mitigation. Updating the PHP runtime (or installing a trusted vendor/LTS backport) and restarting all relevant workers is the authoritative remediation. Temporary controls (disabling session.upload_progress administratively, setting memory_limit=-1 in a non-overridable context, restricting multipart POST traffic where file uploads are not required, WAF/request-size limits, etc.) can reduce specific attack paths but do not replace patching.

PHP 8.1 and older are end-of-life and will not receive official upstream fixes. Organizations running those versions must obtain vendor backports or migrate to a supported branch.

Bangladesh National Security Relevance

PHP is widely embedded in government portals, financial services, telecommunications and ICT platforms, health systems, transportation and logistics interfaces, utilities, media, education, and vendor appliances. A vulnerable runtime can convert an otherwise application-level web exposure into server-level code execution with the privileges of the web worker.

Bangladesh’s Cyber Security Ordinance 2025 defines Critical Information Infrastructure in terms of government-declared systems whose compromise can adversely affect public safety, economic security, public health, national security, integrity or sovereignty. Internet-facing PHP systems operated by government agencies, designated CII operators, banks and payment providers, telecom/ISP operators, energy and utility providers, national data centres, healthcare, and other high-impact services should be treated as Priority-0 for assessment and remediation.

This advisory does not assert that any named Bangladeshi organization or website is vulnerable. Establishing vulnerability requires authorized asset inventory, runtime/version verification (including vendor package provenance), configuration review, and—where appropriate—controlled validation in an authorized environment.

Recommended Actions

Organizations should:

1. Inventory all internet-facing PHP runtimes (PHP-FPM pools, mod_php, CGI binaries, containers, appliances, and bundled vendor PHP).
2. Confirm versions and package/backport status using local evidence rather than HTTP banners alone. A version string may not reveal a distribution backport.
3. Patch supported branches to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or the equivalent trusted vendor backport) and restart all long-lived workers.
4. For systems that cannot be patched immediately, reduce exposure with network controls, reverse-proxy/WAF rules, service isolation, and the temporary mitigations published by PHP. Do not treat these as a complete fix.
5. Perform targeted threat hunting on systems that remained exposed after public exploit material became available. High-confidence behavioral signals include PHP workers (php-fpm, php-cgi, httpd/apache2, LiteSpeed, etc.) spawning shells, interpreters, or download utilities; unexpected new/modified files in web roots, upload directories, or temporary paths; and anomalous outbound connections.
6. Preserve relevant logs and telemetry. If compromise is suspected, follow the organization’s incident-response process, isolate as appropriate, and coordinate with national CERT/CIRT functions.

Prioritization Guidance

• P0 (Emergency): Internet-facing PHP + CII / critical service + vulnerable or unknown runtime — patch/contain within hours, hunt for compromise.
• P1 (Urgent): Internet-facing PHP + high-value public/private service — same business day.

Treat unknown patch status as unverified until confirmed. Prioritize services whose compromise could affect national security, public services, sensitive data, or economic continuity.

Configuration changes, worker recycling, and WAF rules may reduce specific risks but are not substitutes for the fixed PHP runtime. Do not conduct exploit validation against government, CII, or third-party systems without written authorization.

BCSI continues to monitor developments related to these vulnerabilities and associated exploitation activity. Organizations are encouraged to revalidate details against the latest official PHP Group advisory and trusted vendor/CERT notices before formal internal circulation.

References (selected)

• PHP Group security advisory and release notices — php.net
• GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp