breaks out and runs attacker JavaScript in the proxy's origin. The route needs no authentication, so an attacker with an account on the configured IdP (for example one that lets users edit a display name) can complete the SSO flow and send the resulting callback URL to a logged-in proxy admin. The script can then read the dashboard session cookie and act with the admin's privileges, up to full account takeover of the gateway that holds your LLM provider keys. Risk is moderate: CVSS is 6.8, the attack needs high complexity and user interaction, and there is no public exploit, no Nuclei template and no KEV listing (EPSS is not yet available). The package is still a high-value target, with 50 other CVEs and a package risk score of 79/100. Upgrade litellm to 1.85.0 or later, and until then disable or block /sso/debug/callback at the reverse proxy."}},{"@type":"Question","name":"Is GHSA-hhww-mrg2-969h actively exploited?","acceptedAnswer":{"@type":"Answer","text":"No confirmed active exploitation of GHSA-hhww-mrg2-969h has been reported, but organizations should still patch proactively."}},{"@type":"Question","name":"How to fix GHSA-hhww-mrg2-969h?","acceptedAnswer":{"@type":"Answer","text":"1) Upgrade litellm to 1.85.0 or later (fix in PR 27498, commit 13a1933). 2) Until patched, block or restrict /sso/debug/callback at the reverse proxy or WAF. 3) Treat SSO user profile fields (display names) as untrusted and restrict self-service editing at the IdP where possible. 4) Have admins avoid clicking SSO callback links from unsolicited sources and use separate browser profiles for admin sessions. 5) Enforce a strict Content-Security-Policy that blocks inline scripts on the proxy origin. 6) Detection: review access logs for requests to /sso/debug/callback containing encoded '' or '%3C/script%3E' in parameters, and rotate admin sessions and provider keys if exploitation is suspected."}},{"@type":"Question","name":"What systems are affected by GHSA-hhww-mrg2-969h?","acceptedAnswer":{"@type":"Answer","text":"This vulnerability affects the following AI/ML architecture patterns: LLM gateways/proxies, model serving, multi-provider routing, admin dashboards."}},{"@type":"Question","name":"What is the CVSS score for GHSA-hhww-mrg2-969h?","acceptedAnswer":{"@type":"Answer","text":"GHSA-hhww-mrg2-969h has a CVSS v3.1 base score of 6.8 (MEDIUM)."}}]}]}

GHSA-hhww-mrg2-969h: LiteLLM: reflected XSS in SSO debug callback

GHSA-hhww-mrg2-969hMEDIUM

Published October 27, 2026

CISO Take

LiteLLM's /sso/debug/callback endpoint embeds identity-provider-supplied fields in an inline script block without neutralizing HTML characters, so a value containing </script> breaks out and runs attacker JavaScript in the proxy's origin. The route needs no authentication, so an attacker with an account on the configured IdP (for example one that lets users edit a display name) can complete the SSO flow and send the resulting callback URL to a logged-in proxy admin. The script can then read the dashboard session cookie and act with the admin's privileges, up to full account takeover of the gateway that holds your LLM provider keys. Risk is moderate: CVSS is 6.8, the attack needs high complexity and user interaction, and there is no public exploit, no Nuclei template and no KEV listing (EPSS is not yet available). The package is still a high-value target, with 50 other CVEs and a package risk score of 79/100. Upgrade litellm to 1.85.0 or later, and until then disable or block /sso/debug/callback at the reverse proxy.

Sources:GitHub AdvisoryNVDOpenSSFATLASgithub.com/BerriAI/litellm

What is the risk?

Medium overall (CVSS 6.8). Exploitation is network-based with no privileges required on the proxy, but it needs a valid account at the configured IdP whose claims are passed through verbatim, plus a logged-in admin who opens a crafted link. No public exploit, scanner template or KEV listing exists. Impact on confidentiality and integrity is high because a stolen admin session gives control of the LLM gateway, including virtual keys, provider credentials, routing and spend settings. Exposure is highest for internet-reachable proxies using SSO with IdPs that let users set free-text profile fields.

How does the attack unfold?

Initial Access

Attacker sets a malicious display name containing </script> at the IdP and completes the SSO flow to obtain a callback URL.

AML.T0049

User Execution

A logged-in proxy admin is lured into opening the crafted callback URL.

AML.T0011.003

Exploitation

The injected script breaks out of the inline script block and runs in the proxy origin, stealing the session cookie.

Impact

Attacker takes over the admin account and gains control of LiteLLM keys, routing and provider credentials.

AML.T0012

Initial Access

Attacker sets a malicious display name containing </script> at the IdP and completes the SSO flow to obtain a callback URL.

AML.T0049

User Execution

