# Who Patches What: The Layers of Your Website No Plugin Controls

> PHP2Shell (CVE-2026-109618/109619) isn't fixed by updating your CMS. The four-layer map of a university website, and who patches each one.

**URL:** https://griddo.io/en/journal/who-patches-php2shell-university/
**Language:** English
**Published:** 2026-10-27
**Updated:** 2026-10-27
**Author:** Daniel Serrano
**Tags:** security, architecture

---

## Key Takeaways

- **The flaw is in PHP, not the CMS:** updating WordPress or Drupal doesn't fix a bug in the interpreter that runs them.
- **The four-layer map:** application, interpreter, server, and per-request code — who's responsible for each one changes with your hosting model.
- **Six questions for your provider:** which PHP version serves each site, who updates it, and what gets checked after the patch.

---

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](https://www.php.net/archive/2026.php). [Wiz's analysis](https://wiz.io/blog/php2shell-php-rce) 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](https://www.drupal.org/psa-2026-10-20) 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](https://www.recordedfuture.com/blog/php2shell-vulnerability-exploitation), 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.

#### What's known about exploitation (as of 10/27/2026)

On October 26, 2026, [CISA added both flaws](https://www.cisa.gov/news-events/alerts/2026/10/26/cisa-adds-two-known-exploited-vulnerabilities-catalog) to its Known Exploited Vulnerabilities (KEV) catalog, which requires evidence of exploitation. Amazon identified an attempt on October 17, 2026, according to [its own security blog](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/). Cloudflare was also seeing attempts before the patch, according to [SecurityWeek](https://www.securityweek.com/php2shell-exploitation-started-days-before-patches/). On October 24, a researcher reported that attackers executed commands on honeypots configured to favor the exploit.

As of October 27, 2026, no source consulted reports a successful attack against production systems. This data ages fast: check this article's update date.

## 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](https://blogs.ed.ac.uk/website-communications/2117-websites-and-counting-welcome-to-our-wild-west-web-estate/) 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](/en/journal/multisite-management-universities-web-governance/) is a starting point.

#### Six questions for your host or provider

1. **What PHP version serves each site?** The fixed branches are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Ask for the exact version, site by site.
2. **Which branch is still supported, and what's the plan for PHP 8.1 and earlier?** Those branches no longer receive updates from the PHP project. Minimal source-code backports exist for 7.4, 8.0, and 8.1; PHP points to LTS distributions and vendors. Ask which route your provider uses. For the cost of staying on an old version, read [Vendor lock-in myth vs. version lock-in reality](/en/journal/vendor-lockin-myth-vs-version-lockin-reality/).
3. **Who installs the patch, when, and who restarts the processes?** PHP's advisory asks for worker restarts only for the configuration-based mitigations. Laravel Forge documents that its update restarts PHP-FPM; long-running processes launched from the CLI keep running the old version until restarted. Ask your provider how they handle this.
4. **What site inventory do they have?** Compare it against yours. Every mismatch is a site with no clear owner.
5. **Can traffic be cut off before it reaches PHP?** Ask whether the CDN or load balancer allows this while the patch rolls out.
6. **What gets checked after patching?** Amazon recommends investigating back to at least October 17, 2026. Ask what checks your provider will run and what evidence they'll hand over.

## 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](/en/journal/cms-vulnerability-crisis-hard-data/). Follow up with the [hidden costs of maintaining your website](/en/journal/wordpress-hidden-costs-university/) and with [CIOs and serverless architecture](/en/journal/cio-university-competitive-advantage/).

## 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](/en/demo/)

## Sources

[PHP's security advisory](https://www.php.net/archive/2026.php) | [Wiz's analysis of PHP2Shell](https://wiz.io/blog/php2shell-php-rce) | [Drupal's PSA-2026-10-20 advisory](https://www.drupal.org/psa-2026-10-20) | [Recorded Future's blog](https://www.recordedfuture.com/blog/php2shell-vulnerability-exploitation) | [SecurityWeek](https://www.securityweek.com/php2shell-exploitation-started-days-before-patches/) | [CISA's KEV catalog alert](https://www.cisa.gov/news-events/alerts/2026/10/26/cisa-adds-two-known-exploited-vulnerabilities-catalog) | [Amazon's security blog](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/) | [University of Edinburgh's blog](https://blogs.ed.ac.uk/website-communications/2117-websites-and-counting-welcome-to-our-wild-west-web-estate/)

---

## Frequently asked questions

### What is PHP2Shell?

It's the name for two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, patched on October 21, 2026. Wiz rates their severity up to CVSS 9.2.

### Is updating my CMS enough?

No. Updating the CMS doesn't fix a flaw in the interpreter that runs it. According to Wiz and Drupal, you need to update PHP itself.

### Is it already being exploited?

Yes. On October 26, 2026, CISA added both flaws to its Known Exploited Vulnerabilities (KEV) catalog. As of October 27, 2026, no source consulted reports a successful attack against production systems. This data ages fast: check this article's update date.

### What do I do if a site runs PHP 8.1 or earlier?

Those versions no longer receive updates from the PHP project, though minimal source-code backports exist. Ask your provider, or plan the move to a supported version.

### How does Griddo generate the public website?

It's generated as static HTML at build time and distributed through a global CDN. Griddo doesn't use SSR or DSG, and it doesn't run on PHP or .NET either.

### Who patches in Griddo?

It depends on the model. In Enterprise, with the university's own AWS contract, Griddo handles deployment, monitoring, and patching. In Griddo Cloud, Griddo manages the entire AWS infrastructure. Ask in writing exactly what patching covers in your case.

### Can I manage all my sites from one place?

Yes. Griddo lets you manage any number of sites from a single panel, though that doesn't replace reviewing every layer of your infrastructure.

---

*Generated from [Who Patches What: The Layers of Your Website No Plugin Controls](https://griddo.io/en/journal/who-patches-php2shell-university/)*