Blog on Experience Digest

Two Patch Cycles, Same Cracks: What Commerce's 2026 CVE Pattern Is Telling You

Tue, 23 Jun 2026 00:00:00 +0000

Adobe’s May 2026 Commerce bulletin (APSB26-49) dropped 14 CVEs on May 12. March’s (APSB26-05) was lighter by volume but not by type. Scroll through both and the same vulnerability categories keep surfacing: Incorrect Authorization and Stored XSS, bulletin after bulletin. Not the same bugs — different entry points, different CVSS scores, different reporters — but the same kind of bug. That’s the pattern worth paying attention to.

APSB26-05 delivered four critical Stored XSS findings (CVE-2026-21361, CVE-2026-21284, CVE-2026-21290, CVE-2026-21311), all leading to privilege escalation, alongside three Incorrect Authorization findings (CVE-2026-21289, CVE-2026-21309, CVE-2026-21285). APSB26-49 reprised both categories: two more Incorrect Authorization auth bypasses (CVE-2026-34645, CVE-2026-34646) and a critical Stored XSS reaching code execution (CVE-2026-34686, CVSS 8.7).

Incorrect Authorization at this frequency points at access control logic that’s distributed across the codebase — the kind of architecture where a new endpoint or module can introduce a gap without touching anything that looks like a security check. Stored XSS recurring across bulletin cycles suggests input handling that’s inconsistent at the point of persistence. Two different root causes, both showing up across two major patch cycles. That’s structural, not bad luck.

The DoS surface is expanding

APSB26-49 added something APSB26-05 didn’t: a cluster of five unauthenticated resource exhaustion vectors, all critical, all requiring no authentication and no admin access.

Four are independent CWE-400 findings (CVE-2026-34648, CVE-2026-34649, CVE-2026-34650, CVE-2026-34651), all CVSS 7.5. The fifth (CVE-2026-34652) comes through a third-party component dependency at the same score.

That fifth one changes the calculus. A DoS vector introduced through a dependency means the attack surface includes code the Commerce core team didn’t write and Adobe’s bulletin doesn’t fully cover. If your Commerce install carries Composer packages beyond the default set — and it almost certainly does — the exposure footprint for resource exhaustion is larger than any single security bulletin accounts for. Third-party patch cadence is your problem to manage, not Adobe’s.

What six bulletins in fourteen months actually costs

Adobe has shipped more than six Commerce security bulletins since April 2025. If your patching workflow is “engineer reads the bulletin, schedules a Composer update, tests in staging, ships in a two-week window” — the math doesn’t close. You’re structurally behind before you start, and with a CVSS 8.7 path traversal (CVE-2026-34653) and a CVSS 8.7 Stored XSS in the latest bulletin, the cost of that lag is non-trivial.

Shops keeping pace have automated the Composer lockfile update step: a scheduled CI job opens a branch the moment a security release hits Packagist, runs the test suite against it, and puts a PR in front of someone who can approve in hours, not weeks. Security patches shouldn’t require scheduling. When they do, maintenance overhead compounds with every bulletin.

What to do

Merchants:

Check your Commerce version against the APSB26-49 affected versions table. If you’re on 2.4.8-p4 or earlier (or the equivalent patch on your supported line), the full CVE set above is open on your installation.
Treat the two CVSS 8.7 findings (CVE-2026-34653, CVE-2026-34686) as high-priority — these aren’t “next maintenance window” candidates.
Audit your third-party Composer dependency exposure separately from Adobe’s bulletins. CVE-2026-34652 is the model case for why.

Agencies and integrators:

Automate Composer security patch delivery across your client fleet — a bot that opens a branch on new Packagist security releases, runs tests, and queues a PR for sign-off. The bulletin frequency makes manual scheduling untenable at scale.
Audit your client installs for version compliance before the next bulletin drops. Six bulletins in fourteen months means you’re likely carrying at least one unpatched cycle on slower-moving accounts.
Patch complexity varies: most of APSB26-49 clears with a standard Composer update and cache flush. CVSS 8.7 findings warrant an explicit QA gate before production. Know which bulletins need staging validation and which don’t — blanket “treat every patch the same” policies are why teams fall behind.

