On October 21, 2026, the PHP project released emergency fixes for two flaws that can let an attacker take over a web server without logging in. The same day, the Canadian Centre for Cyber Security issued alert AL26-026. Agencies in the US, UK and EU followed with their own warnings.
These PHP critical vulnerabilities nicknamed "php2shell" are not a regular thing. PHP powers almost 70% of sites that have a server-side scripting language. You might still be affected even if none of your team members actually works with PHP. This guide will tell you what happened, who is at risk and what to do first. It is intended for Canadian business owners, IT directors and security managers as well as developers.
What Happened With php2shell
The two vulnerabilities are tracked by the identifiers as CVE-2026-109618 and CVE-2026-109619. The PHP security team scores this issue as CVSS 4.0 score 9.2. Both issues are memory safety bugs in the PHP runtime itself, not in your website code.
CVE-2026-109618: Out-of-Memory Corruption
PHP stops when it reaches the memory limit. If the memory limit is reached at an unexpected time, some internal structures may be left in an inconsistent state. The cleanup code may then assume that this data is valid, possibly allowing an attacker to modify the memory in such a way that will cause it to execute unexpected code.
CVE-2026-109619: Stale Global State
A fatal error may cause PHP to have pointers to memory that has been freed. The next request processed by the same worker thread may access these pointers leading to a use-after-free vulnerability, potentially disclosing memory or allowing code execution.
CERT-EU advisory 2026-018 explains both paths in plain technical detail. The official PHP security advisory remains the primary reference.
Who Is at Risk
Every PHP installation that serves web requests is affected. That includes:
- PHP-FPM
- Apache with mod_php
- php-cgi
- FrankenPHP
- LiteSpeed
The PHP team considers mod_php the highest-risk setup. A demonstrated exploit showed that a single unauthenticated request can trigger the attack before any application code runs.
The scale is large. Unit 42 reported more than 22.6 million exposed instances that may be vulnerable. Researchers cited by Tenable traced the oldest affected code path back to PHP 5.4.0.
Is the Threat Active?
The disclosure did not go smoothly. According to the PHP Foundation, the CVE IDs leaked a day early, a research video briefly went public, and proof-of-concept code began circulating. The Cyber Centre and CISA stated that they had not witnessed any active exploitation at the moment of their warnings. However, Amazon Threat Intelligence announced that there were exploitation attempts as early as October 17 and described general exploitation in the wild.
The risk is apparent. If a person runs an unpatched PHP server on the net, they must consider it compromised.
What Readers Need to Know Right Now
Most of the web surfers who will search for this topic are expecting short answers. Here they are.
Are WordPress or other PHP apps at risk?
The vulnerability exists in the PHP runtime, so WordPress, Drupal, Joomla!, Magento, and Laravel sites are all impacted. You cannot just update your plugins or themes. You will have to update PHP to address the issue.
What should be upgraded?
The PHP versions which are recommended for upgrade are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. You need to prioritize the systems which are accessible over the Internet.
What can be done if an organization cannot temporarily patch the system?
You should make sure that their internet-facing applications are isolated and consider the use of a web application firewall as a temporary measure.
How can one check if the system was compromised?
You should be on the lookout for anomalous activity in your web server, application, and web endpoint logs. This includes PHP worker processes attempting to launch shells, downloaders, or connect out to unusual sites. The Amazon team recommends starting the hunt on October 17.
Where else is the vulnerable code likely to reside within a network?
The code can live anywhere in the network perimeter, including third-party applications, containers, network appliances, control panels, and managed hosting platforms. The NCSC-NL php2shell inventory tracks affected vendor products.
Fixed Versions and Unsupported Releases
|
PHP Branch |
Fixed Version |
|
8.5.x |
8.5.12 |
|
8.4.x |
8.4.27 |
|
8.3.x |
8.3.36 |
|
8.2.x |
8.2.35 |
PHP 8.1 or older versions no longer get updates from the PHP project. Some Linux distributions and LTS vendors have backported some fixes, so check with your vendor. Due to the importance and impact of the issue, the PHP security team has published minimal source backports for 7.4 through 8.1 for those compiling PHP from source. Older releases before 7.4 will not get any fixes from the project.
Also note that PHP 8.2 reaches the end of security support on December 31, 2026, according to php.net's supported versions page. If you are patching 8.2 today, plan your next upgrade now.
A Pattern, not a One-Off
Old PHP versions have a long history of stacked flaws. Many scanners report this as a single version-based finding. A Tenable or similar alert for php 8.0 30 vulnerabilities refers to builds older than 8.0.30, which carried several known CVEs. A php 8.3 6 vulnerabilities finding flags 8.3 builds older than 8.3.6. Legacy servers may even show php 5.4 16 vulnerabilities, a finding from over a decade ago that should never appear on a production system today.
The lesson is clear. Teams that ignore routine php 8.3 vulnerabilities and other version warnings tend to be the slowest to respond in an emergency like php2shell.
Application-level flaws are a separate class of risk. The panabit panalog singleuser_action.php sql injection vulnerability, for example, is a SQL injection bug in a third-party PHP-based product, not in PHP itself. It shows how vendor appliances can carry their own PHP weaknesses alongside runtime issues. The same applies to information disclosure findings. If a scanner reports something like a "PHP diescan information disclosure vulnerability," treat it as exposure of debug output, file paths or version details. Labels vary by tool, but the fix is usually to disable verbose errors and remove diagnostic pages.
Immediate Response Checklist
Use this list to move fast and stay organized:
- Inventory every PHP asset: Include servers, containers, appliances, SaaS integrations and hosting accounts.
- Patch internet-facing systems first: Then move to internal systems.
- Verify the real runtime version: php -v shows only the command-line version, which may differ from PHP-FPM or Apache. Check through your web server, then remove any test phpinfo() page right away.
- Inspect third-party packages: Ask vendors for patch status on any product that bundles PHP.
- Enable WAF protection as a temporary layer: Cloudflare deployed WAF rules for known attack patterns, but it is a stopgap, not a fix.
- Apply PHP's temporary mitigations if needed: These include memory_limit=-1 and session.upload_progress.enabled=0, followed by a restart of every worker. They reduce risk but do not make a server safe.
- Review logs from October 17 onward: Look for unusual processes, new files, new accounts and outbound traffic.
- Isolate public-facing apps if patching is delayed: CISA advises taking unpatched or unsupported systems offline.
- Call incident response help if something looks wrong: The NCSC UK recommends checking for backdoors before or during remediation.
Why This Matters for Canadian Businesses
For Canadian organizations, a PHP breach represents a potential violation of personal information protection laws. Exposure of customer data may result in a breach of the Personal Information Protection and Electronic Documents Act (PIPEDA). This applies to all sectors including healthcare, where additional regulations (e.g., PHIPA) apply, and retail, where credit card data security standards (PCI DSS) are relevant.
The downtime involved also incurs costs in terms of lost revenues and customer confidence. In this breach, several organizations chose to take their website offline as a precaution, which may cause loss of customers who prefer online transactions, or more severe impacts if an organization is reliant on online retail outlets. The sooner an organization can identify its exposure, the smaller the duration of the incident.
How PlutoSec Helps You Close the Gap
PlutoSec is a Canadian cybersecurity company based in Etobicoke, Ontario, serving organizations in every province and territory. Our certified team holds OSCP, CISSP and GPEN credentials, and we work with clients in finance, healthcare, retail, government and technology.
Here is how we support teams facing PHP critical vulnerabilities:
- Urgent exposure assessment: We map where PHP runs in your environment, including hidden instances inside vendor software and containers.
- Manual-first testing: Our offensive security and web application penetration testing go beyond scanners to confirm real risk.
- Patch and hardening support: Our cloud and infrastructure security and secure hosting and infrastructure teams help you harden servers and runtime settings.
- Ongoing monitoring: Our managed security and vulnerability management services keep watch after the patch is applied.
- Breach investigation: If you see suspicious activity, our incident response and digital forensics team can contain the threat and find the root cause.
You receive a technical report for engineers and a plain-language summary for leadership. We also retest to confirm every fix holds. Explore our full range of cybersecurity services.
Act Before the Window Closes
PHP critical vulnerabilities like php2shell reward speed. Attackers move within hours of disclosure. Defenders who know their assets, patch fast and verify their work stay ahead.
If you are unsure whether your systems are exposed, talk to PlutoSec today. We can help you assess, patch, investigate and monitor with confidence. For more analysis of current threats, visit our blog.
Written by
Jonathan Zachary
