DEV Community: Stanley A.

CVE-2026-32475: Unauthenticated RCE in Elementor Pro via File Upload Validation Bypass

Stanley A. — Fri, 04 Sep 2026 13:48:00 +0000

CVE-2026-32475 is an unauthenticated arbitrary file upload to RCE in Elementor Pro (<= 4.2.1, fixed in 4.2.2). CVSS 9.0 (CWE-434). If you run WordPress with Elementor Pro forms that accept file uploads, patch and audit the uploads directory today.

The bug: `return` where `continue` belonged

The flaw is in the Form widget's upload path (process_field -> Upload::validation()). The validation loop iterates over the file array for one field. When the first element has UPLOAD_ERR_NO_FILE (empty filename), the code calls return instead of continue — aborting extension and MIME checks for every remaining file in that field. The mover runs in a separate loop that correctly skips the empty slot and writes the rest. Validator stops early, mover keeps going.

Exploit shape (observed in the wild by Wordfence):

POST /wp-admin/admin-ajax.php
action=elementor_pro_forms_send_form
form_fields['field_cc213f9'][0]; filename=""          <- triggers UPLOAD_ERR_NO_FILE
form_fields['field_cc213f9'][1]; filename="x1.php"    <- PHP webshell, never validated

The file lands at wp-content/uploads/elementor/forms/<uniqid>.php (uniqid() output, attacker-supplied .php extension). The upload response does not return the path, so the attacker must first work out the filename — a cheap step Patchstack documents. One GET to the file executes it. No auth, no nonce bypass needed — admin-ajax.php exposes the form handler to unauthenticated callers by design. Credit: Tin Pham (TF1T) reported via Patchstack (Jul 16); Austin Ginder independently reported via the Wordfence Bug Bounty Program (~Jul 24, $15,600 bounty); Wordfence rejected its own CVE in favor of Patchstack's CVE-2026-32475.

Precondition (precise): a published page with an Elementor Form widget containing at least one non-required File Upload field. Required is off by default, so most upload fields qualify. Installed-but-no-upload-form = vulnerable code, no reachable entry point for this chain.

Check if you are affected

# 1. Plugin version (want >= 4.2.2)
wp plugin list | grep -i elementor-pro
wp plugin get elementor-pro --field=version

# 2. Any PHP where there should never be PHP
find wp-content/uploads/elementor/forms/ -type f -name "*.php" -ls
# Any hit = treat as compromise, not cleanup-and-done

# 3. Look for probing in access logs (IP list rotates fast — check the live list in the Wordfence advisory, do not rely on static copies)
grep "elementor_pro_forms_send_form" /var/log/nginx/access.log | tail -n 50

Wordfence publishes the live offending-IP list in its advisory — check there rather than any static copy. Absence of matches proves nothing (log rotation, IP churn) — the folder check is authoritative.

Fix

# Update first — firewall rules are a shield, the patch removes the hole
wp plugin update elementor-pro
wp plugin get elementor-pro --field=version   # confirm 4.2.2+

# Harden the uploads path so the next validation bug buys nothing (defense in depth)
# nginx: never execute PHP under the forms upload dir
location ^~ /wp-content/uploads/elementor/forms/ {
  location ~ \.php$ { deny all; access_log off; log_not_allowed 1; }
}

# Apache alternative (.htaccess in wp-content/uploads/elementor/forms/)
<FilesMatch "\.php$">
  Require all denied
</FilesMatch>

If you run Wordfence Premium, Care, or Response, confirm Firewall -> Global Options -> "Disable Code Execution for Uploads directory" is on — that is what makes its file-access block work. Note the free version of Wordfence receives new firewall rules ~30 days after paid tiers, so free-tier sites had no firewall cover during the Aug 19-23 attack peak: updating was the only immediate protection. Patchstack has a virtual patch for unpatched sites. Either way, update: WAF rules rot, the patch does not.

Also worth a pass: wp post list --post_type=page --fields=ID,post_title plus a quick audit of which pages carry Form widgets with upload fields, and whether each one still needs to accept files. Restrict accept to what the workflow needs (PDF/images for applications) and drop upload fields from pages that no longer need them.

Why this one stung

6M+ installs, 190,000+ blocked attempts since Aug 19 disclosure, heaviest Aug 19-23. Same-day weaponization is now normal for internet-facing unauthenticated flaws.
The validator/mover split-loop pattern is a classic: two passes over the same array with different empty-element handling. If you write upload handling, validate and move in one pass, or fuzz the validator with [empty, valid, malicious] permutations.
Duplicate CVE CVE-2026-17590 was rejected — if your scanner flags it, map it to CVE-2026-32475.

Technical takeaway: never let validation and file-move disagree on what "empty" means. One loop, continue on empty, allowlist extensions, randomize stored names without preserving the attacker extension, and deny execution in upload dirs at the web server layer.

Full prevention-focused version with the shop-owner playbook: WardenBit.

1,033 Live Stripe Secret Keys Leaked: How Exposed .env Files Became a Payment Rail Breach

Stanley A. — Tue, 01 Sep 2026 14:34:00 +0000

1,033 Live Stripe Secret Keys Leaked: How Exposed .env Files Became a Payment Rail Breach

