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

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.