Description

Snipe-IT 8.5.0 through 8.6.3 contains an open redirect vulnerability in its SAML assertion-consumer endpoint (SamlController::acs, POST /saml/acs). The endpoint wrote the RelayState POST parameter directly into Laravel's url.intended session key with only CR/LF characters stripped, and LoginController later issued redirect()->intended(), which passes an absolute URL through to the Location header unchanged. An unauthenticated attacker who induces a user of a SAML-SSO-enabled instance to visit a crafted IdP-initiated SSO link can therefore cause the victim's browser to be redirected to an arbitrary absolute external URL immediately after a successful authentication, which the advisory notes facilitates credential-harvesting phishing. No account on the target instance and no compromise of the identity provider are required. Only deployments with SAML SSO enabled are affected. Fixed in 8.7.0 (commit d30b73d, PR #19386), which validates RelayState via a new Helper::sameOriginUrl check before storing it.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.1",
  "pubDate": "2026-09-09T14:17:24.883Z",
  "pubdate": "2026-09-09T14:17:24.883Z",
  "executiveSummary": "Snipe-IT versions 8.5.0 through 8.6.3 are susceptible to an open redirect vulnerability located within the SAML assertion-consumer endpoint (SamlController::acs).\nThe vulnerability arises from improper validation of the RelayState parameter, which is processed by the application to facilitate post-authentication redirects.\nBy manipulating the RelayState parameter, an unauthenticated attacker can force a victim's browser to navigate to an arbitrary external URL following successful SAML authentication.\nThis vulnerability is particularly dangerous for deployments with SAML SSO enabled, as it can be leveraged for sophisticated phishing and credential-harvesting campaigns.\nExploitation does not require prior authentication or compromise of the identity provider, as the malicious redirection is triggered immediately after the victim completes the legitimate SSO process.\nThe risk is significant due to the trust users place in the target application's authentication flow, making them more likely to interact with the attacker-controlled destination.\nOrganizations using impacted versions of Snipe-IT are advised to upgrade to version 8.7.0 immediately to implement the required security validations.",
  "technicalDetails": "The root cause of this vulnerability is located in the SamlController::acs method, which handles the POST /saml/acs endpoint. When processing a SAML assertion, the application reads the RelayState POST parameter from the SAML response.\nPrior to the fix, the application performed insufficient sanitization, stripping only CR/LF characters before storing the value directly into Laravel's 'url.intended' session key. Because Laravel's redirect()->intended() function does not perform origin validation, it accepts absolute URLs and passes them directly to the HTTP Location header.\nThe attack flow begins with an unauthenticated attacker crafting a malicious IdP-initiated SSO link containing a crafted RelayState parameter pointing to a domain under the attacker's control.\nWhen a legitimate user of a SAML-SSO-enabled Snipe-IT instance clicks this link, the user is redirected to the identity provider to authenticate. Upon successful authentication, the identity provider sends the SAML assertion along with the attacker's manipulated RelayState to the target Snipe-IT instance's acs endpoint.\nThe vulnerable code stores this malicious redirect URL into the session. Once the authentication process completes, the LoginController logic calls the redirect()->intended() method, retrieving the attacker-supplied URL from the session.\nBecause the application treats this as a trusted destination for user return-flow, the user's browser is issued a 302 redirect to the external site. This allows the attacker to redirect users to a look-alike login page or malicious payload, facilitating credential harvesting by exploiting the user's implicit trust in the authentication process.\nThis vulnerability is restricted to environments where SAML SSO is actively configured and enabled. The patch introduced in version 8.7.0 (commit d30b73d, PR #19386) remediates this issue by implementing a strict Helper::sameOriginUrl check on the RelayState before it is committed to the session storage. This ensures that only local, relative paths or URLs belonging to the same host can be processed by the redirect logic, effectively neutralizing the open redirect vector."
}