Sources: APSB26-49 (Adobe, May 12, 2026) · APSB26-05 (Adobe, March 10, 2026)

APSB26-56: thirty-plus XSS findings in one AEM bulletin — what the batch tells you

Wed, 10 Jun 2026 00:00:00 +0000

Adobe published APSB26-56 on June 9, 2026 — a security update for Adobe Experience Manager 6.5 and AEM as a Cloud Service. The advisory contains at least 36 cross-site scripting vulnerabilities, the overwhelming majority of them stored XSS, each carrying CVSS 5.4.

That number matters more than the severity score.

What the bulletin contains

Every finding in APSB26-56 shares the same profile: cross-site scripting via improper output encoding, low-privilege exploitation path (authenticated author access required), CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N.

Confirmed stored XSS CVEs (27): CVE-2026-47936, CVE-2026-47939, CVE-2026-47941, CVE-2026-47942, CVE-2026-47943, CVE-2026-47944, CVE-2026-47945, CVE-2026-47948, CVE-2026-47949, CVE-2026-47950, CVE-2026-47951, CVE-2026-47953, CVE-2026-47954, CVE-2026-47956, CVE-2026-47957, CVE-2026-47958, CVE-2026-47962, CVE-2026-47966, CVE-2026-47970, CVE-2026-47972, CVE-2026-47973, CVE-2026-47974, CVE-2026-47975, CVE-2026-47977, CVE-2026-47978, CVE-2026-47980, CVE-2026-47981

Confirmed DOM-based XSS CVEs (9): CVE-2026-47935, CVE-2026-47946, CVE-2026-47947, CVE-2026-47982, CVE-2026-47983, CVE-2026-47985, CVE-2026-47986, CVE-2026-47987, CVE-2026-47989

The bulletin’s full CVE list is longer than what was enumerated here — the advisory page truncates on initial load. The 36 above are confirmed; the actual total is likely higher.

The exploitation surface: AEM content authoring interfaces. An author-level account, or an author who pastes content from an untrusted source, can plant a payload that executes in any session that renders it. No administrative access required.

CVSS 5.4 looks modest against a remote code execution finding, but the effective blast radius is wider in practice. Content editors typically operate the most public-facing interfaces in an AEM deployment. A stored XSS in that context can reach site visitors, not just other authenticated users.

Why a batch of 36 says more than any individual CVE

A single stored XSS finding is noise. A batch of 36 from the same systematic audit is signal.

When Adobe identifies this many findings in a single bulletin, it indicates a coordinated security review of AEM’s component layer — not routine vulnerability triage. The review already happened. The bugs that would surface in an equivalent review of your current version have already been found; you either have the fix or you are running exposed.

There is a specific implication for teams on earlier service packs: the vulnerabilities that this audit surfaced exist across the prior service pack tree until patched. A team on 6.5.22 or 6.5.23 carries all 36 of these plus whatever the prior audit cycles fixed that they have not yet applied.

Batch disclosure is a trailing indicator of systematic review. APSB26-56’s 36 findings represent one audit cycle. The next cycle will produce another bulletin.

The upgrade cadence argument

APSB26-56 is addressed in AEM 6.5.24 and AEM as a Cloud Service (auto-applied). This is not an emergency hotfix — it is a service pack release. The fix has been available since June 9.

Teams running deferred upgrade cycles are making a specific trade: testing overhead of service pack validation against ongoing CVE exposure. For a single-CVE bulletin, that trade can be defensible. For a bulletin with 36 XSS findings against the author interface, the calculus is different.

Some specific implications:

