Live › vulnerability › CVE-2026-63414
The shopify_app Ruby gem's token-exchange controllers could resolve the current shop from a request's shop query parameter instead of the verified Shopify token or session. An attacker holding a valid session for one shop can act on another shop's data by supplying a different shop parameter.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-29 16:44 UTC. All times on this page are UTC.
Apps that use shopify_app token-exchange authentication and rely on current_shopify_domain or the request shop parameter for authorization, tenant lookup, stored token selection, or shop-scoped data access. Apps that only use the verified session shop, or that do not use token exchange, are not described as exposed. Applications that cannot upgrade should reject requests whose sanitized shop parameter does not match the authenticated shop.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| shopify_app | rubygems | >= 22.1.0, < 23.0.3 | 23.0.3 |
bundle exec gem list shopify_app or inspect Gemfile.lock for shopify_app.current_shopify_domain or params[:shop] in authorization, tenant lookup, or access-token selection.shopify_app 23.0.3 (affected range: >= 22.1.0, < 23.0.3)Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In token-exchange authenticated controllers, shopify_app exposes shop context through helpers such as current_shopify_domain. Prior to the fix, current_shopify_domain could resolve to the sanitized shop query parameter instead of the shop identity derived from the verified Shopify ID token or active Shopify session.
As a result, a request authenticated for one shop could include a different shop query parameter, causing application code to treat the requested shop as the current shop.
Applications that used current_shopify_domain, or the request shop parameter, for authorization decisions, tenant lookup, stored access-token selection, or shop-scoped data access may have been vulnerable to cross-shop context confusion.
The patched version hardens token-exchange handling so that:
current_shopify_domain resolves to the authenticated shop from the verified token or session.authenticated_shopify_domain exposes the trusted authenticated shop.requested_shopify_domain exposes the sanitized requested shop parameter for bootstrap or routing use cases only.401 Unauthorized when the requested shop does not match the authenticated shop.In affected applications, an attacker with a valid Shopify session token for one shop could send an authenticated request that also supplied a different shop query parameter. If the application relied on current_shopify_domain or params[:shop] for security-sensitive shop scoping, application code could operate in the context of the requested shop rather than the authenticated shop.
Affected applications are those that:
shopify_app token-exchange authentication;shop query parameter may be present; andcurrent_shopify_domain or the request shop parameter for authorization, tenant lookup, stored access-token selection, or shop-scoped resource access.Depending on the application’s authorization model, this could result in unauthorized access to another shop’s application data or unauthorized shop-scoped actions.
Upgrade to shopify_app version 23.0.3
Applications that cannot upgrade immediately should apply equivalent validation in token-exchange authenticated controllers:
params[:shop] for authorization, tenant lookup, access-token selection, or data scoping.current_shopify_domain for security-sensitive shop scoping if a shop query parameter may be present.current_shopify_session.shop or the verified JWT dest value.
params[:shop] value is present, reject the request with 401 Unauthorized when it does not match the authenticated shop.This issue was responsibly reported by Hackerone researcher leqtuer.
This page as .md · .json · in your agent: get_signal("CVE-2026-63414")
GitHub Advisory Database, CC-BY 4.0. Posts quoted belong to their authors.