GHSA-6J52-38F8-QHXR

Vulnerability from github – Published: 2026-10-29 16:39 – Updated: 2026-10-29 16:39
VLAI
Summary
Shopify App: Token exchange shop context confusion may allow cross-shop authorization bypass in affected apps
Details

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. - Token-exchange requests are rejected with 401 Unauthorized when the requested shop does not match the authenticated shop.

Impact

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:

  1. Use shopify_app token-exchange authentication;
  2. Accept authenticated controller requests where a shop query parameter may be present; and
  3. Use current_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.

Remediation

Upgrade to shopify_app version 23.0.3

Workarounds

Applications that cannot upgrade immediately should apply equivalent validation in token-exchange authenticated controllers:

  • Do not use params[:shop] for authorization, tenant lookup, access-token selection, or data scoping.
  • On vulnerable versions, avoid relying on current_shopify_domain for security-sensitive shop scoping if a shop query parameter may be present.
  • Use the authenticated shop from the verified ID token or active Shopify session instead, such as current_shopify_session.shop or the verified JWT dest value.
  • If a sanitized params[:shop] value is present, reject the request with 401 Unauthorized when it does not match the authenticated shop.

Credit

This issue was responsibly reported by Hackerone researcher leqtuer.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "shopify_app"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "22.1.0"
            },
            {
              "fixed": "23.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-63414"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-29T16:39:49Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "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.\n\nAs 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.\n\nApplications 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.\n\nThe patched version hardens token-exchange handling so that:\n   - `current_shopify_domain` resolves to the authenticated shop from the verified token or session.\n   - `authenticated_shopify_domain` exposes the trusted authenticated shop.\n   - `requested_shopify_domain` exposes the sanitized requested `shop` parameter for bootstrap or routing use cases only.\n   - Token-exchange requests are rejected with `401 Unauthorized` when the requested shop does not match the authenticated shop.\n\n## Impact\n\nIn 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.\n\nAffected applications are those that:\n\n   1. Use `shopify_app` token-exchange authentication;\n   2. Accept authenticated controller requests where a `shop` query parameter may be present; and\n   3. Use `current_shopify_domain` or the request `shop` parameter for authorization, tenant lookup, stored access-token selection, or shop-scoped resource access.\n\nDepending on the application\u2019s authorization model, this could result in unauthorized access to another shop\u2019s application data or unauthorized shop-scoped actions.\n\n## Remediation\nUpgrade to `shopify_app` version `23.0.3`\n\n## Workarounds\nApplications that cannot upgrade immediately should apply equivalent validation in token-exchange authenticated controllers:\n\n- Do not use `params[:shop]` for authorization, tenant lookup, access-token selection, or data scoping.\n- On vulnerable versions, avoid relying on `current_shopify_domain` for security-sensitive shop scoping if a `shop` query parameter may be present.\n- Use the authenticated shop from the verified ID token or active Shopify session instead, such as `current_shopify_session.shop` or the verified JWT `dest` value.\n   - If a sanitized `params[:shop]` value is present, reject the request with `401 Unauthorized` when it does not match the authenticated shop.\n\n## Credit\n\nThis issue was responsibly reported by Hackerone researcher [leqtuer](https://hackerone.com/leqtuer?type=user).",
  "id": "GHSA-6j52-38f8-qhxr",
  "modified": "2026-10-29T16:39:49Z",
  "published": "2026-10-29T16:39:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Shopify/shopify_app/security/advisories/GHSA-6j52-38f8-qhxr"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Shopify/shopify_app"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Shopify/shopify_app/releases/tag/v23.0.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Shopify App: Token exchange shop context confusion may allow cross-shop authorization bypass in affected apps"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
Events included in the timeline

Loading timeline…


    Loading…

    Loading…

    Loading…

    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.