Last week, PHP2Shell (CVE-2026-109618 and CVE-2026-109619, both CVSS 9.2) forced hundreds of websites offline worldwide, including government sites in France, Finland, and the Netherlands. PHP-based CMSs such as WordPress, Drupal, Joomla and Magento were all exposed.
The message from CERT-EU was clear: patch immediately or take your site offline.
But there is a risk almost nobody is talking about.
The overlooked vector: your update channel
When PHP2Shell broke, administrators worldwide rushed to patch. Fast patching is the right reflex, but speed creates a blind spot.
In December 2025, I published a full supply chain attack simulation targeting the Drupal update mechanism, 10 months before PHP2Shell:
👉 GitHub: privlabs/Supply-Chain-Attack-Simulation-on-Drupal
The attack works like this:
- Attacker gains MITM position (DNS poisoning or network compromise)
- Deploys a rogue server with a forged SSL certificate impersonating updates.drupal.org
- Serves a crafted release-history.xml
- Admin sees: "Security update available"
- Admin installs the "patch"
- Payload executes: RCE + cron persistence
The admin believes they patched. They installed a backdoor.
Why PHP2Shell makes this worse
PHP2Shell created exactly the conditions that make supply chain attacks more likely to succeed:
→ Admins are under pressure to patch fast
→ Security alerts create urgency
→ Urgency reduces verification habits
→ "I need to patch PHP NOW"
= less likely to verify the update source
This is not hypothetical. My PoC demonstrates the full attack chain on
Drupal 9.5.10, 10.1.0, 11.0.8, and 11.1.3
— tested in a controlled lab environment.
The combined scenario
Standard PHP2Shell response:
→ Admin patches PHP ✅
→ Result: SAFE ✅
Supply chain + PHP2Shell scenario:
→ Admin thinks they patch PHP ✅ (belief)
→ Rogue server delivers malware instead ❌
→ PHP2Shell still present ❌
→ Backdoor installed ❌
→ Result: COMPROMISED while believing they are protected ❌
The vulnerability is not in PHP or Drupal core. It is in the trust model:
administrators trust that updates.drupal.org is always the real updates.drupal.org.
Patch fast = good.
Verify where the patch comes from = even better.
How to protect yourself
Before patching any CMS in a PHP2Shell
context:
Verify the update server URL
Check DNS resolution of updates.drupal.org
Compare against known good IPsVerify package signatures
Drupal packages should be signed
Do not skip signature verification under time pressureCheck your SSL certificate Is the certificate issued by the
expected CA?
Any anomaly = stop and investigateMonitor for MITM indicators
Unusual DNS responses
Certificate changes on known domains
Unexpected outbound connections
For a full hardening guide specific to Drupal update security, see:
→ HARDENING.md in my repository
→ DETECTION.md for blue team monitoring tips
Responsible disclosure note
My December 2025 research does not exploit a vulnerability in Drupal core.
It demonstrates a supply chain attack simulation in a controlled lab environment for defensive and educational purposes only.
DISCLAIMER: Do not use these techniques against any system you do not own or without explicit permission.
Resources
→ My PoC (December 2025):
github.com/privlabs/Supply-Chain-Drupal
→ CERT-EU PHP2Shell advisory:
cert.europa.eu/publications/security-advisories/2026-018/
→ CVE-2026-109618 (NVD)
→ CVE-2026-109619 (NVD)
→ The Register — PHP2Shell coverage
Nelson Adhepeau
Independent Security Researcher
CVE-2025-69690 (CVSS 8.8) &
CVE-2025-69691 (CVSS 9.9) — NVD/NIST
github.com/privlabs