If your cycle puts you more than one service pack behind, you are carrying CVEs from at least two bulletin cycles.
AEM 6.5.x ships quarterly service packs. A “wait for the next maintenance window” that stretches to six months is two full bulletin cycles of exposure.
Each skipped service pack is not just the CVEs in that bulletin — it is that bulletin plus the systematic audit that produced it, applied to whichever component class Adobe reviewed next.

Upgrade cadence is not a development operations preference. It is a security posture decision with cumulative exposure in both directions.

What to do

Check your version. AEM 6.5.24 addresses APSB26-56. Confirm your service pack level against the bulletin before your next maintenance window.
Prioritize 6.5.24 if you are on 6.5.22 or earlier. You are carrying these 36 CVEs plus the delta from any skipped service packs between your current version and 6.5.24.
Review your author trust model. Output encoding in custom components is defense-in-depth that reduces stored XSS surface regardless of patch level. If your authors routinely paste content from external sources, that review is worth running independently of your service pack schedule.
Track service pack cadence as a security metric. How many service packs you are behind is a meaningful proxy for unpatched CVE exposure, particularly when Adobe’s systematic audits are producing batches of this size.

The 36 CVEs will be in your scanner by now. The batch pattern — a systematic component audit producing 36 findings across a single bulletin — is the signal worth acting on.

Sources: APSB26-56 — Security update available for Adobe Experience Manager (Adobe, June 9, 2026)

Before the Next Wave: What Magento Shops Must Do After the Composer Token Leak

Wed, 10 Jun 2026 00:00:00 +0000

On May 12, 2026, the PHP ecosystem had a near-miss that deserves more attention than it received. The post-mortem from the graycoreio maintainer — who runs the canonical GitHub Actions suite for Magento and Mage-OS — is worth reading in full. Here is the operational summary for Commerce shops.

What happened

GitHub began rolling out a new format for App installation tokens. The new format includes characters (-) that Composer’s existing token validator rejected. When Composer threw the validation exception, it included the literal token value in the error message. Symfony Console rendered that message to stderr before the Actions runner could mask it — bypassing the secret masker’s substring match.

For roughly 14 hours (2026-05-12 ~22:00 UTC to 2026-05-13 ~14:30 UTC), any workflow that ran composer install after shivammathur/setup-php on a push, pull_request_target, or schedule trigger had its GITHUB_TOKEN printed in plaintext to a world-readable Actions log.

The typical GITHUB_TOKEN on a push workflow carries contents: write by default. That is enough to push commits and tags to the repo it came from.

Why Magento shops specifically should care

The graycoreio maintainer caught this while working on Magento 2.4.9 release support. His report named the repos where failures were visible during the window: composer/composer itself, laravel/framework, sylius, woocommerce, and others.

For Magento deployments, the supply chain path is direct: Magento and Mage-OS are Composer projects. Packagist polls GitHub for new tags and publishes them automatically. A successful exfil-and-push against any sufficiently popular Composer package resolves as remote code execution on every store that runs composer install before the rollback.

The maintainer has a working proof of concept: a stolen token can push to main in under a second with a polling setup. The window is narrow, but it is real.

This is not over

Composer shipped patched releases (2.9.8 / 2.2.28 / 1.10.28) and GitHub paused the rollout. GitHub will resume the format change. The fix has to be in place before the next wave.

What to do

Bump Composer in CI. If your workflows pin Composer — tools: composer:v2.8.1 in setup-php, or a hardcoded version anywhere — unpin it or bump to 2.9.8 / 2.2.28 / 1.10.28. Unpatched Composer is the entire attack surface here.

Add an explicit permissions: block. Workflows without one inherit the legacy permissive default (contents: write). Add permissions: contents: read at the top of every workflow that does not need write access. Most CI jobs do not.

Protect your tags. The practical attack vector is pushing a tag to trigger a Packagist release. Enable GitHub tag protection rules on your repos. Branch protection alone does not cover tags — that distinction matters here.

Sweep your logs for the window. Look at failed runs between 2026-05-12 22:00 UTC and 2026-05-13 14:30 UTC. If you see a ghs_… string in any rendered output, your token was exposed. Then run:

