What Happened
On October 21, 2026, the PHP project released emergency security updates — PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 — to fix two critical vulnerabilities that can allow unauthenticated remote code execution (RCE). In plain terms: an attacker who can send web requests to a vulnerable server can potentially run their own code on it, without logging in.
The flaws are being referred to in the security community as "PHP2Shell". This is not a school-specific incident and we are not tracking it as a breach. We're publishing it because PHP powers WordPress, Joomla, Drupal, Moodle, and most of the websites Philippine schools run — and because schools are often the last to learn that a server-level patch exists.
The Two Flaws
- CVE-2026-109618 — PHP exits a request early when it runs out of memory. In some situations that early exit happens while internal request data is only partly set up, and the cleanup step then treats the invalid data as valid. PHP rates it CVSS v4 9.2 (Critical). The advisory describes a demonstrated exploit against Apache with
mod_php and default settings, where an unauthenticated request triggers the attack before any application code runs. Source analysis suggests PHP-FPM and other runtimes may also be affected. - CVE-2026-109619 — Request-owned internal state can survive after its memory has been freed. A later request handled by the same worker can then use that stale state. PHP rates this one CVSS v4 9.2 as well.
The practical point: these are flaws in PHP itself, not in your website's code. Updating WordPress, plugins, or themes does not fix them.
Why This Is a Big Deal for Schools
- 1It needs no password. Unlike most school-site compromises we document (stolen credentials, vulnerable plugins), this attack does not require an account.
- 2You probably can't patch it yourself. If your school site is on shared hosting, a cPanel account, or a vendor-managed server, PHP is updated by your host — not by you. See Shared Hosting and Web Shells for why one compromised server can take down every site on it.
- 3Old PHP versions get no fix. PHP 8.1 and older no longer receive official security updates, and PHP 8.2 reaches end of life on December 31, 2026. Many school sites run on whatever version their host set up years ago.
- 4Details are public. The vulnerability details leaked before the planned disclosure date, and proof-of-concept code is reported to be public. Cloudflare and hosting companies reported attack attempts the day the patch shipped. As of October 21, no confirmed break-ins had been reported, but that window tends to be short.
What To Do
If you manage your own server (VPS, dedicated, on-prem)
- 1Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or newer).
- 2Restart PHP-FPM or Apache. Running workers keep the old code until they restart.
- 3Check the web runtime version, not just the command line.
php -v can report a different PHP than the one your website actually uses. Check php-fpm8.3 -v (adjust the version), or look at the version shown on a phpinfo() page — and remove that page afterward. - 4Don't trust the version number alone. Linux distributions often backport fixes without changing the version. Check the package changelog for the CVE IDs, for example
apt changelog php8.3-cli on Debian/Ubuntu or rpm -q --changelog php on RHEL-family systems. - 5If you cannot patch right away, reduce exposure: put the site behind a web application firewall or CDN with rules for these CVEs, and consider taking internet-facing PHP applications offline until patched. PHP's own advisory says updating is the only complete mitigation; other measures are partial.
If your site is on shared or managed hosting
You can't patch it, but you can ask. Send your host (or your IT vendor) this:
Has the October 21, 2026 PHP security release (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35, fixing CVE-2026-109618 and CVE-2026-109619) been applied to the servers hosting our website? Which PHP version is our account running, and if it is 8.1 or older, when will it be upgraded?
If the host can't answer, or your account is on PHP 8.1 or older with no upgrade path, treat that as a reason to move. Our Vendor Security Assessment Checklist lists what to ask of any provider.
For everyone
- Take a backup of your website and database now, stored somewhere that is not the same server.
- Watch for signs of compromise after patching: unfamiliar files in upload directories, new admin accounts, unexpected outbound connections, or defaced pages. Our Site Scanner can check for exposed paths and misconfigurations, and Sensitive Paths Exposed explains what to look for.
- If you find evidence of compromise involving student or staff data, follow What To Do After a Breach — including National Privacy Commission notification timelines.
A Note on the Numbers
You may see figures like "22.6 million servers exposed" shared on social media. Estimates vary by scanner: reports cite 22.6 million potentially vulnerable PHP installations (attributed to Palo Alto Networks), and about 5.1 million internet-facing PHP addresses fingerprinted by VirusTotal. These are exposure estimates, not counts of compromised servers. We have not seen a Philippines-specific breakdown, so we can't tell you how many Philippine school sites are affected — only that PHP-based school sites on unpatched hosts are in scope.
Resources
Sources