DEV Community: Nelson

PHP2Shell + Supply Chain: Why patching fast could make things worse

Nelson — Fri, 23 Oct 2026 16:27:51 +0000

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 IPs
Verify package signatures
Drupal packages should be signed
Do not skip signature verification under time pressure
Check your SSL certificate Is the certificate issued by the
expected CA?
Any anomaly = stop and investigate
Monitor 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

Independent Security Researcher
CVE-2025-69690 (CVSS 8.8) &
CVE-2025-69691 (CVSS 9.9) — NVD/NIST
github.com/privlabs

Why I Built an Offline Pre-Audit Platform for Supply Chain Security (Before Scanning or Pentesting)

Nelson — Mon, 15 Dec 2025 10:19:09 +0000

In many security engagements, I kept seeing the same pattern.

Teams would start with:

scanners

pentests

long lists of findings

But very often, the real problem wasn’t what was exploitable,
it was where trust assumptions were already broken.

The gap before scanning

Most incidents I worked on started with:

weak sudoers configurations

unsafe update mechanisms

unpinned CI/CD dependencies

exposed management interfaces

These issues existed before any exploitation.

Yet most tools focus on what happens after.

Enter PrivLabs

I built PrivLabs to sit before scanning and exploitation.

PrivLabs is an offline supply-chain pre-audit assessment platform designed to:

identify early risk signals

structure findings

help teams decide where to focus first

It is intentionally:

non-exploiting

non-invasive

offline

human-centric

What PrivLabs does

Linux privilege escalation pre-audit

CI/CD pipeline trust analysis

Supply-chain configuration reviews

Executive-friendly risk summaries

What it does not do

No exploitation

No active attacks

No scanning

No data storage or transmission

PrivLabs complements pentesting — it doesn’t replace it.

Why offline matters

In many environments (enterprise, regulated, air-gapped), uploading data to SaaS tools is simply not an option.

PrivLabs processes everything in-memory, with no persistence.

Try it

Live demo:
https://privlabs-security-toolkit.streamlit.app/

Project overview:
https://privlabs.github.io/supplychain-security-toolkit/

Feedback is welcome — especially from people working in Blue Team, consulting, or DevSecOps roles.

Supply Chain Attack Simulation on Drupal: RCE via Malicious Update Server (PoC, not a CVE)

Nelson — Thu, 11 Dec 2025 14:43:56 +0000

What if a malicious actor could hijack the update server for your favorite CMS? I built a full lab scenario to show how it’s possible — and how to defend against it.

MITM, rogue CA, fake update feeds (release-history.xml), trojanized package, RCE + persistence
Everything documented: attack steps, screenshots, scripts (in the PDF), hardening tips
NOT a Drupal 0-day — just a realistic simulation for security awareness

Why does it matter?

Supply chain attacks are not theoretical anymore. This demo can help Blue Teams, Red Teams, devs, and trainers build better defenses and awareness.

👉 [See the repo & full PDF PoC] GitHub repo: https://github.com/privlabs/-Supply-Chain-Attack-Simulation-on-Drupal-RCE-via-Malicious-Update-Server-PoC-not-a-CVE-

Questions, feedback, want to collaborate? DM or email me (contact in README).

All lab, all safe, no harm to real-world systems!

cybersecurity #supplychainsecurity #securityresearch

offensivesecurity #redteam #blueteam #devsecops

drupal #websecurity #rce #mitm

Open-source tool: Detect & fix Linux cron job privilege escalation (LPE)

Nelson — Fri, 05 Dec 2025 19:56:19 +0000

After several months of research and lab testing, I’m releasing a complete guide + scripts to detect and fix privilege escalation via misconfigured cron jobs on Linux.

🚀 Key features:

Automated audit of cron jobs for security issues
Exploitation examples
Hardening tips
Open-source scripts

💡 Example: root shell on a cloud VM through a simple cron misconfiguration (see repo for details).

For sysadmins, SecOps, pentesters, or anyone passionate about Linux security.

👉 GitHub repo: https://github.com/privlabs/lpe-cron-misconfig-2025

Feel free to test, comment, or contribute! Would love your feedback or stories of similar issues you’ve found.

linux #security #opensource #cron #infosec #sysadmin