Vulnerability-Lookup

CVE-2026-48012 (GCVE-0-2026-48012)

Vulnerability from cvelistv5 – Published: 2026-07-23 19:16 – Updated: 2026-07-24 13:31

Title

Shopware SSO referer trust leading to an arbitrary redirect target

Summary

Shopware is an open commerce platform. Versions 6.7.3.0 through 6.7.10.0 have an open redirect in Shopware's public SSO entry point at `GET /api/oauth/sso/auth`. When the endpoint is reached without the expected SSO session state, the application falls back to the request's `Referer` header and uses that value as the redirect destination. In the validated behavior, the server does not restrict that fallback target to same-origin URLs, does not require a relative path, and does not reject dangerous schemes such as `javascript:`. As a result, an unauthenticated request can turn this endpoint into a reusable redirect primitive whose destination is fully controlled by attacker-supplied request metadata. The security problem is not limited to a harmless navigation mismatch. The endpoint sits under `/api/oauth/`, which gives the redirect a trustworthy application-controlled origin and makes it suitable for phishing chains, branded redirect abuse, and cases where client software automatically follows redirects issued by a trusted host. The attached evidence also shows that the response is not only an HTTP `302` with a user-controlled `Location` header. The HTML body contains a matching meta refresh tag and redirect link built from the same attacker-controlled value. In the validated proof, the endpoint redirects to `https://attacker.example/poc` when that URL is supplied through `Referer`, and it also reflects `javascript:alert(1)` into `Location` and the HTML redirect body without any scheme filtering. This report therefore stays conservative and claims an open redirect with arbitrary redirect targets, while noting that the lack of scheme restrictions makes the behavior materially worse than a same-scheme external redirect. Version 6.7.10.1 fixes the issue.

Severity

4.3 (Medium)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N

SSVC

Exploitation: poc Automatable: no Technical Impact: partial

CISA Coordinator (v2.0.3)

CWE

CWE-601 - URL Redirection to Untrusted Site ('Open Redirect')

Assigner

GitHub_M

References

2 references

URL	Tags
https://github.com/shopware/shopware/security/adv…	x_refsource_CONFIRM
https://github.com/shopware/shopware/releases/tag…	x_refsource_MISC

Impacted products

2 products