git log --since='2026-05-12T22:00Z' --until='2026-05-13T14:30Z' --all
git tag --sort=creatordate

Check both for anything you do not recognize.

Review failure-upload steps. If you have actions/upload-artifact on if: failure() steps, those extend the live-token window while the upload runs — for large test fixtures this can be minutes, not seconds. Consider whether those steps need the token in scope, or whether the artifact upload can be moved outside the token’s lifetime.

The broader lesson

The person who caught this describes himself as a small fish. He caught it because he was actively working on Magento 2.4.9 support, noticed intermittent CI failures that did not match any change he had made, and dug in. His immediate actions — disabling actions org-wide, reaching out to Laravel and Mage-OS Discord, filing the Composer advisory — almost certainly kept this from being exploited.

The ecosystem’s defense was accidental: Composer fails loudly, tokens are repo-scoped and short-lived, the rollout was gradual. None of that is engineered defense-in-depth. The checklist above is the engineered version. With the next rollout wave coming, there is no reason to wait.

Sources: graycoreio/github-actions-magento2 #261 · CVE-2026-45793 / GHSA-f9f8-rm49-7jv2 · Composer 2.9.8 release notes

GorgonAgora: Inside the 4,800-Storefront Checkout Skimming Machine

Wed, 03 Jun 2026 00:00:00 +0000

Security researcher Hunter Heaivilin has been mapping a skimming operation called GorgonAgora since August 2025. The dataset he handed to Sansec confirmed 4,880 fake storefronts — and urlscan.io’s CSS fingerprint matching suggests the real number is already above 6,000.

The attack pattern differs from classic magecart. GorgonAgora doesn’t touch your store. The operator scraped product catalogs from real Shopify storefronts belonging to hundreds of brands — Starbucks, Nike, Ford, Sony, Disney, Lego, DJI and more — and rebuilt each one as a lookalike on a .shop domain. Every store runs Medusa.js as its commerce backend. Every checkout loads the same SDK: payment-vanilla.iife.js.

How PaymentVanilla works

When a shopper reaches checkout, the SDK injects a pixel-perfect fake Stripe iframe. The real Stripe is never involved. Card data flows to a WebSocket endpoint at an AlexHost server in Moldova, encrypted with AES-256-GCM. If the victim’s bank returns a 3DS challenge, the operator relays it back through the fake iframe. The transaction completes. The shopper believes they bought from a real brand.

The 3DS relay is what makes this particularly effective — victims have no immediate signal that anything went wrong.

Two generations, one fingerprint

The operator made one structural upgrade in late March 2026, switching from a single shared Medusa database (~339 stores, one publishable API key fronting 544 brand catalogs) to individual Medusa instances per storefront (~4,500+ stores). The shared-key enumeration hole is gone. Everything else is unchanged: same CSS bundle (d482fd41f7f1f379.css), same JS chunk, same skimmer SDK, same C2. The network is trivially fingerprintable despite the backend refactor.

What to do

For brand owners: Search urlscan.io using filename:d482fd41f7f1f379.css to find storefronts cloning your catalog. The operator scrapes from real Shopify stores, so trademark and DMCA takedowns typically work fast once you identify a clone. Set up ongoing brand monitoring for your domain variants — the .shop TLD is the current pattern, but it’s a template.

For shoppers: If you transacted on a .shop domain in the IOC list, treat the card as compromised and request a replacement.

Full technical write-up including C2 IPs, SDK hashes, and the complete sample domain list: sansec.io/research/gorgonagora-fake-storefront-skimming-network

The Perforce Driver You Never Knew You Had: Composer CVE-2026-40261 and CVE-2026-40176

Sat, 23 May 2026 10:00:00 -0500

Update Composer to 2.9.6 or 2.2.27 LTS now. If that sentence is enough, you’re done. If you want to understand why this one is worth a closer look, keep reading.

