PHP2Shell: What Malaysian Website Owners Should Do This Week

PHP2Shell is two critical flaws in PHP, the language WordPress, WooCommerce and Laravel are built on. Fixes came out on 21 October 2026. The short version: the fix is a PHP update on your server, not a WordPress update. So first, find out who updates PHP on your site.

What is PHP2Shell?

The two flaws, CVE-2026-109618 and CVE-2026-109619, are each rated 9.2 out of 10. PHP calls them "unauthenticated remote code execution": a stranger could make your server run their commands without logging in.

The PHP project's advisory, captured 22 October 2026. Source: php.net

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.

Wiz Research, which helped find the flaws, says even a simple "Hello World" page on an affected version can be vulnerable. It showed working attacks on WordPress, Drupal and Joomla.

Is my WordPress or WooCommerce site affected by PHP2Shell?

If your site runs on PHP, assume yes until someone confirms the server is patched. WordPress.org is blunt:

WordPress.org's notice, captured 22 October 2026. Source: WordPress.org

These vulnerabilities are not specific to WordPress and affect any server that hosts a PHP application. No WordPress update is required or planned for these issues.

How to check if your site is vulnerable

1. Find your PHP version. In WordPress, open Tools > Site Health > Info > Server, or look in your hosting panel.
2. Compare it with the table. Anything below the patched number needs the update.
3. Ask your host or vendor in writing: "Is PHP on my site patched for CVE-2026-109618 and CVE-2026-109619?" A backported fix may not change the version number, so a written yes beats guessing.
4. Someone technical can run OpenAI's free php2shell-checker, which reads the version a site announces. We ran it today: a test server on 8.4.26 showed VULNERABLE, one on 8.4.27 showed OK, and php.net showed UNKNOWN. UNKNOWN does not mean patched, because servers can hide their version.
5. If you can't update right away, or you run 8.1 or older, CISA says to take PHP systems offline until they are patched or updated.

What if my site is on PHP 8.1 or older?

PHP.net will not ship a new 7.4, 8.0 or 8.1 release, but the fix does exist for those versions. PHP's security team posted source patches for all three. Remi Collet, a PHP core developer, also keeps security backport branches for old PHP versions, and his 7.4, 8.0 and 8.1 branches carry this fix. Package sources such as Remi's RPM repository (RHEL, AlmaLinux) and deb.sury.org (Debian, Ubuntu) build their old PHP packages from that work.

So ask your host: "Is our PHP build patched for CVE-2026-109618 and CVE-2026-109619?" There are two catches. A patched build keeps its old version number, so OpenAI's checker will still say VULNERABLE and Site Health will still show the old version. Only your host's answer settles it. And older than 7.4? PHP's own patches stop at 7.4, but cPanel and CloudLinux, the software behind many shared hosts, shipped patched builds for every PHP version from 5.2 to 8.5 (CloudLinux's status page). TuxCare sells patched builds for old versions too. So the same question to your host applies.

A patched old version buys time, nothing more. Plan the move to a supported version anyway.

How this affects Malaysian businesses

Our take: applying the patch is the easy part. The harder part is that nobody may own the job. On shared hosting, the host usually updates PHP. On a cloud server a vendor set up, often nobody does unless the contract says so. The vendor assumes the host handles it, the host assumes you do, and the server stays on old PHP. More on that gap in our software maintenance cost guide.

Then there's AI. Wiz says it used Gemini 4 Argon and GPT-5.6 Sol throughout the research, on bugs that had sat in PHP for more than a decade. Attackers can use the same models, so we expect the gap between a public fix and the first attacks to keep shrinking. CISA had not seen attacks when it published, so use that head start this week. A web application firewall may help until you patch, CISA says, but PHP calls updating "the only safe choice."

A patched version does not make the rest of the server safe. If nobody has looked at yours since launch, start with our server hardening basics. If it holds customer data, a break-in may also count as a PDPA breach with a 72-hour reporting clock. See what a real penetration test covers.

Want us to fix it for you?

Gotchaa Lab can patch PHP2Shell on your server. We first check which PHP version actually serves your site, then fix it to match. On PHP 8.2 to 8.5, we update to the fixed release. On PHP 7.4 to 8.1, we install a patched build of your current version, so the site keeps running while you plan the upgrade. On 7.3 or older, we find a patched build for your server if one exists, and plan the upgrade with you. Afterwards we confirm the fix is in place and check that your site still works.

On shared hosting, we switch you to a fixed version if your hosting panel offers one. If it doesn't, we tell you exactly what to ask your host.

WhatsApp us with your website address, or see our cybersecurity services.

This is general information, not professional cybersecurity or legal advice.

References

1. PHP security advisory, PHP.net, 21 October 2026
2. Critical PHP Security Release, WordPress.org, 21 October 2026
3. Critical Vulnerabilities in PHP Require Immediate Patching, CISA, 21 October 2026
4. PHP2Shell: AI uncovers critical RCE vulnerabilities, Wiz Research
5. php2shell-checker, OpenAI on GitHub
6. php-src-security: security backports for end-of-life PHP versions, Remi Collet on GitHub
7. PHP CVE-2026-109618 and CVE-2026-109619: fixed alt-php and ea-php packages, CloudLinux, 21-22 October 2026