Adobe Commerce merchants got a security patch on July 14, 2026, and two of the flaws it closes need no login at all. APSB26-73 fixes 13 vulnerabilities across Adobe Commerce and Magento Open Source, and the two that matter most can be reached by an unauthenticated attacker. If you run a Magento storefront, this is a patch-this-week item, not a next-sprint one.
What Adobe shipped in APSB26-73
APSB26-73 is a scheduled Adobe Commerce security update, released July 14, 2026, that resolves 13 vulnerabilities rated critical, important and moderate. Successful exploitation could lead to arbitrary code execution, security feature bypass and privilege escalation, per Adobe's security bulletin. The affected builds are Adobe Commerce 2.4.9, 2.4.8-p5 and earlier, 2.4.7-p10 and earlier, 2.4.6-p15 and earlier, 2.4.5-p17 and earlier, and 2.4.4-p18 and earlier, along with the matching Magento Open Source and B2B lines. The flaw categories span incorrect authorization, server-side request forgery, stored cross-site scripting, path traversal and uncontrolled resource consumption. Adobe says it is not aware of any exploits in the wild for these issues at release. That last line is the one merchants misread every time. No exploit today is not the same as no exploit next week, and Magento has a long history of unauthenticated bugs going from bulletin to mass scanning in days.
The two flaws that need no admin login
CVE-2026-34646 and CVE-2026-34647 are the two to fix first, because neither requires an admin account. CVE-2026-34646 is an incorrect-authorization flaw (CWE-863) scored CVSS 7.5. Adobe's advisory describes a remote, unauthenticated attacker gaining unauthorized write access with no credentials and no user interaction, per the NVD entry. That is the profile that gets weaponized. Write access on a storefront is how attackers plant skimmers on checkout pages. CVE-2026-34647 is a server-side request forgery flaw (CWE-918) scored CVSS 7.4. It needs no privileges either, though it does require a victim to interact with a crafted URL, and it yields unauthorized read access plus a security feature bypass. SSRF on a commerce backend is a pivot: it lets an attacker reach internal services the storefront can see and the public internet cannot. Neither of these is the loud remote-code-execution headline. Both are the quiet mid-sevens that do the real damage on e-commerce, because money and card data sit one step past them.
Isolated patch vs full version upgrade
The isolated patch is the fast fix and a full version upgrade is the durable one, and for APSB26-73 Adobe ships both. The isolated patch is a version-specific archive, for example 2-4-9-jul-2026.zip, that applies only the security fixes without the feature and dependency changes a full upgrade drags in. That is the pragmatic path for a live premium storefront where a full 2.4.x upgrade means a regression-test cycle you cannot run before the weekend. There is a prerequisite the release notes are strict about: you must already be on the latest security-only patch for your line before the isolated patch will apply, per Adobe's release note. Merchants still on 2.4.5 or 2.4.4 also need Composer credentials to pull the patch. A full version upgrade is still the right destination. The isolated patch buys you time. It does not buy you a maintained platform. If you are several minor versions behind, the honest reading is that the isolated patch is triage and the upgrade is the treatment.
Why it matters, and what to fix this quarter
Apply APSB26-73 this week, lead with the two unauthenticated CVEs, and use the isolated patch if a full upgrade cannot ship before the weekend. For a premium Magento storefront, the metric that matters here is time-to-patch, not the CVSS score. A brand doing real revenue on Adobe Commerce in Jakarta or Singapore is a more attractive target than its traffic rank suggests, because card data and a checkout flow are worth more than pageviews. The pre-auth authorization bug is exactly the class of issue that historically turned unpatched Magento stores into card-skimming hosts within a week of disclosure. This is why we treat security patching as scheduled engineering on our Magento and Hyva commerce work, not as an emergency we react to. A Hyva front-end does not change any of this. Hyva replaces the theme layer, but the vulnerable code here lives in the Magento application and backend, so a fast, modern storefront on an unpatched core is still an unpatched core. If you are still planning a Luma to Hyva migration, fold the security-patch baseline into that project rather than treating it as separate work.
Confirm your current patch level first, because the isolated patch will not apply unless you are on the latest security-only release for your line. If you cannot patch immediately, put a virtual patch on the two unauthenticated CVEs at the WAF, but treat that as a stopgap measured in days, not a fix. Then fix the process, not just this bulletin. Adobe ships commerce security updates on a schedule, so a store that scrambles every quarter has a pipeline problem, not a patching problem. We wire security-patch checks into the same deployment automation that runs the rest of the release, so applying a bulletin is a normal deploy with a normal regression run behind it. Subscribe to the Adobe security bulletin feed, keep a staging environment that mirrors production closely enough to test a patch in an afternoon, and know your current version and patch level at all times. The stores that get skimmed are almost never the ones that could not patch. They are the ones that did not know they were behind.