Vendor	Product	Version
shopware	shopware	Affected: >= 6.7.3.0, < 6.7.10.1
shopware	platform	Affected: >= 6.7.3.0, < 6.7.10.1

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-48012",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-24T13:31:15.186146Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-24T13:31:43.099Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/shopware/shopware/security/advisories/GHSA-4x3x-869w-xx3m"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "shopware",
          "vendor": "shopware",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 6.7.3.0, \u003c 6.7.10.1"
            }
          ]
        },
        {
          "product": "platform",
          "vendor": "shopware",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 6.7.3.0, \u003c 6.7.10.1"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Shopware is an open commerce platform. Versions 6.7.3.0 through 6.7.10.0 have an open redirect in Shopware\u0027s public SSO entry point at `GET /api/oauth/sso/auth`. When the endpoint is reached without the expected SSO session state, the application falls back to the request\u0027s `Referer` header and uses that value as the redirect destination. In the validated behavior, the server does not restrict that fallback target to same-origin URLs, does not require a relative path, and does not reject dangerous schemes such as `javascript:`. As a result, an unauthenticated request can turn this endpoint into a reusable redirect primitive whose destination is fully controlled by attacker-supplied request metadata. The security problem is not limited to a harmless navigation mismatch. The endpoint sits under `/api/oauth/`, which gives the redirect a trustworthy application-controlled origin and makes it suitable for phishing chains, branded redirect abuse, and cases where client software automatically follows redirects issued by a trusted host. The attached evidence also shows that the response is not only an HTTP `302` with a user-controlled `Location` header. The HTML body contains a matching meta refresh tag and redirect link built from the same attacker-controlled value. In the validated proof, the endpoint redirects to `https://attacker.example/poc` when that URL is supplied through `Referer`, and it also reflects `javascript:alert(1)` into `Location` and the HTML redirect body without any scheme filtering. This report therefore stays conservative and claims an open redirect with arbitrary redirect targets, while noting that the lack of scheme restrictions makes the behavior materially worse than a same-scheme external redirect. Version 6.7.10.1 fixes the issue."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 4.3,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-601",
              "description": "CWE-601: URL Redirection to Untrusted Site (\u0027Open Redirect\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-23T19:16:38.956Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/shopware/shopware/security/advisories/GHSA-4x3x-869w-xx3m",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/shopware/shopware/security/advisories/GHSA-4x3x-869w-xx3m"
        },
        {
          "name": "https://github.com/shopware/shopware/releases/tag/v6.7.10.1",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/shopware/shopware/releases/tag/v6.7.10.1"
        }
      ],
      "source": {
        "advisory": "GHSA-4x3x-869w-xx3m",
        "discovery": "UNKNOWN"
      },
      "title": "Shopware SSO referer trust leading to an arbitrary redirect target"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-48012",
    "datePublished": "2026-07-23T19:16:38.956Z",
    "dateReserved": "2026-05-20T17:44:09.586Z",
    "dateUpdated": "2026-07-24T13:31:43.099Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-48012",
      "date": "2026-07-25",
      "epss": "0.00162",
      "percentile": "0.05778"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-48012\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2026-07-23T20:17:08.777\",\"lastModified\":\"2026-07-24T14:16:27.007\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"Shopware is an open commerce platform. Versions 6.7.3.0 through 6.7.10.0 have an open redirect in Shopware\u0027s public SSO entry point at `GET /api/oauth/sso/auth`. When the endpoint is reached without the expected SSO session state, the application falls back to the request\u0027s `Referer` header and uses that value as the redirect destination. In the validated behavior, the server does not restrict that fallback target to same-origin URLs, does not require a relative path, and does not reject dangerous schemes such as `javascript:`. As a result, an unauthenticated request can turn this endpoint into a reusable redirect primitive whose destination is fully controlled by attacker-supplied request metadata. The security problem is not limited to a harmless navigation mismatch. The endpoint sits under `/api/oauth/`, which gives the redirect a trustworthy application-controlled origin and makes it suitable for phishing chains, branded redirect abuse, and cases where client software automatically follows redirects issued by a trusted host. The attached evidence also shows that the response is not only an HTTP `302` with a user-controlled `Location` header. The HTML body contains a matching meta refresh tag and redirect link built from the same attacker-controlled value. In the validated proof, the endpoint redirects to `https://attacker.example/poc` when that URL is supplied through `Referer`, and it also reflects `javascript:alert(1)` into `Location` and the HTML redirect body without any scheme filtering. This report therefore stays conservative and claims an open redirect with arbitrary redirect targets, while noting that the lack of scheme restrictions makes the behavior materially worse than a same-scheme external redirect. Version 6.7.10.1 fixes the issue.\"}],\"affected\":[{\"source\":\"security-advisories@github.com\",\"affectedData\":[{\"vendor\":\"shopware\",\"product\":\"shopware\",\"versions\":[{\"version\":\"\u003e= 6.7.3.0, \u003c 6.7.10.1\",\"status\":\"affected\"}]},{\"vendor\":\"shopware\",\"product\":\"platform\",\"versions\":[{\"version\":\"\u003e= 6.7.3.0, \u003c 6.7.10.1\",\"status\":\"affected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N\",\"baseScore\":4.3,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"REQUIRED\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"LOW\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":2.8,\"impactScore\":1.4}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2026-07-24T13:31:15.186146Z\",\"id\":\"CVE-2026-48012\",\"options\":[{\"exploitation\":\"poc\"},{\"automatable\":\"no\"},{\"technicalImpact\":\"partial\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-601\"}]}],\"references\":[{\"url\":\"https://github.com/shopware/shopware/releases/tag/v6.7.10.1\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/shopware/shopware/security/advisories/GHSA-4x3x-869w-xx3m\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/shopware/shopware/security/advisories/GHSA-4x3x-869w-xx3m\",\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\"}]}}",
    "vulnrichment": {
      "containers": "{\"cna\": {\"title\": \"Shopware SSO referer trust leading to an arbitrary redirect target\", \"problemTypes\": [{\"descriptions\": [{\"cweId\": \"CWE-601\", \"lang\": \"en\", \"description\": \"CWE-601: URL Redirection to Untrusted Site (\u0027Open Redirect\u0027)\", \"type\": \"CWE\"}]}], \"metrics\": [{\"cvssV3_1\": {\"attackComplexity\": \"LOW\", \"attackVector\": \"NETWORK\", \"availabilityImpact\": \"NONE\", \"baseScore\": 4.3, \"baseSeverity\": \"MEDIUM\", \"confidentialityImpact\": \"NONE\", \"integrityImpact\": \"LOW\", \"privilegesRequired\": \"NONE\", \"scope\": \"UNCHANGED\", \"userInteraction\": \"REQUIRED\", \"vectorString\": \"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N\", \"version\": \"3.1\"}}], \"references\": [{\"name\": \"https://github.com/shopware/shopware/security/advisories/GHSA-4x3x-869w-xx3m\", \"tags\": [\"x_refsource_CONFIRM\"], \"url\": \"https://github.com/shopware/shopware/security/advisories/GHSA-4x3x-869w-xx3m\"}, {\"name\": \"https://github.com/shopware/shopware/releases/tag/v6.7.10.1\", \"tags\": [\"x_refsource_MISC\"], \"url\": \"https://github.com/shopware/shopware/releases/tag/v6.7.10.1\"}], \"affected\": [{\"vendor\": \"shopware\", \"product\": \"shopware\", \"versions\": [{\"version\": \"\u003e= 6.7.3.0, \u003c 6.7.10.1\", \"status\": \"affected\"}]}, {\"vendor\": \"shopware\", \"product\": \"platform\", \"versions\": [{\"version\": \"\u003e= 6.7.3.0, \u003c 6.7.10.1\", \"status\": \"affected\"}]}], \"providerMetadata\": {\"orgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"shortName\": \"GitHub_M\", \"dateUpdated\": \"2026-07-23T19:16:38.956Z\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"Shopware is an open commerce platform. Versions 6.7.3.0 through 6.7.10.0 have an open redirect in Shopware\u0027s public SSO entry point at `GET /api/oauth/sso/auth`. When the endpoint is reached without the expected SSO session state, the application falls back to the request\u0027s `Referer` header and uses that value as the redirect destination. In the validated behavior, the server does not restrict that fallback target to same-origin URLs, does not require a relative path, and does not reject dangerous schemes such as `javascript:`. As a result, an unauthenticated request can turn this endpoint into a reusable redirect primitive whose destination is fully controlled by attacker-supplied request metadata. The security problem is not limited to a harmless navigation mismatch. The endpoint sits under `/api/oauth/`, which gives the redirect a trustworthy application-controlled origin and makes it suitable for phishing chains, branded redirect abuse, and cases where client software automatically follows redirects issued by a trusted host. The attached evidence also shows that the response is not only an HTTP `302` with a user-controlled `Location` header. The HTML body contains a matching meta refresh tag and redirect link built from the same attacker-controlled value. In the validated proof, the endpoint redirects to `https://attacker.example/poc` when that URL is supplied through `Referer`, and it also reflects `javascript:alert(1)` into `Location` and the HTML redirect body without any scheme filtering. This report therefore stays conservative and claims an open redirect with arbitrary redirect targets, while noting that the lack of scheme restrictions makes the behavior materially worse than a same-scheme external redirect. Version 6.7.10.1 fixes the issue.\"}], \"source\": {\"advisory\": \"GHSA-4x3x-869w-xx3m\", \"discovery\": \"UNKNOWN\"}}, \"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-48012\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"poc\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-07-24T13:31:15.186146Z\"}}}], \"references\": [{\"url\": \"https://github.com/shopware/shopware/security/advisories/GHSA-4x3x-869w-xx3m\", \"tags\": [\"exploit\"]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-07-24T13:31:37.320Z\"}}]}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-48012\", \"assignerOrgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"state\": \"PUBLISHED\", \"assignerShortName\": \"GitHub_M\", \"dateReserved\": \"2026-05-20T17:44:09.586Z\", \"datePublished\": \"2026-07-23T19:16:38.956Z\", \"dateUpdated\": \"2026-07-24T13:31:43.099Z\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

GHSA-4X3X-869W-XX3M

Vulnerability from github – Published: 2026-06-04 19:32 – Updated: 2026-06-04 19:32

Summary

Shopware SSO referer trust leading to an arbitrary redirect target

Details

Description

This report describes an open redirect in Shopware's public SSO entry point at GET /api/oauth/sso/auth. When the endpoint is reached without the expected SSO session state, the application falls back to the request's Referer header and uses that value as the redirect destination. In the validated behavior, the server does not restrict that fallback target to same-origin URLs, does not require a relative path, and does not reject dangerous schemes such as javascript:. As a result, an unauthenticated request can turn this endpoint into a reusable redirect primitive whose destination is fully controlled by attacker-supplied request metadata.

The security problem is not limited to a harmless navigation mismatch. The endpoint sits under /api/oauth/, which gives the redirect a trustworthy application-controlled origin and makes it suitable for phishing chains, branded redirect abuse, and cases where client software automatically follows redirects issued by a trusted host. The attached evidence also shows that the response is not only an HTTP 302 with a user-controlled Location header. The HTML body contains a matching meta refresh tag and redirect link built from the same attacker-controlled value. In the validated proof, the endpoint redirects to https://attacker.example/poc when that URL is supplied through Referer, and it also reflects javascript:alert(1) into Location and the HTML redirect body without any scheme filtering. This report therefore stays conservative and claims an open redirect with arbitrary redirect targets, while noting that the lack of scheme restrictions makes the behavior materially worse than a same-scheme external redirect.

Steps To Reproduce

Start a local Shopware instance that exposes the vulnerable endpoint at http://127.0.0.1:8000/api/oauth/sso/auth. No login is required for the proof. The attached Python PoC already targets that base URL and is configured to send direct requests without following redirects automatically.
Run the attached PoC with python3 poc_sso_referer_open_redirect.py. The script sends three requests to GET /api/oauth/sso/auth and records the raw responses as evidence files. The first request omits the Referer header entirely. The second request supplies Referer: https://attacker.example/poc. The third request supplies Referer: javascript:alert(1).
Inspect the first recorded response in evidence/sso_redirect_no_referer.raw.txt. In the validated run, the endpoint returns 401 with the message Referrer not found. Cannot redirect. This shows that the code path being exercised is the unauthenticated fallback behavior that depends on Referer when the expected SSO state is missing.
Inspect evidence/sso_redirect_https_redirect.raw.txt. In the validated run, the endpoint returns 302 and sets Location: https://attacker.example/poc. The HTML body also contains a meta refresh tag and redirect link pointing to the same external URL. This demonstrates that the server accepts an attacker-controlled external target and emits it as a redirect destination.
Inspect evidence/sso_redirect_javascript_redirect.raw.txt. In the validated run, the endpoint again returns 302, but this time the response sets Location: javascript:alert(1). The HTML body mirrors the same javascript: target in both the meta refresh tag and the anchor. This demonstrates that the fallback redirect does not even enforce an http or https scheme restriction before constructing the response.
Compare the PoC summary in evidence/poc_sso_referer_open_redirect.output.txt with the raw responses. The validated run shows 401 when no Referer is present, 302 to https://attacker.example/poc when an external HTTPS URL is supplied, and 302 to javascript:alert(1) when a dangerous scheme is supplied. That behavior confirms the endpoint can be used as an open redirect with an arbitrary redirect target controlled through Referer.

Recommendations

The endpoint should stop using Referer as a fallback redirect target when the expected SSO state is missing. If the application cannot complete the SSO flow because the required session state does not exist, it should return a fixed error response or redirect only to a fixed internal page that is not influenced by request headers. Referer is not a trustworthy source of navigation intent and should not be treated as an authorization or routing signal for security-sensitive redirect logic.

If the product needs to preserve a return destination, that destination should be derived from a server-generated state value or validated against a strict allowlist. At minimum, the code should reject non-HTTP schemes, reject scheme-relative targets such as //host, and reject absolute URLs that are not same-origin with the current Shopware instance. A regression test should cover the exact cases proven here: no Referer, an external HTTPS Referer, and a javascript: Referer, with assertions that none of the attacker-controlled values can be emitted into Location or the HTML redirect body.

Impact

The demonstrated impact is that an unauthenticated attacker can cause a trusted Shopware endpoint to emit arbitrary redirect targets chosen through the request's Referer header. In the minimum case, that enables standard open redirect abuse for phishing, brand impersonation, and redirect chaining through a legitimate application origin. Because the redirect is served from /api/oauth/sso/auth, the resulting URL can look more trustworthy than a generic off-site redirect and may be more likely to be followed by users or client software that expects the endpoint to participate in an authentication flow.

The validated evidence also shows that the endpoint does not restrict the redirect target to ordinary web URLs. It reflects javascript:alert(1) directly into Location and into the HTML redirect page. This report keeps the claim conservative and classifies the issue as an open redirect with arbitrary redirect targets, but the acceptance of dangerous schemes makes the behavior more severe than a simple same-browser redirect to another HTTPS site and increases the risk of downstream abuse depending on client behavior.

Note on submission channel:

I initially attempted to submit this issue through Shopware’s official security reporting form. The form backend returned HTTP 400 for normal submissions, and when an attachment was included it explicitly rejected .md, .py, .zip files with the message File type not allowed. Because the official form was not functioning correctly for me, I am submitting this report privately through GitHub’s vulnerability reporting flow.

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.7.3.0"
            },
            {
              "fixed": "6.7.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.7.3.0"
            },
            {
              "fixed": "6.7.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48012"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-04T19:32:35Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Description\n\nThis report describes an open redirect in Shopware\u0027s public SSO entry point at `GET /api/oauth/sso/auth`. When the endpoint is reached without the expected SSO session state, the application falls back to the request\u0027s `Referer` header and uses that value as the redirect destination. In the validated behavior, the server does not restrict that fallback target to same-origin URLs, does not require a relative path, and does not reject dangerous schemes such as `javascript:`. As a result, an unauthenticated request can turn this endpoint into a reusable redirect primitive whose destination is fully controlled by attacker-supplied request metadata.\n\nThe security problem is not limited to a harmless navigation mismatch. The endpoint sits under `/api/oauth/`, which gives the redirect a trustworthy application-controlled origin and makes it suitable for phishing chains, branded redirect abuse, and cases where client software automatically follows redirects issued by a trusted host. The attached evidence also shows that the response is not only an HTTP `302` with a user-controlled `Location` header. The HTML body contains a matching meta refresh tag and redirect link built from the same attacker-controlled value. In the validated proof, the endpoint redirects to `https://attacker.example/poc` when that URL is supplied through `Referer`, and it also reflects `javascript:alert(1)` into `Location` and the HTML redirect body without any scheme filtering. This report therefore stays conservative and claims an open redirect with arbitrary redirect targets, while noting that the lack of scheme restrictions makes the behavior materially worse than a same-scheme external redirect.\n\n## Steps To Reproduce\n\n1. Start a local Shopware instance that exposes the vulnerable endpoint at `http://127.0.0.1:8000/api/oauth/sso/auth`. No login is required for the proof. The attached Python PoC already targets that base URL and is configured to send direct requests without following redirects automatically.\n2. Run the attached PoC with `python3 poc_sso_referer_open_redirect.py`. The script sends three requests to `GET /api/oauth/sso/auth` and records the raw responses as evidence files. The first request omits the `Referer` header entirely. The second request supplies `Referer: https://attacker.example/poc`. The third request supplies `Referer: javascript:alert(1)`.\n3. Inspect the first recorded response in `evidence/sso_redirect_no_referer.raw.txt`. In the validated run, the endpoint returns `401` with the message `Referrer not found. Cannot redirect.` This shows that the code path being exercised is the unauthenticated fallback behavior that depends on `Referer` when the expected SSO state is missing.\n4. Inspect `evidence/sso_redirect_https_redirect.raw.txt`. In the validated run, the endpoint returns `302` and sets `Location: https://attacker.example/poc`. The HTML body also contains a meta refresh tag and redirect link pointing to the same external URL. This demonstrates that the server accepts an attacker-controlled external target and emits it as a redirect destination.\n5. Inspect `evidence/sso_redirect_javascript_redirect.raw.txt`. In the validated run, the endpoint again returns `302`, but this time the response sets `Location: javascript:alert(1)`. The HTML body mirrors the same `javascript:` target in both the meta refresh tag and the anchor. This demonstrates that the fallback redirect does not even enforce an `http` or `https` scheme restriction before constructing the response.\n6. Compare the PoC summary in `evidence/poc_sso_referer_open_redirect.output.txt` with the raw responses. The validated run shows `401` when no `Referer` is present, `302` to `https://attacker.example/poc` when an external HTTPS URL is supplied, and `302` to `javascript:alert(1)` when a dangerous scheme is supplied. That behavior confirms the endpoint can be used as an open redirect with an arbitrary redirect target controlled through `Referer`.\n\n## Recommendations\n\nThe endpoint should stop using `Referer` as a fallback redirect target when the expected SSO state is missing. If the application cannot complete the SSO flow because the required session state does not exist, it should return a fixed error response or redirect only to a fixed internal page that is not influenced by request headers. `Referer` is not a trustworthy source of navigation intent and should not be treated as an authorization or routing signal for security-sensitive redirect logic.\n\nIf the product needs to preserve a return destination, that destination should be derived from a server-generated state value or validated against a strict allowlist. At minimum, the code should reject non-HTTP schemes, reject scheme-relative targets such as `//host`, and reject absolute URLs that are not same-origin with the current Shopware instance. A regression test should cover the exact cases proven here: no `Referer`, an external HTTPS `Referer`, and a `javascript:` `Referer`, with assertions that none of the attacker-controlled values can be emitted into `Location` or the HTML redirect body.\n\n## Impact\n\nThe demonstrated impact is that an unauthenticated attacker can cause a trusted Shopware endpoint to emit arbitrary redirect targets chosen through the request\u0027s `Referer` header. In the minimum case, that enables standard open redirect abuse for phishing, brand impersonation, and redirect chaining through a legitimate application origin. Because the redirect is served from `/api/oauth/sso/auth`, the resulting URL can look more trustworthy than a generic off-site redirect and may be more likely to be followed by users or client software that expects the endpoint to participate in an authentication flow.\n\nThe validated evidence also shows that the endpoint does not restrict the redirect target to ordinary web URLs. It reflects `javascript:alert(1)` directly into `Location` and into the HTML redirect page. This report keeps the claim conservative and classifies the issue as an open redirect with arbitrary redirect targets, but the acceptance of dangerous schemes makes the behavior more severe than a simple same-browser redirect to another HTTPS site and increases the risk of downstream abuse depending on client behavior.\n\n## Note on submission channel:\n\nI initially attempted to submit this issue through Shopware\u2019s official security reporting form. The form backend returned HTTP 400 for normal submissions, and when an attachment was included it explicitly rejected `.md`, `.py`, `.zip` files with the message `File type not allowed`. Because the official form was not functioning correctly for me, I am submitting this report privately through GitHub\u2019s vulnerability reporting flow.",
  "id": "GHSA-4x3x-869w-xx3m",
  "modified": "2026-06-04T19:32:36Z",
  "published": "2026-06-04T19:32:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/security/advisories/GHSA-4x3x-869w-xx3m"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/shopware/shopware"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/releases/tag/v6.7.10.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Shopware SSO referer trust leading to an arbitrary redirect target"
}

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.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.

Action not permitted