Description

Warpgate is an open source SSH, HTTPS and MySQL bastion host for Linux. Prior to 0.25.5, the /@warpgate/api/sso/providers/:name/start endpoint stores an attacker-controlled next parameter that the POST /@warpgate/api/sso/return handler inserts without HTML escaping into the response generated by warpgate-protocol-http/src/api/sso_provider_list.rs. A victim who follows a crafted link and completes SSO can cause markup and JavaScript to execute in the authenticated Warpgate origin, allowing access to session data and actions through user APIs, and through administrator APIs only when the victim is an administrator. The GET /@warpgate/api/sso/return path also uses the same unvalidated value as a redirect destination, enabling an open redirect. This issue is fixed in version 0.25.5.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.3",
  "pubDate": "2026-09-21T19:17:06.910Z",
  "pubdate": "2026-09-21T19:17:06.910Z",
  "executiveSummary": "Warpgate versions prior to 0.25.5 contain a critical vulnerability involving improper neutralization of input during web page generation (Cross-Site Scripting) and improper limitation of a pathname to a restricted directory (Open Redirect).\nThe vulnerability originates in the SSO authentication flow, specifically where attacker-controlled parameters are processed and reflected in server responses without sanitization.\nBy crafting a malicious link, an attacker can execute arbitrary JavaScript within the context of the Warpgate web origin upon successful SSO completion by a victim.\nSuccessful exploitation allows for session hijacking, unauthorized API interaction, and privilege escalation if the victim holds administrative status.\nThe open redirect capability further facilitates phishing campaigns by leveraging the trusted Warpgate domain to redirect users to malicious third-party sites.\nThe flaw affects the /@warpgate/api/sso/providers/:name/start and GET /@warpgate/api/sso/return endpoints, necessitating an immediate upgrade to version 0.25.5 to mitigate risk.",
  "technicalDetails": "The vulnerability is rooted in an injection flaw located within the SSO provider handling logic, specifically in warpgate-protocol-http/src/api/sso_provider_list.rs. The system fails to perform output encoding or HTML sanitization on the 'next' parameter when constructing responses.\nDuring the initiation phase of the SSO process, the endpoint /@warpgate/api/sso/providers/:name/start accepts a 'next' parameter provided by the user. Warpgate stores this value and subsequently retrieves it during the /@warpgate/api/sso/return callback sequence. The application inserts this raw, attacker-controlled value directly into the HTTP response body intended for the user's browser.\nWhen a victim interacts with a specially crafted URL containing a payload within the 'next' parameter, the malicious script is rendered in the victim's browser session. Because this occurs within the authenticated Warpgate origin, the injected JavaScript operates with the victim's session cookies and authorization tokens. This grants the attacker the ability to perform unauthorized requests to the Warpgate user APIs on behalf of the victim.\nIn scenarios where the victim possesses administrative privileges, the attacker gains the ability to execute administrative API functions. This could lead to a full compromise of the bastion host, including the manipulation of access controls, keys, or audit configurations.\nFurthermore, the GET /@warpgate/api/sso/return path utilizes the same unsanitized 'next' parameter as a destination for HTTP redirects. An attacker can supply a malicious URL to the 'next' parameter, resulting in an open redirect vulnerability. This allows for the redirection of legitimate users to arbitrary, potentially malicious external websites under the guise of the Warpgate domain, which is a common vector for credential harvesting and social engineering.\nThe attack flow follows a predictable pattern: 1) The attacker generates a malicious link containing an XSS or redirect payload in the 'next' parameter. 2) The attacker social-engineers a victim into clicking the link. 3) The victim completes the SSO authentication process. 4) The server processes the 'return' request and reflects the unsanitized 'next' payload in the response. 5) The browser executes the malicious script or follows the redirect, completing the compromise of the user's context."
}