shopify_app CVE-2026-63414

Exploitation requires all of the following: (1) the application uses shopify_app token-exchange authentication; (2) it accepts authenticated controller requests where a shop query parameter may be present; and (3) it relies on current_shopify_domain or params[:shop] for authorization decisions, tenant lookup, stored access-token selection, or shop-scoped resource access on a vulnerable version (>= 22.1.0, < 23.0.3). The attacker must already possess a valid Shopify session/ID token for at least one shop (PR:L authenticated), supplied for example by installing the app on their own store. Limiting factors that reduce real risk: apps that derive shop identity from current_shopify_session.shop or the verified JWT dest value are NOT vulnerable even on affected versions; there is no unauthenticated path; and the flaw only yields cross-shop access when the application actually trusts the requested shop parameter for security-sensitive scoping. The vendor states upgrading to 23.0.3 is the fix; the documented workaround is to validate params[:shop] against the authenticated shop and reject mismatches with 401.

This is a genuine but conditional authorization flaw (CWE-863), not a blanket critical. The provided CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N, score 7.6 High) is internally consistent with the description: network-reachable, low attacker complexity, but PR:L means the attacker must already hold a valid Shopify session/ID token for at least one shop, and AT:P reflects that the target application must actually rely on the untrusted shop context for security decisions. No EPSS score was supplied and the CVE is not on CISA KEV, so there is no signal of mass or active exploitation; exploitation status is 'no public exploit identified at time of analysis' - the GitHub references are the fix commit/PR and advisory, not weaponized exploit code. The vuln.today decision label is 'this_week', consistent with a patched, authenticated, exploitation-dependent library flaw rather than an emergency. The real priority is bounded: the vulnerability only matters for apps that use shopify_app token-exchange authentication AND consume current_shopify_domain or params[:shop] for authorization, tenant lookup, access-token selection, or shop-scoped data - many apps that use the authenticated session object directly are unaffected. The most important missing signal is population-level: there is no data on how many deployed Shopify apps actually follow the vulnerable coding pattern, so blast radius must be assessed per-application. Where the pattern is present, impact is real cross-shop/cross-tenant data access and actions.

An attacker who legitimately installed the vulnerable Shopify app on their own shop (Shop A) obtains a valid Shopify session/ID token, then sends an authenticated controller request that additionally carries shop=victim-shop.myshopify.com as a query parameter. If the app uses current_shopify_domain or params[:shop] for shop scoping on vulnerable versions (>= 22.1.0, < 23.0.3), the application code operates in Shop B's context, exposing or modifying another merchant's data. No public exploit code is identified at time of analysis; the published artifacts are the fix (PR #2081 / commit a09ccc0) and the GHSA advisory.