On August 18, 2026, a threat actor dumped 1,033 live Stripe sk_live_... keys from 669 vendors on an illicit forum — with a direct claim to Hudson Rock that ~20,000 keys are held for staggered release. The leaked keys had charge capabilities, were tied to real invoices and promo-code tables, and the victims ran completely different stacks. Hudson Rock found no infostealer infections tied to the vendor domains. The working hypothesis: automated mass-scanning for publicly exposed .env files and debug logs.

No vulnerability in Stripe. No single WordPress plugin. One misconfigured file, found at scale.

If you build or operate anything that talks to Stripe, this is a build-pipeline and deployment-hygiene incident you can verify in five minutes.

What the dump actually contained

Per Hudson Rock's Infostealers analysis:

669 vendors, 1,033 sk_live keys, customer rows, charges, balances, payouts, invoices
Advertised 33 GB total; the provided archive was 2.37 GB — consistent with a staggered release
JSON samples show "sk_live_51H..." with explicit charge-access flags
Invoice-linked CSVs with customer name / email / phone / home address / IP at purchase / internal transaction IDs / third-party integration identifiers — plus hosted invoice URLs that resolve to valid Stripe invoices exposing last-four of card
A separate promo-code spreadsheet (code, discount amount, duration) — mass abuseable

The 20,000 figure is an actor claim to Hudson Rock researchers, not an independent count. Treat it as claimed; the 1,033 observed keys are verified. That distinction matters if you cite the story.

What `sk_live` actually unlocks

Depending on scope, a standard sk_live is not read-only:

GET /v1/customers
GET /v1/invoices/:id
GET /v1/charges
POST /v1/refunds        # with charge capability → direct financial control
POST /v1/payouts        # if account-settings write is allowed
GET /v1/coupons         # promo-code enumeration

That is programmatic access through normal Stripe API calls. No exploit. A scanner that finds the key gets the same interface your backend uses.

Why `.env` and not a package bug

Two signals rule out a single-dependency explanation:

Victim tech stacks are heterogeneous — PHP storefronts, Node services, Python APIs, hosted site builders. No common plugin or framework.
Hudson Rock's telemetry found no infostealer infections on the specific vendor domains in the dump.

Both point to infrastructure-level exposure: a document root that serves dotfiles, a Docker image that copies .env into the served directory, or a debug/error page that dumps process.env / $_ENV. Scanners for /.env, /.git/HEAD, and /debug are older than this breach and fully automated.

A quick check you can run from any machine:

for p in "/.env" "/.env.example" "/.git/HEAD" "/debug"; do  # keep /.well-known/security.txt public per RFC 9116
  echo -n "$p -> "
  curl -s -o /dev/null -w "%{http_code}\n" "https://yourdomain.com$p"
done
# all should be 403/404 — any 200 that returns key-value secrets is an incident (note: /.well-known/security.txt should return 200 and is not part of this check)

Server-side, the fix is boring and decisive. Examples:

# nginx — block dotfiles before any try_files
location ~ /\. { deny all; access_log off; log_not_found off; }
location = /.env { deny all; }
location ~ /\.git { deny all; }

# Apache .htaccess
<FilesMatch "^\.env">
  Require all denied
</FilesMatch>
RedirectMatch 404 /\.git

# Dockerfile — do not copy .env into the image
# .dockerignore must contain: .env
# and: RUN --mount=type=secret,id=stripe_key ...  # BuildKit secrets, not COPY

On Cloudflare, a single WAF custom rule blocking URI Path contains /.env or /.git covers the edge, but it is not a substitute for origin hygiene — the origin must not serve the file even if the edge is bypassed by direct IP.

The check that actually invalidates a copied key

Scanning fixes the exposure. Rotation invalidates what was already copied.

In the Stripe Dashboard:

Developers → API keys → Roll secret key → Revoke previous value

If you use restricted keys, roll each one and audit whether any key was issued as a standard-type key with full charge + refund + payout scope when your integration only needs payment_intents:write and customers:read. Scope reduction after rotation:

# list keys and their scopes (restricted keys API)
curl https://api.stripe.com/v1/restricted_keys \
  -u sk_live_...: \
  -G

# create a least-privilege restricted key for a checkout-only service
curl https://api.stripe.com/v1/restricted_keys \
  -u sk_live_...: \
  -d "name=checkout-only $(date -I)" \
  -d "restricted_resources[0][resource]=payment_intent" \
  -d "restricted_resources[0][permissions][]=write" \
  -d "restricted_resources[1][resource]=customer" \
  -d "restricted_resources[1][permissions][]=read"

A copied standard key and a copied restricted key are both breaches — but one can refund and reroute payouts, the other cannot. That scope boundary is the difference between a privacy incident and a financial one.

Inventory every place the key has lived

The .env on production is rarely the only copy. After rotation, inventory and clean:

.env committed to a private repo that later became public
CI logs and build artifacts that echoed environment
Backup snapshots of the app directory (app-2026-03-01.tar.gz that includes .env)
Staging / legacy subdomains sharing the same key (staging.yourdomain.com/.env)
Third-party deploy tools and env-sync services that replicate variables
Local .env files on developer machines that were never rotated after the exposure window

A single git log --all --full-history -- ".env" and a secrets scan (GitGuardian, TruffleHog, gitleaks in CI) catches most historical commits. The point of the inventory is speed the next time any one location leaks: you rotate the key once and every copy is covered.

Detection after the fact

After rotating, look backwards 30 days in both places:

