On October 21, 2026, PHP released patches for two critical flaws, CVE-2026-109618 and CVE-2026-109619, known as PHP2Shell. The fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35, according to PHP’s security advisory. Wiz’s analysis rates the severity up to CVSS 9.2. It also demonstrated unauthenticated remote code execution on WordPress, Drupal, and Joomla.

If you run IT at a university, the useful question is a different one: what layers does your website have, and who patches each one?

Why updating your CMS isn’t enough

The flaw is in PHP, not in the applications. PHP is the interpreter that runs the CMS. Updating the CMS doesn’t fix a flaw in the interpreter.

Wiz puts it plainly: applying the PHP security update is the only complete fix. Drupal agrees. Its PSA-2026-10-20 advisory states that updating to a patched PHP version is the only complete mitigation.

The scope is wide. According to Wiz, nearly every PHP version is affected by at least one of the flaws, going back to PHP 5.4. According to VirusTotal, cited by Recorded Future’s blog, about 5.1 million IP addresses run PHP. Only about 1.1 million declare their version. That’s an exposure figure, not a count of vulnerable sites.

Drupal adds a reminder of responsibility. If your host manages PHP, follow their communications for timelines and actions. And the security of the hosting platform remains the responsibility of the site’s owner.

The layer map: who patches what

A university website stacks four layers. Who’s responsible for each one changes depending on how you host it.

Layer Self-hosted Managed hosting or agency Griddo
Application (CMS and extensions) Your team Whoever the contract names: confirm it The public website is generated as static HTML at build time
Interpreter (PHP) Your team Your host, if they manage PHP: ask them Griddo doesn’t run on PHP or .NET. Backend in Node.js and TypeScript
Server Your team Your host or agency Static HTML distributed through a global CDN. The front end deploys on the infrastructure the university chooses
Per-request code Your team Whoever manages the application Griddo doesn’t use SSR or DSG. API-first, headless architecture on serverless infrastructure at the edge

A plugin only lives in the first row. The PHP2Shell flaws live in the second.

Step 0: a site registry

Before asking anyone else, you need to know what sites you have. A registry with owner, PHP version, and risk level for each one.

The scale is surprising. The University of Edinburgh’s blog counted 2,117 sites on October 16, 2026. That’s a census taken before PHP2Shell, but it shows the scale a university’s web estate can reach.

Without a registry, you can’t answer the first question below. If you manage many sites, our guide on multisite management and web governance is a starting point.

What Griddo does

Griddo’s backend runs on Node.js and TypeScript. Griddo doesn’t run on PHP or .NET.

Griddo operates on the SSG model. It generates static HTML at build time and distributes it through a global CDN. It doesn’t use SSR or DSG.

Griddo states that its static front end deploys on AWS (S3 + CDN + WAF). The university chooses where it deploys: Cloudflare Pages, Amazon S3 + CloudFront + WAF, or self-hosted.

The architecture is API-first and headless, deployed at the edge on serverless infrastructure. In the Griddo Cloud model, Griddo manages the entire AWS infrastructure.

Patching responsibility also shifts depending on the model. In Enterprise, with the university’s own AWS contract, Griddo handles deployment, monitoring, and patching. Our documentation doesn’t detail exactly which components patching covers: ask for that scope in writing.

If you run several sites, Griddo lets you manage them from a single panel. That fits with step 0: one place to see all your sites. Even so, review every layer of your website.

We’ve been writing about who patches a university website since July 2025. For context, start with The CMS Vulnerability Crisis. Follow up with the hidden costs of maintaining your website and with CIOs and serverless architecture.

Your next step

PHP2Shell gets patched in a layer the CMS doesn’t control. Ask every provider who’s responsible for theirs, and get the answers in writing.

Request an Architectural Security Review