In October 2026, security researchers disclosed two critical flaws in PHP, the language that still runs a large share of the web, including WordPress, Laravel and most Nepali business websites and CMS platforms. They've been nicknamed "PHP2Shell". This isn't a tutorial on exploiting them; it's what site owners and developers need to know to check their exposure and patch.
What CVE-2026-109618 and CVE-2026-109619 actually are
Both are use-after-free flaws (a memory-handling bug, CWE-416) in PHP's core. Used together, they could let an attacker who isn't even logged in run arbitrary code on a vulnerable server. The Canadian Centre for Cyber Security's advisory (AL26-026, updated 23 October 2026) calls them critical and says internet-facing PHP servers and applications are at heightened risk.
Is your site affected?
| PHP branch | Affected (before) | Fixed in |
|---|---|---|
| 8.5 | 8.5.12 | 8.5.12 |
| 8.4 | 8.4.27 | 8.4.27 |
| 8.3 | 8.3.36 | 8.3.36 |
| 8.2 | 8.2.35 | 8.2.35 |
PHP 8.1 and older no longer get official security updates from the PHP project at all, so if your site runs on one of those, the real question isn't 'is it patched' but 'is it time to upgrade PHP'. Some Linux distributions and managed hosts backport fixes to older branches, so check with your host or developer rather than assuming.
How serious is this, really?
Serious enough that it made security news worldwide within days. As of the Cyber Centre's update, a proof-of-concept exists in open-source reporting but no confirmed active, widespread exploitation had been identified yet, though the advisory notes that could change quickly once attackers weaponise it. Treat 'no confirmed exploitation yet' as a head start to patch, not a reason to wait.
A second, related flaw: CVE-2026-115560
On 23 October 2026, a separate remote code execution flaw, CVE-2026-115560, was disclosed. The patches released on 21 October for CVE-2026-109618/109619 do not fix it. Exploiting it needs an uncommon mix of PHP configuration and application behaviour, so not every site is exposed, but PHP's security team recommends setting session.upload_progress.enabled = 0 as a precaution until an official fix ships. If you already applied this setting for the earlier flaw and left it on, no further action is needed for this one.
What to do now
- Find every PHP installation you're responsible for, including the one bundled inside WordPress hosting, plugins or third-party appliances, not just your own code
- Update to a fixed version (see the table above), or confirm with your host that they've already patched the server
- If you can't patch immediately, set session.upload_progress.enabled = 0 and restrict network access to the PHP service as an interim step
- Prioritise sites that are public-facing and handle untrusted input (contact forms, file uploads, login pages) over internal tools
- Check your web server and application logs for anything unusual: unexpected processes, new admin accounts or outbound connections
Most Nepali businesses don't manage their own servers directly; a shared or managed host does. If that's you, the fastest thing you can do today is ask your host or developer one direct question: 'Which PHP version are we on, and has it been patched for CVE-2026-109618 and CVE-2026-109619?' A vague answer is itself a warning sign.