Stripe Dashboard → Developers → Logs: filter for POST /v1/refunds, POST /v1/payouts, and high-volume GET /v1/customers or GET /v1/invoices from unfamiliar IPs / ASNs. Normal integrations have a predictable call pattern; bulk listing is anomalous.
Origin access logs: GET /.env and GET /.git/HEAD from scanner user-agents in the weeks before the dump date. Even a 404-heavy scan leaves a fingerprint.

If either log shows unfamiliar calls, treat the window as an active incident — preserve logs, notify the payment processor, and consider a focused review of the key's lifetime.

Why this keeps happening

Doppler's Breach Dashboard timeline makes the pattern explicit. Recent examples include n8n (4,576 tokens found in public GitHub, 321 still valid, August 2026) and LiteLLM on PyPI — where CloudSEK initially tracked roughly 434,000 pipelines potentially exposed and Hudson Rock's independent analysis corroborated the scale at about 2,500 organizations (March 2026 backdoored releases 1.82.7/1.82.8) — alongside two disclosures from May 2026: Nx Console (poisoned VS Code extension 18.95.0 published May 18, more than 2.2 million installs) and CISA's own 844 MB public repo of production secrets (also May 2026, reportedly exposed for about six months). The Hudson Rock note on LiteLLM applies verbatim: removal of the file does not end the incident — copied credentials outlive the exposure.

For small teams, the durable fix is three habits rather than a vault project:

Time-box secrets — Stripe keys every 90 days, DB URLs every 180, on the same calendar as domain renewal
Keep secrets out of the repo — .env in .gitignore, history scanned in CI, BuildKit secrets or env injection at deploy time
Maintain a live inventory of every location that holds each secret, so rotation is one action, not a scavenger hunt

TL;DR for the reviewer who finds `/.env` returning 200

Your .env is your payment rail's access-control list. Check whether it is public, rotate the key, inventory where it lives, scope its permissions, and review the logs. That is the hour of work that 669 vendors are doing after the fact. You can do it before the next batch drops.

Originally published on WardenBit.

CVE-2026-19478: GitLab's CVSS 9.4 GraphQL Flaw Was Exploited Within Days — Patch Now

Stanley A. — Tue, 25 Aug 2026 14:37:00 +0000

GitLab shipped an out-of-band emergency release on August 17, 2026 fixing CVE-2026-19478 — a code injection flaw in a GraphQL directive, CVSS 9.4. Unauthenticated, network-exploitable, no user interaction. On self-managed instances, a single HTTP request can delete repositories, forge merge records, and ban maintainers, according to watchTowr principal researcher Jake Knott, who reproduced the exploit shortly after disclosure. Reported through GitLab's HackerOne bug bounty program by researcher hiimguardian. The same release also patched a related CSRF flaw in the GraphQL multiplex handler — CVE-2026-19650 (CVSS 7.1) — which, unlike the main flaw, does require some user interaction to trigger. Self-managed instances get two fixes in one upgrade.

Fixed builds: 19.2.4, 19.1.6, 19.0.8, 18.11.11 (affects 18.2+). GitLab.com / Dedicated are already patched server-side — no action needed there.

The timeline is the story

Aug 17 — patch released; advisory says "under certain conditions," the vulnerable directive isn't named (full technical details are embargoed for ~90 days, per GitLab's usual disclosure policy)
Aug 18 — watchTowr reproduces the flaw within minutes, working from nothing but the advisory and the diff in the patch itself — and says AI tooling is what let them move that fast
Aug 19 — watchTowr's honeypot network catches the first in-the-wild exploitation attempts, roughly two days after disclosure
Within the week — working proof-of-concept exploit code starts showing up publicly on GitHub, well before GitLab's 90-day embargo on full technical details even gets close to lifting

That last point matters: the "we'll release full details in 90 days" cushion GitLab normally relies on didn't buy anyone 90 days of safety here. Researchers armed only with a diff got there in hours.

Jake Knott (watchTowr), on why the old playbook doesn't hold anymore:

"This is the new reality of vulnerability reproduction and exploitation, where AI-enabled attackers are able to compress the time from disclosure to exploitation, and 'waiting until the next patch cycle' is often too late."

What to do

Self-hosting? Upgrade today — 19.2.4, 19.1.6, 19.0.8, or 18.11.11. Not next maintenance window.
Unpatched still? Hunt web/reverse-proxy logs for @gl_introduced — watchTowr's identified probe/exploitation marker. If you can't patch immediately, restrict unauthenticated access to /api/graphql at the proxy or WAF layer as a stopgap.
Rethink your patch SLA for internet-facing, unauthenticated, critical CVEs. Days, not weeks. If a patch takes longer than that to roll out, you need compensating controls (WAF rules, network restrictions) in the gap, not just a ticket in the backlog.

The pattern to internalize

This is the third GraphQL-layer flaw GitLab has patched in 2026 — a sustained hardening signal, not a one-off. More importantly, it's a concrete data point for a broader shift: weaponization time is collapsing, and AI is a big part of why. watchTowr didn't need a leaked exploit or insider knowledge — a public advisory plus a public patch diff was enough to get from "here's what we fixed" to working exploit in minutes. The old "let the patch bake for two weeks" playbook is now a liability for internet-facing critical flaws.

