GHSA-5rr4-8452-hf4v is a critical-severity (CVSS 9.6) Improper Input Validation vulnerability in @better-auth/sso. O3 Security confirms whether GHSA-5rr4-8452-hf4v is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
@better-auth/sso provider registration has server-side request forgery via unvalidated OIDC endpoints
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-5rr4-8452-hf4v.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-5rr4-8452-hf4v plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 366,526 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@better-auth/ssonpmDescription
Am I affected?
Users are affected if all of the following are true:
- Their application uses
@better-auth/ssoat a version>= 0.1.0, < 1.6.11on the stable line, or any1.7.0-beta.xon the pre-release line. - The
sso()plugin is added to their application'sbetterAuth({ plugins: [...] })array. - Any user with a valid Better Auth session can reach
POST /sso/register(the plugin's default gate accepts any session).
For the non-blind SSRF impact (full IAM credential or internal HTTP body exfiltration), no further configuration is required.
For the account takeover escalation, additionally:
- Developers set
sso({ trustEmailVerified: true, ... }). - The developer's application deployment has accounts whose
emailoverlaps with attacker-chosen domains.
If developers do not enable the SSO plugin, their application is not affected.
Fix:
- Upgrade to
@better-auth/[email protected]or later. - If developers cannot upgrade, see workarounds below.
Summary
The @better-auth/sso plugin's POST /sso/register endpoint accepts attacker-controlled oidcConfig.userInfoEndpoint, tokenEndpoint, and jwksEndpoint URLs when skipDiscovery: true is set, persists them on the ssoProvider row without origin validation, then issues server-side fetches to those URLs during the OIDC callback. The fetched response body is reflected through the user profile, producing a non-blind SSRF reachable by any authenticated session. The same primitive exists on POST /sso/update-provider.
Details
The schema field types accept bare strings: no .url() validator, no origin gate. The discovery branch (skipDiscovery: false) routes URLs through validateDiscoveryUrl; the skip-discovery branch persists them as-is. At callback time three fetch sites read the stored URLs: validateAuthorizationCode for the token endpoint, betterFetch for the userInfo endpoint, and validateToken for the JWKS endpoint.
When trustEmailVerified: true is configured, the attacker can escalate to account linking. A malicious userInfo response with emailVerified: true and a chosen email triggers OAuth auto-link against any pre-existing user row with that email, compounding the SSRF into account takeover.
Patches
Fixed in @better-auth/[email protected]. Provider registration (POST /sso/register with skipDiscovery: true) and every POST /sso/update-provider request now validate each supplied OIDC endpoint URL (authorizationEndpoint, tokenEndpoint, userInfoEndpoint, jwksEndpoint, discoveryEndpoint) at registration time. A URL is rejected unless it satisfies one of two conditions:
- Its host is publicly routable on the internet, evaluated through the
@better-auth/core/utils/host.isPublicRoutableHostgate. RFC 1918 private ranges, RFC 4193 unique-local addresses, link-local addresses (including the cloud-metadata IP169.254.169.254), loopback, multicast, broadcast, and reserved ranges are rejected, along with cloud-metadata FQDNs. - Its origin is already listed in the application's
trustedOriginsconfiguration. This preserves the documented escape hatch for customers running internal IdPs intentionally on private networks.
The schema also tightens from z.string() to z.url() on those fields, so malformed URLs fail at parse time rather than at fetch time. Deployments running internal IdPs that previously worked must add the IdP's origin to trustedOrigins to keep working after upgrade.
Workarounds
If developers cannot upgrade immediately:
- Disable provider self-registration: set
sso({ providersLimit: 0 }). The limit is enforced before the schema branch, blocking every/sso/registerregardless ofskipDiscovery. - Reverse-proxy gate: block
POST /sso/registerandPOST /sso/update-providerat the edge, or restrict to a denylist of source IPs and a small admin user list. - Network-level egress controls: block egress from the auth server to RFC 1918, RFC 4193, link-local ranges (
169.254.0.0/16,fe80::/10), and the cloud-metadata FQDN list at the firewall or VPC level. AWS users should additionally enforce IMDSv2 (HttpTokens: required). - Set
trustEmailVerified: falseuntil upgrade. This caps the impact at non-blind SSRF and removes the account-takeover escalation, but does not stop the SSRF.
Impact
- Server-Side Request Forgery (non-blind): the attacker reads response bodies from any HTTP endpoint reachable from the auth server, including cloud metadata services (AWS IMDS, GCP metadata FQDN), internal-only APIs, and infrastructure services such as Redis or admin panels bound to localhost.
- Account takeover (when
trustEmailVerified: true): the attacker mints a malicious userInfo response assertingemailVerified: truefor an arbitrary email, triggering OAuth auto-link against pre-existing user rows.
Credit
Reported by Vaadata.
Resources
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @better-auth/sso | ≥ 0.1.0&&< 1.6.11 | 1.6.11 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @better-auth/sso. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @better-auth/sso to 1.6.11 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-5rr4-8452-hf4v is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-5rr4-8452-hf4v is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-5rr4-8452-hf4v. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-5rr4-8452-hf4v in your dependencies?
O3 detects GHSA-5rr4-8452-hf4v across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.