Your website works, customers can still log in, and there may be nothing unusual on the monitoring dashboard. That does not establish whether the PHP runtime behind it is patched against the PHP2Shell vulnerabilities. If you run WordPress, Laravel, an online shop or a PHP customer portal, the urgent question is which PHP build actually handles web requests and who will update it.
Need help now? ObsidianCorps offers immediate PHP patching assistance to businesses in Luxembourg and the Greater Region: exposure checks, security updates, deployment and verification. Request urgent PHP patching help or call +352 691 165 856. Tell us which sites or applications are affected and who manages the hosting so we can establish the next step.
Client status as of 21 October 2026: none of our clients are affected by these vulnerabilities.
PHP2Shell: what was released on 21 October 2026?
PHP released security updates on 21 October 2026 addressing CVE-2026-109618 and CVE-2026-109619, often discussed together as PHP2Shell. The official PHP security announcement describes two critical vulnerabilities that can allow remote code execution without authentication and urges users to update immediately.
CVE-2026-109618 concerns memory exhaustion and invalid request state. When an allocation fails during certain operations, PHP can leave partially initialised data behind; request cleanup can then use that invalid data. The advisory describes conditions under which this can lead to remote code execution.
CVE-2026-109619 concerns stale global state. A worker can retain references to memory belonging to an earlier request after that memory has been freed. A subsequent request handled by the same worker can access the stale state before normal initialisation replaces it. Exploitability depends on reachable operations and configuration.
In business terms, successful exploitation could let an attacker execute code with the permissions of the affected PHP process. Prioritise services with access to customer information, application secrets or business systems. A functioning homepage is not a security check.
Which PHP versions contain the fixes?
The PHP advisories list these first fixed releases for the supported branches. Use these versions or a later release containing the fixes within the same branch; verify separately if moving to another branch.
| PHP branch | First upstream release fixing both CVEs |
|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Distribution and commercial support packages can carry backported fixes without adopting the upstream version number above. Ask for the security advisory and exact package revision covering both CVEs. For Ubuntu, consult the release-specific status for CVE-2026-109618 and CVE-2026-109619; a package being installed is not evidence that its revision includes a fix.
PHP states that PHP 8.1 and older no longer receive regular updates from the project. If you still depend on an older branch, obtain explicit confirmation of vendor coverage or plan an upgrade. Do not treat the absence of an upstream release for your branch as evidence that it is unaffected.
Who should check their systems now?
PHP identifies web-serving installations as at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Its announcement places the highest risk on mod_php, where a demonstrated attack can run before application code. Using PHP-FPM does not remove the need to update.
Our recommended first pass is an inventory by application and owner. Include public websites, administration panels, partner portals, staging systems reachable from the internet and older applications still used by a single department. Ask the person responsible for each service to record:
- The hostname, business purpose and person authorised to approve maintenance.
- The PHP runtime, package source or container image actually serving that hostname.
- The hosting provider or internal administrator responsible for the update.
- The evidence needed to confirm patch completion and the next review time.
This avoids a common ownership gap: the web agency maintains the application, the host maintains PHP, and each assumes the other has handled the advisory. Assign one person to collect the answers and escalate installations whose status remains unknown.
A practical PHP security patch checklist
1. Identify the runtime behind the website
From an administrative shell, these read-only commands help identify the command-line installation:
php -v
php --ini
The PHP command-line documentation explains these options. They report the CLI binary and its configuration. A host can have multiple PHP installations: do not use this output alone to sign off a website running through a different FPM pool, Apache module or container.
Have the administrator map the site to its configured handler and inspect that runtime through the hosting panel or a restricted diagnostic mechanism. Record the package revision as well as the PHP version. Avoid leaving a public phpinfo() page behind after the check.
2. Prepare the change and recovery path
Confirm a usable backup, the application owner and the checks that define a successful update. For a customer portal, those checks might cover login, document access and password reset. For a shop, include the checkout test flow and payment-provider callbacks. Decide how to restrict access if validation fails; restoring an old vulnerable runtime should not silently become the recovery plan.
Where practical, test the patch release on a representative staging environment first. Keep that check focused on the real application and its extensions so emergency work does not turn into an unrelated framework migration.
3. Update every deployed instance
For package-managed servers, install the vendor revision that explicitly resolves both CVEs for your operating system and PHP branch. Check each active pool and application handler. We deliberately recommend a vendor-specific update procedure rather than one universal shell command: package names, repositories and service names differ between installations.
For containers, obtain a base image that contains the fixes, rebuild the application image and replace running containers. Docker documents why images need rebuilding and how fresh base images are pulled. A Dockerfile edit or a successful image build does not confirm what is deployed. Check the running image identity and the PHP build inside each serving replica.
For shared or managed hosting, ask the provider for written confirmation of the patched build for each relevant subscription. If you operate several websites, check the PHP handler assigned to each one; an updated default does not prove that every site uses it.
4. Replace old workers and validate the live service
Arrange the restart or replacement needed to ensure that all web-serving workers use the updated runtime. Coordinate the procedure with your hosting architecture, including multiple nodes and replicas. Then recheck the live handler and perform the agreed application tests.
Retain the advisory reference, package revision or image digest, completion time and validation results in the change record. We recommend recording exceptions separately, with an owner and an explicit decision about continued exposure. A ticket marked complete should mean that the deployed service was verified.
What if you cannot patch immediately?
PHP states that only an update is a complete solution. Configuration changes can reduce particular attack paths but cannot establish that an unpatched installation is safe.
The technical advisories discuss partial measures, including disabling session upload progress for confirmed session-related paths. They also explain their limits: CVE-2026-109619 has other producers and consumers of stale state, and CVE-2026-109618 involves allocation failure paths. Do not translate one configuration suggestion into a blanket declaration that the server is protected.
Our recommendation for a service awaiting a patch is to make a documented exposure decision: restrict access, place it behind an appropriate access boundary or temporarily withdraw it where business operations permit. Ask the administrator to assess any interim configuration against the official advisory and the application. Keep a named owner and a follow-up time until the actual update is verified.
After patching: separate remediation from incident review
Updating closes the documented vulnerabilities in the runtime. It does not establish whether an earlier compromise occurred. If you find unexpected files, unexplained account changes, suspicious outbound activity or other anomalies, preserve relevant evidence and escalate the review. Those observations warrant investigation; they do not by themselves identify either CVE as the cause.
ObsidianCorps can combine application deployment and infrastructure support with security assessment and incident investigation. Agree the operational patch work and any investigation scope so each has a clear owner.
Questions about the PHP2Shell update
Does updating WordPress, a plugin or Laravel fix this?
The affected component is PHP itself. Application updates remain useful maintenance, but obtain confirmation that the underlying PHP runtime contains these fixes. Check both the application and hosting responsibilities.
Is a firewall or WAF enough?
Do not use a WAF rule as the completion criterion. PHP explicitly states that partial mitigations do not replace the update. Keep the runtime remediation open until the deployed fix has been verified.
Can we keep our current supported PHP branch?
The table above lists fixed patch releases for PHP 8.2, 8.3, 8.4 and 8.5. A move to another major or minor branch is not required solely to obtain these fixes if your existing supported branch has a suitable patched release. Check application compatibility and vendor support when choosing the package.
What should we send when asking for help?
Start with the affected domain, hosting provider, known PHP version and any maintenance constraints. A high-level description is sufficient for the first contact. Keep passwords, private keys and sensitive customer data out of the contact form; arrange access through an agreed secure channel.
Get immediate PHP patching help in Luxembourg
ObsidianCorps offers immediate assistance to identify exposed PHP services, apply the appropriate security update, restart or redeploy the affected runtime, and verify application behaviour. We agree access, scope and timing with you before touching production. The practical outcome is a record of what was updated, what was tested and what still needs attention.
For the wider process behind future emergency releases, see our guide to vulnerability management and patch prioritisation. For this PHP security update, request urgent PHP patching assistance or call +352 691 165 856, mentioning CVE-2026-109618 and CVE-2026-109619.