Background: the Composer maintainers published their own writeup of these advisories on the Packagist blog. The technical details and the registry-level mitigations described below come from that post; this piece is the operator’s read for commerce teams.

Quick Refresher: Composer, Drivers, and Why Perforce Is in There

If you don’t live in PHP-land daily, this advisory reads as opaque, so a thirty-second primer.

Composer is the dependency manager every modern PHP project uses. For Magento and Adobe Commerce specifically, it is how the core platform itself ships and how every module — first-party, third-party, your own internal libraries — gets installed and updated. When a developer runs composer install on a fresh Magento checkout, Composer reads composer.json, resolves the dependency graph, downloads each package, and assembles vendor/. When CI deploys a release, it runs the same command. There is no Magento install today that does not run Composer many times a day.

A composer.json lists each dependency along with where to fetch it from. Most packages come from Packagist (the public PHP registry) or its commercial sibling Private Packagist. But you can also point Composer directly at a source-control repository — a git URL, a mercurial repo, a subversion checkout, or a Perforce depot. To do that, you declare a repository in composer.json with a type: field naming which version-control system to use. Composer ships with a VCS driver for each supported type — git, svn, hg, fossil, perforce — that knows how to clone, list versions, and fetch source from that system.

The Perforce driver is one of those bundled drivers. It exists because Perforce is the dominant version-control system in game studios, large enterprises with legacy commercial codebases, and some sectors of finance and manufacturing — places where PHP shops occasionally need to pull a package from a Perforce depot. The driver is shipped with Composer by default. It loads regardless of whether you have ever configured a Perforce repository. That last point is the whole story of this CVE.

The Perforce Driver Is Loaded Whether You Use It or Not

CVE-2026-40261 and CVE-2026-40176 are both in Composer’s Perforce VCS driver - the code that handles repositories declared as perforce type in a composer.json. Neither requires Perforce to be installed. Both allow arbitrary command execution in the context of whatever runs composer install or composer update.

That’s the part the advisory buries in the third paragraph. Most Magento shops have never configured a Perforce repository and have no intention of doing so. That doesn’t matter. The vulnerable code path loads regardless, and an attacker-controlled composer.json or package metadata can reach it.

Two Different Attack Surfaces

CVE-2026-40176 requires the attacker to control the composer.json you’re actually running - the root manifest. The injected values are Perforce connection parameters (port, user, client) that get interpolated into shell commands without escaping. This is the local-project risk: if you’re running Composer commands on a project from an untrusted source, this fires.

CVE-2026-40261 is the wider problem. It affects the syncCodeBase() method, which handles a source reference parameter that can come from package metadata - not just the root composer.json. That means any Composer repository, including a compromised or malicious third-party repository, can serve package metadata that exploits this. You don’t have to touch the root manifest. You just have to install or update a dependency from source.

The trigger condition: installing dev-prefixed versions (anything before 1.0.0, or packages with dev- prefix) defaults to –prefer-source in Composer. Commerce agencies running Magento module development pipelines almost certainly have some dev-constraint packages in their dependency tree.

What This Means for a Magento and Commerce Pipeline

Enterprise commerce platforms run layered dependency graphs. The core is typically Magento/Adobe Commerce, which comes from the Magento Composer repository. Third-party modules come from a mix of Packagist, private repositories, and occasionally vendor-managed repos. Development workflows - module builds, staging deploys, CI pipelines - regularly operate with dev- constraints to pull HEAD on in-development extensions.

In that environment, CVE-2026-40261 is not hypothetical. Any point in the supply chain where package metadata can be influenced - a compromised private repo, a package repository serving malicious metadata, a CI secret that got rotated too late - becomes a command injection entry point into your build environment. The build environment has access to credentials, cloud provider tokens, and staging infrastructure that production doesn’t expose directly.

The patch notes say there’s no evidence of exploitation prior to publication. That’s the standard disclosure language and it’s worth taking at face value. It also doesn’t change the update calculus.

