Adobe Commerce EUVD-2026-44414

Exploitation requires the attacker to already hold a high-privileged (administrative or equivalent) authenticated account on the Adobe Commerce / Magento instance - the CVSS vector's PR:H makes elevated privileges a hard prerequisite and is the primary factor limiting real-world exploitation. Beyond that, the issue is reachable over the network (AV:N) with low complexity (AC:L) and no user interaction (UI:N), and no additional non-default configuration is called out in the available data. Impact is limited to unauthorized read access (confidentiality high, C:H); integrity is not affected (I:N) and availability impact is minor (A:L). Because the specific vulnerable feature or endpoint is not detailed in the description, defenders should treat any privileged admin, API, or Webhooks-plugin access as within the exploitable surface and consult APSB26-73 for specifics.

The CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:L, base 7.6) describes a network-reachable, low-complexity issue that nonetheless requires high privileges (PR:H) - the attacker must already hold an elevated/administrative account, which is the single largest limiting factor and pulls real-world risk well below what the network vector alone might suggest. The scope change (S:C) and high confidentiality impact (C:H) raise severity because the read exposure can cross a trust boundary. No EPSS score was supplied, there is no CISA KEV listing, and no public POC is referenced, so all signals point to a genuine but not urgent issue: a real priority for internet-facing commerce deployments given the sensitivity of customer and order data, but gated behind existing privileged access rather than mass-exploitable. The absence of EPSS and exploitation telemetry should be explicitly noted and confirmed against Adobe advisory APSB26-73 before final triage.

An attacker who has obtained a high-privilege Adobe Commerce account - for example a compromised administrator or a malicious insider - sends crafted requests over the network to the affected functionality. Because the authorization check is applied incorrectly, the platform returns restricted data the account should not be able to read, and the changed scope lets that exposure extend to resources beyond the immediately targeted component. No user interaction is required, and no public exploit code is identified at time of analysis.