Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
An unauthenticated attacker can send a crafted GET request directly to /oauth/:provider/callback with a forged profile in the query string. The OAuth service's authentication payload has a fallback chain that reaches params.query (the raw request query) when Grant's session/state responses are empty. Since the attacker never initiated an OAuth authorize flow, Grant has no session to work with and produces no response, so the fallback fires. The forged profile then drives entity lookup and JWT minting. The attacker gets a valid access token for an existing user without ever contacting the OAuth provider. Critical (CVSS 9.8)
Recommended action: Upgrade to 5.0.42 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
All HTTP request headers are stored in the session cookie, which is signed but not encrypted, exposing internal proxy/gateway headers to clients. The OAuth service stores the complete headers object in the session: The session is persisted using cookie-session, which base64-encodes the data. While the cookie is signed to prevent tampering, the contents are readable by anyone by simply decoding the base64 value. Under specific deployment configurations (e.g., behind reverse proxies or API gateways), this can lead to exposure of sensitive internal infrastructure details such as API keys, service tokens, and internal IP addresses. Credits: Abdelwahed Madani Yousfi (@vvxhid) / Edoardo Geraci (@b0-n0-b0) / Thomas Rinsma (@ThomasRinsma) From Codean Labs.
Recommended action: Upgrade to 5.0.40 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The origin validation uses startsWith() for comparison, allowing attackers to bypass the check by registering a domain that shares a common prefix with an allowed origin. The getAllowedOrigin() function checks if the Referer header starts with any allowed origin: This comparison is insufficient as it only validates the prefix. This is exploitable when the origins array is configured and an attacker registers a domain starting with an allowed origin string (e.g., https://target.com.attacker.com bypasses https://target.com). On its own, tokens are still redirected to a configured origin. However, in specific scenarios an attacker can initiate the OAuth flow from an unauthorized origin and exfiltrate tokens, achieving full account takeover. Credits: Abdelwahed Madani Yousfi (@vvxhid) / Edoardo Geraci (@b0-n0-b0) / Thomas Rinsma (@ThomasRinsma) From Codean Labs.
Recommended action: Upgrade to 5.0.40 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The redirect query parameter is appended to the base origin without validation, allowing attackers to steal access tokens via URL authority injection. This leads to full account takeover, as the attacker obtains the victim's access token and can impersonate them. The application constructs the final redirect URL by concatenating the base origin with the user-supplied redirect parameter: Where: - redirect = base origin from config (e.g., https://target.com) - queryRedirect = user input from ?redirect= parameter This is exploitable when the origins array is configured and origin values do not end with /. An attacker can supply @attacker.com as the redirect value results in https://target.com@attacker.com#accesstoken=..., where the browser interprets attacker.com as the host, leading to full account takeover. Credits: Abdelwahed Madani Yousfi (@vvxhid) / Edoardo Geraci (@b0-n0-b0) / Thomas Rinsma (@ThomasRinsma) From Codean Labs.
Recommended action: Upgrade to 5.0.40 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.