CVE-2026-48012

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.

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.

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

1. 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.
2. 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).
3. 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.
4. 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.
5. 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.
6. 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.

##…

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.

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.

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

1. 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.
2. 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).
3. 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.
4. 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.
5. 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.
6. 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.

##…