Build an emergency-patch lane before you need one: auto-alerts on critical CVEs in your stack, tested upgrade runbooks, and a standing decision rule — critical + unauthenticated + internet-facing → patch within 24–48h, no exceptions.

GitLab.com tenants: nothing to do here — but it's a good moment to inventory which self-hosted tools in your stack you'd quietly forgotten you're responsible for patching.

Originally published on the WardenBit blog.

CVE-2026-69836: Entra ID CVSS 10.0 RCE — What Business Owners Should Know

Stanley A. — Sat, 22 Aug 2026 12:09:43 +0000

On August 20, Microsoft disclosed CVE-2026-69836 — a remote code execution flaw in Entra ID (formerly Azure Active Directory), the identity service behind Microsoft 365 logins. CVSS 10.0. Unauthenticated. Network-reachable. The original bulletin said it had been exploited in the wild; Microsoft corrected that on Friday to "no evidence of exploitation." Either way: fixed in the cloud, no customer action required.

For developers and technical teams, three things are worth pulling out of this one.

1. The disclosure flip is a process story

The bulletin went from "exploited" to "not exploited" in about 24 hours — the correction reportedly came after The Hacker News asked Microsoft directly (Cybersecurity Dive and Forkast covered the change; most outlets, including THN's own article, still carry the original "exploited" framing). If you run threat-intel feeds or alerting off MSRC flags, treat first-pass exploitation claims as provisional — especially on cloud-service CVEs where Microsoft's visibility is asymmetric (they see their telemetry; you see a flag). Automations that page people at 2 a.m. based on an initial "exploited: yes" should have a re-check step.

2. Deserialization in identity infrastructure

CWE-502 (deserialization of untrusted data) keeps showing up in high-severity CVEs. In an auth service, a deserialization bug isn't just RCE-on-one-box — the blast radius is every tenant behind it. If your own services deserialize anything from tokens to webhook payloads, this is your reminder to keep deserialization on the threat-model list, prefer safe formats (JSON with schema validation over native object serialization), and never deserialize data from unauthenticated endpoints.

3. Know your patch-responsibility boundary

The useful mental model for any team: split your stack into vendor-patched (Microsoft 365, managed databases, SaaS) and self-patched (your WordPress/plugins, self-hosted apps, servers). The Entra fix required nothing from you. The WordPress 7.0.4 / Magento APSB26-92 releases two weeks ago required everything from you. Teams that can't enumerate their self-patched column are the ones that get breached by a July plugin CVE in October.

Practical checklist:

MFA on all admin accounts (the vendor patch doesn't cover credential theft)
Expect fake "emergency patch" emails after headline CVSS-10 disclosures — Microsoft explicitly required no action, so any such email is a scam by definition
Keep a living list of what YOU must update; review it monthly
If you build alerting on MSRC/CISA feeds, add a delay or re-check for exploitation-status flips

Microsoft found this one themselves, fixed it server-side, and disclosed for transparency. That's the system working. Your side of the line is smaller than the headlines suggest — but it's not zero.

Magento APSB26-92 and WordPress 7.0.4: Two Security Releases, Two Opposite Risk Profiles

Stanley A. — Tue, 18 Aug 2026 14:27:00 +0000

Two platform security releases landed 24 hours apart (Aug 11–12, 2026): an unauthenticated account takeover in Magento/Adobe Commerce, and an authenticated RCE in WordPress that needs two separate preconditions to fire. Same week, same severity tier on paper, very different exposure in practice. If you run — or maintain client sites on — either platform, here's what actually matters and what to do about it.

TL;DR

Magento (APSB26-92, Aug 11): unauthenticated session-hijack bug, CVSS 9.1. No release, isolated patch only. Exploitation attempts already observed — patch now.
WordPress (7.0.4, Aug 12): authenticated Author+ RCE, CVSS 8.8, needs Imagick + Ghostscript on the server. Third core security release in under a month — wp core update and move on.

Magento / Adobe Commerce APSB26-92 (Aug 11)

CVE-2026-71362 — Incorrect Authorization (CWE-863), CVSS 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N). No auth, no admin, no interaction.
Sansec confirmed the mechanism: an attacker can switch an active customer session onto another customer's account, exposing profile and private customer data.
7 vulnerabilities total, 5 Critical: stored XSS (CVE-2026-48413, 8.7; CVE-2026-48414, 7.7), auth bypasses (CVE-2026-48415, B2B, 7.6; CVE-2026-48416, 7.5), plus CVE-2026-48411/48412.
No new release, no new Composer packages. Fixes ship as isolated patch files; you must be on the latest -p release of your line first (e.g. 2.4.9-2026-jul), then apply the isolated patch on top.
Exploitation attempts observed within ~24h of disclosure (Sansec Shield blocking logs, BleepingComputer, Aug 12); no confirmed successful compromises reported yet.
Affected: -2026-jul and earlier; fixed: -2026-aug versions of each line.

WordPress 7.0.4 (Aug 12)

CVE-2026-65640 / GHSA-8vr3-7mxf-gx8w (CVSS 8.8) — authenticated Author+ RCE via malicious file upload, on sites running Imagick + Ghostscript. Reported by pwn.ai.
Fixed point releases shipped across every maintained branch (7.0.4 down to 4.7.35); only the latest branch stays actively supported going forward.
Third core security release in under a month: 7.0.2 (Jul 17, unauthenticated pre-auth RCE chain, "wp2shell", exploited at scale within hours), 7.0.3 (Aug 6, 12 fixes including CVE-2026-64638, a pre-auth reflected XSS on the login screen), 7.0.4 (Aug 12).
The 7.0.3 → 7.0.4 diff is small and focused: 7 files, 267 insertions — 235 of them in a single file, wp-includes/class-wp-image-editor-imagick.php.

Why the contrast matters

The Magento bug asks nothing of the victim — no credential, no click, no account. The patch window is the exposure window, full stop. The WordPress bug is gated twice (Author account and a specific image-processing stack), which genuinely lowers exploitability — but Author accounts accumulate on any site with guest writers or agency clients, and "third core security release in a month" is exactly the pattern that produces update fatigue. Teams tend to patch the first one carefully and the third one on autopilot. That's the real risk here, not the CVSS number.

Practical steps

Magento: confirm your release line, update to the latest -p release, then apply the APSB26-92 isolated patch. There's no full security release this month — don't wait for one.
WordPress: run wp core update (or Dashboard → Updates). If you want to scope actual exposure, check Site Health for Imagick/Ghostscript — but treat the update itself as the fix regardless of what you find.
Both: keep a version inventory so "are we exposed" is a lookup, not a fire drill. Apply security releases within days; stage majors. (WordPress 7.1, a feature release, is expected around Aug 19 during WordCamp US — stage that one, don't rush it.)

How are you handling the "third patch this month" problem — forced auto-updates, a staging gate, something else? Curious what's actually working for people running multiple sites.

This post originally appeared on the WardenBit blog.

Metabase Zero-Day: An Unauthenticated SQLi That Hit CVSS 10.0 and Stole Real Customer Data

Stanley A. — Tue, 11 Aug 2026 14:21:00 +0000

On 3 August 2026, attackers exploited a previously unknown, unauthenticated SQL injection in Metabase — starting with Metabase's own Cloud SaaS platform. Framework and Tally, both Metabase Cloud customers, confirmed customer data theft after Metabase notified them on 6 August that their instances had been accessed. Metabase disclosed the zero-day on 6 August with a CVSS 10.0 rating and confirmed active exploitation — before any CVE was assigned (the advisory ID is GHSA-vwf4-m7j8-wcjf).

The vulnerability

Advisory: GHSA-vwf4-m7j8-wcjf (GitHub Security Advisory). No CVE at disclosure — scanners that only track the CVE/NVD feed won't flag an exposed instance until one is assigned.
Type: unauthenticated SQL injection, reachable through the password reset flow (/api/session/reset_password)
Impact: arbitrary SQL into the Metabase application database → full administrator access → change application configuration, steal stored credentials for connected databases, read any data reachable through those connections, export data
Affected: self-hosted branches 0.58 through 0.63; Metabase Cloud was patched automatically for all customers

Minimum safe releases:

Branch	Minimum safe version
0.58	0.58.24
0.59	0.59.21
0.60	0.60.17
0.61	0.61.11
0.62	0.62.9
0.63	0.63.5

Temporary workaround if you can't upgrade immediately: block access to /api/session/reset_password. Stopgap, not a fix.

Cloud vs. self-hosted: read this twice

The confirmed victims — Framework and Tally — were Metabase Cloud customers. The breach happened at the vendor's end: attackers got into Metabase's managed platform, then into customer instances. Nobody at Framework or Tally "forgot to patch" anything; Metabase patched every Cloud customer automatically.

That's the part that should worry self-hosted operators more, not less. The same flaw is present in every self-hosted install from 0.58 to 0.63 — and for those, you are the vendor. The fix shipped within days of disclosure; applying it is entirely on whoever runs the instance.

A word of caution on attribution: you may see other outlets mention LexisNexis alongside Framework and Tally as a third victim. LexisNexis did disclose a service disruption at a third-party vendor around the same time, affecting something it calls "Metabase API" — but that's LexisNexis's own news-aggregation product, a completely separate piece of software that happens to share the name. LexisNexis itself has not confirmed any link to this vulnerability. Worth flagging as a reminder to double-check attribution during a fast-moving incident, but not something to repeat as fact.

Compromise signature (check your logs)

Metabase published the attack indicator: a POST to /api/session/reset_password returning HTTP 400, followed by a successful GET to /api/user/current. If your logs show that pairing, treat the instance as compromised — patching alone is not enough.

Post-compromise cleanup per the advisory:

Revoke all active sessions — delete every row in the core_session table
Review API keys; remove any you don't recognize
Review administrator accounts for unexpected changes
Rotate credentials for every connected database
Review data-warehouse logs for unauthorized access
Review Metabase activity and query history

The pattern to internalize

This is another incident where an unauthenticated, remotely reachable flaw in a tool — not the main application — became the entry point to a database the tool was allowed to reach. Cloud users got patched for them; self-hosted users had to move within days. If you run any self-hosted tool that holds database credentials, version-check it this week — and don't assume your scanner will tell you first, because until this one gets a CVE, CVE-feed scanners won't know it exists.

Sources: BleepingComputer · Metabase advisory · Metabase security update · SecureInSeconds

Full prevention-focused version: WardenBit

CVE-2026-8457: WooCommerce Social Login Auth Bypass — Forged Apple JWTs Take Over Accounts

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

On August 1, 2026, Wordfence disclosed a critical authentication bypass in the WooCommerce – Social Login plugin (WPWeb Elite), tracked as CVE-2026-8457 (CVSS 9.8).

The short version: the plugin's Apple login handler accepts an id_token, decodes its base64 payload — and never verifies the JWT signature, issuer, audience, or expiry. Combined with a login nonce that's publicly exposed via wp_localize_script, an unauthenticated attacker can log in as any existing WordPress user, including administrators, by forging a token whose payload contains the target's email.

No password. No 2FA. No user interaction. Just an email address.

The technical breakdown

The vulnerable flow, in pseudocode terms:

// What the plugin does (vulnerable):
const payload = JSON.parse(base64Decode(id_token.split('.')[1]));  // decode only
const email = payload.email;
const user = getUserByEmail(email);
loginAs(user);  // no signature check, no iss/aud/exp validation

// What it should do:
const jwt = verifySignature(id_token, APPLE_PUBLIC_KEYS);  // via JWKS
assert(jwt.iss === 'https://appleid.apple.com');
assert(jwt.aud === YOUR_CLIENT_ID);
assert(jwt.exp > now());
const email = jwt.payload.email;

The two problems stack:

Missing JWT validation — the handler decodes the payload without verifying it was signed by Apple (CWE-289, Authentication Bypass by Alternate Name).
Public nonce — the security nonce required to invoke the login flow is emitted to unauthenticated users via a localized JS object on the login page, so there's no client-side gate either.

The plugin resolves the WordPress user by email from the forged payload, with no role exclusion, and immediately issues an authenticated session.

Affected versions & fix

Detail	Value
Plugin	WooCommerce – Social Login (WPWeb Elite, CodeCanyon)
Affected	<= 2.8.7
Fixed	2.8.8
CVSS	9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
CWE	CWE-289
Researcher	Rafie Muhammad (Lead Security Researcher, Patchstack — credited via Wordfence's PRISM researcher program)
Disclosed	August 1, 2026 (Wordfence Threat Intelligence)
Exploitation status	None confirmed at disclosure (Aug 1, 2026)

References: Wordfence vulnerability entry · NVD: CVE-2026-8457

Note: this is a CodeCanyon premium plugin — updates don't flow through the usual WordPress.org free-plugin channel, so affected stores often patch late.

Why this matters to developers

This is the third authentication-related flaw Wordfence has logged for this plugin family:

CVE-2024-7503 (Aug 2024): Authentication Bypass to Account Takeover via loose comparison of an activation code, CVSS 9.8
CVE-2024-10114 (Nov 2024): Authentication Bypass via WordPress.com OAuth provider — insufficient verification of the user returned by the token, CVSS 8.1
CVE-2026-8457 (Aug 2026): Forged Apple JWT auth bypass, CVSS 9.8

Three critical-to-high auth bypasses in two years, all in the same "trust the token/claim without properly verifying it" family, is a pattern worth noting — not just a one-off bug.

Auth code is genuinely hard to get right, and the pattern here — decode-then-trust instead of verify-then-trust — is one of the most common JWT mistakes in the wild. If you build or maintain WooCommerce sites:

Always verify JWTs against the provider's JWKS endpoint. Signature first, then iss, aud, exp, and any provider-specific claims (e.g. Apple's nonce claim if you use the Sign in with Apple nonce).
Never expose the auth nonce to unauthenticated clients. If a nonce is in wp_localize_script, it's not a security control — it's a formality.
Resolve accounts with role exclusion in mind. Even a legitimate flow shouldn't auto-login into an administrator account purely from a provider email without additional checks.
Treat paid/CodeCanyon plugins as first-class update targets. They don't get WordPress.org's auto-update pipeline; schedule manual checks or use a license-manager integration.

Remediation checklist for affected stores

Update to 2.8.8 (via CodeCanyon downloads or the plugin's license-connected updater).
Audit Users → All Users for unrecognized admin accounts, especially created on/after Aug 1, 2026.
Review access logs for unusual requests to the social-login callback endpoints around the disclosure window.
Check for signs of post-exploitation (new admin users, unfamiliar plugins/themes installed, modified files, unexpected outbound requests) — not just the login itself, since a compromised admin session can be used to plant persistence.
If you can't update immediately, consider disabling the Apple login provider in plugin settings as a temporary mitigation — it disables the affected handler until you patch.

The takeaway

CVE-2026-8457 is a reminder that "log in with X" buttons are only as safe as the verification code behind them. A missing signature check turned a customer convenience into a full account-takeover path. The fix is one version — but only if you know you run the plugin and you act before attackers decide it's worth their time.

Originally published on WardenBit.

AI Is Finding Bugs Faster Than You're Patching Them — What Website Owners Should Do Differently

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

"As AI helps defenders discover more issues, customers will see a higher volume of security updates included in each security release."
— Pavan Davuluri, Microsoft EVP, Windows + Devices, July 9, 2026

Five days later, Microsoft shipped patches for 570 security vulnerabilities in a single Patch Tuesday — its largest release ever, and more than double the previous month's already-record count.

That is not a sign that Windows got less secure. It is a sign that the way vulnerabilities are discovered has changed. AI tools are now scanning code at a scale and speed that human teams alone cannot match. More bugs found, more patches shipped, and a widening gap between when a vulnerability appears and when you actually fix it.

If you maintain websites, web apps, or WordPress installations — and you think this is an enterprise-only concern — the data will change your mind.

The discovery acceleration is real

The July 2026 Patch Tuesday was the sharpest point of a trend that has been building all year:

Period	CVEs patched	Change
July 2025	137	baseline
June 2026	~200–206	previous record
July 2026	570	largest Patch Tuesday ever
First 7 months of 2026	1,308	nearly double the same period last year

Microsoft attributes the surge to AI-assisted vulnerability discovery through its internal MDASH (Multi-Model Agentic Scanning Harness) system. But the pattern extends well beyond Microsoft:

Mozilla + Anthropic: Claude Mythos Preview, an unreleased frontier model restricted to a small group of organizations under Anthropic's Project Glasswing, identified 271 vulnerabilities in Firefox in a single evaluation pass — all patched in Firefox 150. That's roughly 12× the number found by the previous model used in the same collaboration (Opus 4.6, which found 22 security-sensitive bugs in a two-week engagement, shipped in Firefox 148). Worth noting: Mozilla and outside commentators have pushed back on calling all 271 "zero-days" — most were bugs an elite human researcher could plausibly have found too; the real story is the speed, not exotic new bug classes.
Cisco: Shifting to a twice-monthly security disclosure schedule (1st and 3rd Wednesdays) with seven days' advance notice of which product families are affected, explicitly citing AI-accelerated vulnerability discovery as the reason.
Oracle: Its most recent quarterly update included 1,449 security patches, which it also links to AI-assisted internal scanning.

U.S. Executive Order 14409, "Promoting Advanced Artificial Intelligence Innovation and Security" (signed June 2, 2026), directs the Treasury Department, in consultation with the National Cyber Director, NSA, and CISA, to stand up an AI cybersecurity clearinghouse that coordinates vulnerability scanning, validation, and patch distribution across government and industry.

The message from every major vendor is similar: AI finds bugs faster than before. That pace does not look like it's slowing down.

The wp2shell case study: patched fast, exploited even faster

One week before the July Patch Tuesday, the WordPress Security Team released an emergency patch for a vulnerability chain dubbed wp2shell. Two bugs in WordPress core — CVE-2026-63030 (a REST API batch-route confusion flaw) and CVE-2026-60137 (SQL injection in WP_Query) — could be chained to let an unauthenticated attacker take complete control of a stock WordPress install. No plugins required. No login required. Just a crafted HTTP request.

The chain was found by Adam Kues at Searchlight Cyber, who pointed OpenAI's GPT-5.6 Sol Ultra at a stripped-down copy of the WordPress source (with git history removed, so the model couldn't just trace old bug fixes) and let it search for a pre-auth-to-RCE path. The AI-assisted portion of the work took roughly 10 hours and about $25 in API usage. It's worth being precise about what that means, though: Kues still defined the target, wrote the prompt, verified the SQL injection by hand against a live install, and then spent additional time afterward untangling the escalation chain the model produced. As Kues himself put it, the shift isn't that AI replaced the researcher — it's that the researcher's role moved up a level, from writing exploit code to steering and verifying it. Even accounting for that, a chain this complex against a target this hardened would very likely have taken a human team weeks, not a single working session.

Then the timeline compressed:

Event	Time elapsed
Patch ships (7.0.2 / 6.9.5 / 6.8.6)	T+0 (Friday)
First mitigation rules seeing exploit attempts	T+~90 minutes
Public PoC exploit code	T+overnight
Mass scanning + confirmed in-the-wild exploitation	T+1–2 days

At the time of disclosure, WordPress's own statistics showed 400+ million sites running an affected version. That number doesn't reflect sites patched since — and here the actual news is more encouraging than it might sound: security consultant Daniel Card sampled roughly 3,500–4,200 WordPress sites and estimated that fewer than 15% remained unpatched/vulnerable days after disclosure, thanks largely to WordPress's forced auto-update mechanism and Cloudflare's WAF rules. That's the good news. The bad news is that even a small vulnerable percentage of a 400-million-site ecosystem is still on the order of 90 million exposed sites — and that's the segment this article is really about: the sites where auto-update was disabled, delayed, or silently failed.

The implication for developers and DevOps: the window between "patch available" and "attackers exploiting at scale" is now measured in hours, and being in the "small percentage that didn't auto-update" is no longer a safe place to be.

The exploitation gap is a configuration problem

For teams managing multiple sites or deployments, the gap between "patch ships" and "site is protected" is not just an awareness problem. It is a configuration problem:

Auto-update disabled — many managed WordPress deployments disable core auto-updates for stability. The tradeoff: every emergency patch requires manual intervention.
No verification — auto-update runs but no one confirms the version number post-update. wp2shell triggered forced auto-updates, but only for installations that hadn't opted out.
Plugin compatibility stalls — "we'll update after we test plugin X" is a rational response that becomes a week-long exposure window.
No centralized version inventory — teams running 10, 20, or 50 WordPress sites often have no dashboard showing which versions are live.
Hosting provider patching lag — your site may be patched, but the server OS, PHP version, or database underneath may not be.

What to implement this week

1. Verify auto-update configuration

# Check WordPress auto-update settings
wp option get auto_update_core
wp option get auto_update_plugins
wp option get auto_update_themes

# Check current version across all sites
wp core version

If auto-update is disabled, enable it for minor and security releases at minimum. Major-version auto-update is a separate risk decision, but security releases should never be deferred.

2. Add a post-update verification step to your deploy pipeline

After any WordPress update, automatically run something like:

wp core version | grep -q "7.0.2" && echo "PATCHED" || echo "VULNERABLE"

Fail the deploy if the version doesn't match the expected security release.

3. Build a version inventory

For teams managing multiple WordPress instances, maintain a simple manifest:

[
  { "site": "example.com", "wp_version": "7.0.2", "last_checked": "2026-07-25" },
  { "site": "shop.example.com", "wp_version": "7.0.2", "last_checked": "2026-07-25" }
]

Automate it with a daily cron job that checks wp core version or queries the REST API:

curl -s https://example.com/wp-json/wp/v2/ | jq '.namespaces'
# Or check the generator meta tag:
curl -s https://example.com/ | grep -o 'content="[0-9.]*"'

4. Run a baseline security scan

External scans check SSL configuration, security headers, DNS records, email authentication, CMS version fingerprinting, and known technology exposures — 40+ categories. This is not a penetration test; it's a hygiene check that tells you your public exposure profile before an attacker does.

5. Write your 24-hour response checklist

Not a 30-page incident response plan. A literal checklist for the next critical disclosure:

Check the version on every site you manage
Apply the patch (or confirm auto-update ran)
Verify the version number post-update
Run a file integrity check for recently modified PHP files
Review access logs for suspicious requests

Repeat this sequence for every critical security release. It's worth more than any security product purchased after the fact.

The numbers that matter

Metric	Value	Source
Microsoft July 2026 CVEs	570 (record)	Krebs on Security, BleepingComputer
First 7 months of 2026 CVEs	1,308 (~2× prior year)	Windows Latest
Firefox vulnerabilities found by Mythos	271 in one evaluation pass	Mozilla Blog
WordPress sites on a vulnerable version	400M+ (at disclosure)	WordPress.org, via TechCrunch
Estimated share still vulnerable days later	<15% (≈90M sites)	Daniel Card, via TechCrunch
wp2shell AI-assisted discovery time	~10 hours (human-steered)	Searchlight Cyber / Dark Reading
First exploit attempts after patch	~90 minutes	Patchstack, via The Repository

Key takeaway

AI-accelerated vulnerability discovery is not a future problem. It's the current operating environment. The bottleneck has shifted from finding bugs to patching and verifying them fast enough — and the wp2shell numbers actually cut both ways: most of the WordPress ecosystem patched quickly thanks to forced auto-updates, but the exposed minority is still tens of millions of sites, and the attackers only need one of them.

For developers and DevOps teams: your patching pipeline, version verification, and configuration management are now first-class security controls, not just operational hygiene. The teams that handle the next wp2shell-level event best will be the ones that have already automated the verification step — not the ones relying on "we'll get to it this week."

Originally published on WardenBit — helping small businesses understand their security exposure before attackers do.

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.

DEV Community: Stanley A.

CVE-2026-32475: Unauthenticated RCE in Elementor Pro via File Upload Validation Bypass

The bug: return where continue belonged

Check if you are affected

Fix

Why this one stung

1,033 Live Stripe Secret Keys Leaked: How Exposed .env Files Became a Payment Rail Breach

1,033 Live Stripe Secret Keys Leaked: How Exposed .env Files Became a Payment Rail Breach

What the dump actually contained

What sk_live actually unlocks

Why .env and not a package bug

The check that actually invalidates a copied key

Inventory every place the key has lived

Detection after the fact

Why this keeps happening

TL;DR for the reviewer who finds /.env returning 200

CVE-2026-19478: GitLab's CVSS 9.4 GraphQL Flaw Was Exploited Within Days — Patch Now

The timeline is the story

What to do

The pattern to internalize

CVE-2026-69836: Entra ID CVSS 10.0 RCE — What Business Owners Should Know

1. The disclosure flip is a process story

2. Deserialization in identity infrastructure

3. Know your patch-responsibility boundary

Magento APSB26-92 and WordPress 7.0.4: Two Security Releases, Two Opposite Risk Profiles

Magento / Adobe Commerce APSB26-92 (Aug 11)

WordPress 7.0.4 (Aug 12)

Why the contrast matters

Practical steps

Metabase Zero-Day: An Unauthenticated SQLi That Hit CVSS 10.0 and Stole Real Customer Data

The vulnerability

Cloud vs. self-hosted: read this twice

Compromise signature (check your logs)

The pattern to internalize

CVE-2026-8457: WooCommerce Social Login Auth Bypass — Forged Apple JWTs Take Over Accounts

The technical breakdown

Affected versions & fix

Why this matters to developers

Remediation checklist for affected stores

The takeaway

AI Is Finding Bugs Faster Than You're Patching Them — What Website Owners Should Do Differently

The discovery acceleration is real

The wp2shell case study: patched fast, exploited even faster

The exploitation gap is a configuration problem

What to implement this week

1. Verify auto-update configuration

2. Add a post-update verification step to your deploy pipeline

3. Build a version inventory

4. Run a baseline security scan

5. Write your 24-hour response checklist

The numbers that matter

Key takeaway

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

The bug: `return` where `continue` belonged

What `sk_live` actually unlocks

Why `.env` and not a package bug

TL;DR for the reviewer who finds `/.env` returning 200

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