Packagist and Private Packagist Already Moved

Packagist.org disabled Perforce source metadata on April 10, 2026 as a precaution. Private Packagist did the same. If your dependencies come exclusively from these sources and you’re not running –prefer-source against anything that reaches Perforce metadata, your exposure was already mitigated at the registry layer.

If you run Private Packagist Self-Hosted, the new release is dropping now - and you should scan your installation using the verification command the release announcement documents before relying on the registry-level mitigation.

The Practical Calls

Run composer.phar self-update on every machine and CI runner that executes Composer commands. This includes local dev environments - dev machines are a vector, not just pipelines.
If you can’t update immediately, –prefer-dist in your installs eliminates the CVE-2026-40261 exposure by avoiding the source-fetch path. It’s a workaround, not a fix.
For CVE-2026-40176: review any composer.json files you run Composer commands against and aren’t fully trust-anchored. If your dev workflow clones external projects and runs composer install on them without inspection, that’s a habit worth fixing regardless of this CVE.
Audit your private Composer repositories for Perforce-type source declarations. These should not exist in commerce dependency graphs. If they do, understand why.

This is a straightforward dependency update with a clear fix. The reason it’s worth editorial attention is the “doesn’t affect Perforce users” misread - the relevant audience here is every team running a PHP/Composer-based build pipeline, which in the commerce world is essentially everyone.

Three Signals from November: What the Bulletins Don't Say

Wed, 26 Nov 2025 09:00:00 -0500

Three items from the November 2025 bulletin queue, taken individually, look like routine security hygiene. Together they tell a different story.

The Setup: Xurum Is Still Running Playbooks from 2022

The Xurum webshell campaign that Akamai documented isn’t new technique — it targets a known Magento vulnerability and deploys a sophisticated webshell that fingerprints server environment, exfiltrates payment data, and provides persistent shell access. What’s notable is that the campaign is still running, which means:

A meaningful percentage of Magento installs are still unpatched against a well-documented attack chain.
The attacker tooling has matured — Xurum has environment-awareness that older skimmer campaigns lacked.

The practical read for commerce ops teams: if you’re running a Magento instance and haven’t validated your patching posture against Akamai’s published indicators, do that before reading the rest of this.

The Risk That Patch Notes Don’t Quantify: CVE-2025-54236

CVSS 9.1. Adobe Commerce. No user interaction required. Session takeover.

The APSB25-88 advisory covers an improper input validation vulnerability affecting Adobe Commerce through 2.4.8-p2 and back to 2.4.4-p15. What the advisory doesn’t foreground: in a multi-store environment where admin sessions are long-lived (common in managed service deployments), “session takeover” means an attacker who can reach your admin panel URL has a path to full platform control without needing to know a single credential.

The patch is available. The gap is the deployment window. A vulnerability that requires no user interaction closes fast in the wild once PoC code circulates — and for a CVSS 9.1 Adobe Commerce advisory, that window is short. If you’re on any affected version and your deployment pipeline adds days of testing overhead before applying security patches, that’s the thing worth fixing.

The Sleeper: CVE-2025-64174 and Admin DB Access Assumptions

The Magento-lts stored XSS (fixed in 20.16.0) requires an admin with direct database access or control over the admin notification feed source. That sounds narrow. It isn’t.

In practice, multi-vendor commerce deployments frequently involve third-party integrations that touch the database directly — ETL pipelines, ERP connectors, PIM syncs. Any of those that write to notification tables or translation strings without sanitizing output are an injection vector that bypasses the application layer entirely. The “requires admin DB access” framing in the CVE undersells the real-world exposure surface.

The Pattern

All three of these point at the same underlying gap: Commerce platform security posture is often evaluated at the application layer (patches applied, WAF rules updated) while the actual attack surface extends further — into long-lived sessions, admin-adjacent integrations, and deployment lag. The bulletins report what’s been patched. The editorial job here is flagging what that means for how you run the platform.

That’s what this blog is for.