A logged-in proxy admin is lured into opening the crafted callback URL.

AML.T0011.003

Exploitation

The injected script breaks out of the inline script block and runs in the proxy origin, stealing the session cookie.

Impact

Attacker takes over the admin account and gains control of LiteLLM keys, routing and provider credentials.

AML.T0012

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LiteLLM	pip	>= 1.65.5, < 1.85.0	`1.85.0`
62.0KOpenSSF 6.0Pushed 6d ago51% patched~47d to patchFull package profile →

Do you use LiteLLM? You're affected.

How severe is it?

CVSS 3.1

6.8 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AVNetwork

ACHigh

PRNone

UIRequired

SUnchanged

CHigh

IHigh

ANone

What should I do?

1 step

1) Upgrade litellm to 1.85.0 or later (fix in PR 27498, commit 13a1933). 2) Until patched, block or restrict /sso/debug/callback at the reverse proxy or WAF. 3) Treat SSO user profile fields (display names) as untrusted and restrict self-service editing at the IdP where possible. 4) Have admins avoid clicking SSO callback links from unsolicited sources and use separate browser profiles for admin sessions. 5) Enforce a strict Content-Security-Policy that blocks inline scripts on the proxy origin. 6) Detection: review access logs for requests to /sso/debug/callback containing encoded '</script>' or '%3C/script%3E' in parameters, and rotate admin sessions and provider keys if exploitation is suspected.

How is it classified?

Auth BypassData LeakageAPIFrameworkAML.T0011.003- Malicious Link AML.T0012- Valid Accounts AML.T0049- Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.10.3-Suppliers

NIST AI RMF

MANAGE 2.3-Response to previously unknown risks and vendor vulnerabilities

OWASP LLM Top 10

LLM03-Supply Chain

Frequently Asked Questions

What is GHSA-hhww-mrg2-969h?

Is GHSA-hhww-mrg2-969h actively exploited?

No confirmed active exploitation of GHSA-hhww-mrg2-969h has been reported, but organizations should still patch proactively.

How to fix GHSA-hhww-mrg2-969h?

1) Upgrade litellm to 1.85.0 or later (fix in PR 27498, commit 13a1933). 2) Until patched, block or restrict /sso/debug/callback at the reverse proxy or WAF. 3) Treat SSO user profile fields (display names) as untrusted and restrict self-service editing at the IdP where possible. 4) Have admins avoid clicking SSO callback links from unsolicited sources and use separate browser profiles for admin sessions. 5) Enforce a strict Content-Security-Policy that blocks inline scripts on the proxy origin. 6) Detection: review access logs for requests to /sso/debug/callback containing encoded '</script>' or '%3C/script%3E' in parameters, and rotate admin sessions and provider keys if exploitation is suspected.

What systems are affected by GHSA-hhww-mrg2-969h?

This vulnerability affects the following AI/ML architecture patterns: LLM gateways/proxies, model serving, multi-provider routing, admin dashboards.

What is the CVSS score for GHSA-hhww-mrg2-969h?

GHSA-hhww-mrg2-969h has a CVSS v3.1 base score of 6.8 (MEDIUM).

What is the AI security impact?

Affected AI Architectures

LLM gateways/proxiesmodel servingmulti-provider routingadmin dashboards

MITRE ATLAS Techniques

AML.T0011.003Malicious Link

AML.T0012Valid Accounts

AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.10.3

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

### Summary The `/sso/debug/callback` endpoint reflected identity-provider-controlled fields into an inline `<script>` block via `json.dumps`, which escapes JSON string syntax but not HTML context characters such as `</script>`. An IdP-returned string field containing `</script>` (for example a user-editable display name) closed the script block and executed attacker JavaScript in the proxy's origin. ### Impact Reflected XSS on the LiteLLM proxy origin. The route required no authentication, so an attacker with an account on the configured IdP whose claims pass such strings through verbatim could complete the SSO flow themselves and deliver the resulting callback URL to a logged-in proxy admin. Scripts executing in the proxy origin can read the dashboard session cookie and act with the victim's privileges, up to full admin account takeover.

Exploitation Scenario

An attacker who holds an account at the organization's IdP sets their display name to a string containing </script> followed by JavaScript. They sign in through the LiteLLM SSO flow themselves, capturing the resulting /sso/debug/callback URL. They send that link to a proxy administrator, for example via chat or email. When the admin opens it while logged in, the script runs in the proxy origin, steals the dashboard session cookie and calls admin APIs to create a persistent API key and read configured provider credentials, giving the attacker control of the organization's LLM gateway.

Weaknesses (CWE)

CWE-79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')Primary

CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'): The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
[Implementation, Architecture and Design] Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed. HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Casca

Source: MITRE CWE corpus.