Two Security Releases in 24 Hours: What the Magento and WordPress Updates Mean for Your Store

On August 11, Adobe patched an account-takeover flaw in Magento that needs no password, no click, and no account of the attacker's own. The next day, WordPress shipped its third core security release in a month. Two platforms, two very different risk profiles — and one deadline.

If your store runs on Magento (Adobe Commerce) or WordPress, this was an unusually busy 24 hours. Adobe released APSB26-92 for Adobe Commerce and Magento Open Source on August 11, fixing seven vulnerabilities — five of them rated Critical, including an unauthenticated customer account takeover scored 9.1 out of 10. On August 12, WordPress followed with version 7.0.4, a security release fixing a remote code execution flaw — the third core security release in about a month.

Both updates are the kind vendors describe as "install immediately." The interesting part is how different the two threats actually are — and why that difference should shape what you do next.

The news: what actually shipped

Magento (APSB26-92, August 11). The headline issue, CVE-2026-71362, is an incorrect authorization flaw that lets an attacker switch an active customer session to another customer's account. No authentication, no admin access, no user interaction — the attacker does not need an existing account at all. Security firm Sansec reviewed the patch and confirmed the mechanism: a crafted request can move a session onto a victim's account, exposing their profile and private customer data. The bulletin also covers stored cross-site scripting and several authorization flaws (CVE-2026-48413 through 48416 and others). Adobe said at publication that it was not aware of exploitation in the wild — but Sansec's protection platform was already blocking exploitation attempts within a day of disclosure, and third-party telemetry has since logged further probing. No successful compromises have been confirmed — but unpatched stores are being actively tested, not just watched.

One important detail for Magento owners: this update does not come as a new release or new Composer packages. Adobe now distributes monthly fixes as isolated patch files that are folded into a full security patch later. To apply it you need to be on the latest -p release of your version line (2.4.4 through 2.4.9), then apply the isolated patch for your version.

WordPress (7.0.4, August 12). The fix covers CVE-2026-65640 (GHSA-8vr3-7mxf-gx8w): an authenticated remote code execution flaw triggered by a malicious file upload — but only on sites using the Imagick image library together with Ghostscript. An attacker needs an account with at least Author privileges and a site on that specific stack. Rated CVSS 8.8, the vulnerability was reported by the pwn.ai research team. As a courtesy, WordPress backported the fix all the way down to the 4.7 branch — every maintained release line from 7.0.4 back through 4.7.35 now has a fix — though WordPress reminds users that only the latest version is actively supported.

The bigger story is the cadence. WordPress 7.0.2 (mid-July) fixed a critical core vulnerability chain that was subsequently exploited at scale — we covered that release here. WordPress 7.0.3 followed on August 6 with twelve security fixes, including a pre-auth reflected XSS. Then 7.0.4 landed six days later. Three core security releases in roughly a month is unusual for WordPress, and it is the part worth paying attention to. The cadence continues: the 7.1 feature release lands on August 19 — a different kind of update, and a useful reminder to tell the two apart. Security releases get applied immediately; feature releases get staged and tested.

Why this matters to website owners

These two updates look similar from a distance — "security release, update now" — but the risk profiles are almost opposites.

Magento's account takeover requires nothing from the victim. No employee has to click anything, no password has to leak, no account has to exist. The attacker just needs your store to be reachable and unpatched. The outcome is direct and commercial: customer accounts, order history, saved details, and the trust that goes with them. For a shop, this is closer to a business problem than an IT problem.

WordPress's flaw, by contrast, is gated twice: an Author-level account is required, and the site must run Imagick with Ghostscript. That makes it harder to hit than a pre-auth bug. But "requires an account" is a weaker defense than it sounds. Author accounts accumulate — guest authors, former staff, integrations — and each one is a potential entry point. And the wider pattern this month is the real lesson: when a platform ships three security releases in a month, the people most at risk are not the ones who never update. They are the ones who update the first time, then start skipping because it happens too often. Update fatigue is a vulnerability too — just a quieter one.

What to do

If you run Magento (Adobe Commerce or Magento Open Source): confirm which version line you're on (2.4.4 through 2.4.9), make sure you're on the latest -p release of that line, and apply the APSB26-92 isolated patch — don't wait for a "full release," because this month's fixes only exist as isolated patches. If a developer or agency manages the store, send them the bulletin link and ask for the patch to be applied and tested this week. Why this week: the flaw needs no credentials and no interaction, so the exposure window is entirely on the patching side — and the probing started within hours of disclosure.

If you run WordPress: update to 7.0.4 now via Dashboard → Updates, or let the automatic background update do it. If you're pinned to an older major version for compatibility reasons, update to the matching point release instead (for example 6.9.7, 6.8.8, or 4.7.35) rather than jumping straight to 7.0.4. Because this flaw needs the Imagick + Ghostscript combination, sites that don't use Ghostscript are not exposed to this specific CVE — but you can't rely on knowing that for certain, and the release also carries the usual hardening. The update itself is the fix; there is no meaningful workaround.

For both platforms, the same small investment pays off: know what you're running. A ten-minute inventory — platform, version, who has accounts, what image libraries are enabled — turns every future "update now" from a moment of panic into a routine step. Set the cadence in advance: security releases get applied within days, major versions get staged and tested. That is the difference between treating updates as a chore and treating them as a business decision.

Key numbers

• Magento: 7 vulnerabilities patched, 5 Critical — led by CVE-2026-71362 at CVSS 9.1, exploitable with no authentication, no admin access, and no user interaction (Adobe, August 11, 2026). Exploitation attempts were observed within a day of disclosure (Sansec / BleepingComputer, August 12, 2026); no confirmed compromises yet.
• Magento: affected lines 2.4.4 → 2.4.9 (-2026-jul and earlier); fixed in -2026-aug versions.
• WordPress: CVE-2026-65640 (CVSS 8.8), Author+ RCE via malicious file upload on Imagick + Ghostscript sites; fixed point releases backported across every maintained branch, 7.0.4 down through 4.7.35 (wordpress.org, August 12, 2026).
• WordPress: third core security release in about a month — 7.0.2 (mid-July), 7.0.3 (August 6), 7.0.4 (August 12).

Final takeaway

Two platforms shipped security updates 24 hours apart, and the urgency they carry is not the same. Magento's flaw asks nothing of anyone — it just needs an unpatched store. WordPress's flaw needs an account and a specific stack, but it arrives during a month when the platform has asked you to update three times. Read the risk profile, not just the release note: know your versions, patch the unauthenticated exposure first, and build the update habit now — before the next release makes it a habit you need.