Vulnerability-Lookup

GHSA-5RR4-8452-HF4V

Vulnerability from github – Published: 2026-07-07 20:56 – Updated: 2026-07-07 20:56

Summary

@better-auth/sso provider registration has server-side request forgery via unvalidated OIDC endpoints

Details

Am I affected?

Users are affected if all of the following are true:

Their application uses @better-auth/sso at a version >= 0.1.0, < 1.6.11 on the stable line, or any 1.7.0-beta.x on the pre-release line.
The sso() plugin is added to their application's betterAuth({ 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 email overlaps with attacker-chosen domains.

If developers do not enable the SSO plugin, their application is not affected.

Fix:

Upgrade to @better-auth/sso@1.6.11 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/sso@1.6.11. 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.isPublicRoutableHost gate. RFC 1918 private ranges, RFC 4193 unique-local addresses, link-local addresses (including the cloud-metadata IP 169.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 trustedOrigins configuration. 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/register regardless of skipDiscovery.
Reverse-proxy gate: block POST /sso/register and POST /sso/update-provider at 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: false until 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 asserting emailVerified: true for an arbitrary email, triggering OAuth auto-link against pre-existing user rows.

Credit

Reported by Vaadata.

Resources

Severity

9.6 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@better-auth/sso"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.1.0"
            },
            {
              "fixed": "1.6.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53513"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-345",
      "CWE-441",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-07T20:56:19Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Am I affected?\n\nUsers are affected if all of the following are true:\n\n- Their application uses `@better-auth/sso` at a version `\u003e= 0.1.0, \u003c 1.6.11` on the stable line, or any `1.7.0-beta.x` on the pre-release line.\n- The `sso()` plugin is added to their application\u0027s `betterAuth({ plugins: [...] })` array.\n- Any user with a valid Better Auth session can reach `POST /sso/register` (the plugin\u0027s default gate accepts any session).\n\nFor the non-blind SSRF impact (full IAM credential or internal HTTP body exfiltration), no further configuration is required.\n\nFor the account takeover escalation, additionally:\n\n- Developers set `sso({ trustEmailVerified: true, ... })`.\n- The developer\u0027s application deployment has accounts whose `email` overlaps with attacker-chosen domains.\n\nIf developers do not enable the SSO plugin, their application is not affected.\n\nFix:\n\n1. Upgrade to `@better-auth/sso@1.6.11` or later.\n2. If developers cannot upgrade, see workarounds below.\n\n### Summary\n\nThe `@better-auth/sso` plugin\u0027s `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`.\n\n### Details\n\nThe 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.\n\nWhen `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.\n\n### Patches\n\nFixed in `@better-auth/sso@1.6.11`. 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:\n\n1. Its host is publicly routable on the internet, evaluated through the `@better-auth/core/utils/host.isPublicRoutableHost` gate. RFC 1918 private ranges, RFC 4193 unique-local addresses, link-local addresses (including the cloud-metadata IP `169.254.169.254`), loopback, multicast, broadcast, and reserved ranges are rejected, along with cloud-metadata FQDNs.\n2. Its origin is already listed in the application\u0027s `trustedOrigins` configuration. This preserves the documented escape hatch for customers running internal IdPs intentionally on private networks.\n\nThe 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\u0027s origin to `trustedOrigins` to keep working after upgrade.\n\n### Workarounds\n\nIf developers cannot upgrade immediately:\n\n- **Disable provider self-registration**: set `sso({ providersLimit: 0 })`. The limit is enforced before the schema branch, blocking every `/sso/register` regardless of `skipDiscovery`.\n- **Reverse-proxy gate**: block `POST /sso/register` and `POST /sso/update-provider` at the edge, or restrict to a denylist of source IPs and a small admin user list.\n- **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`).\n- **Set `trustEmailVerified: false`** until upgrade. This caps the impact at non-blind SSRF and removes the account-takeover escalation, but does not stop the SSRF.\n\n### Impact\n\n- **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.\n- **Account takeover** (when `trustEmailVerified: true`): the attacker mints a malicious userInfo response asserting `emailVerified: true` for an arbitrary email, triggering OAuth auto-link against pre-existing user rows.\n\n### Credit\n\nReported by Vaadata.\n\n### Resources\n\n- [CWE-918: Server-Side Request Forgery (SSRF)](https://cwe.mitre.org/data/definitions/918.html)\n- [CWE-20: Improper Input Validation](https://cwe.mitre.org/data/definitions/20.html)\n- [CWE-441: Unintended Proxy or Intermediary](https://cwe.mitre.org/data/definitions/441.html)\n- [CWE-345: Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html)",
  "id": "GHSA-5rr4-8452-hf4v",
  "modified": "2026-07-07T20:56:19Z",
  "published": "2026-07-07T20:56:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-5rr4-8452-hf4v"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/better-auth/better-auth"
    },
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/releases/tag/v1.6.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@better-auth/sso provider registration has server-side request forgery via unvalidated OIDC endpoints"
}

CVE-2026-53513 (GCVE-0-2026-53513)

Vulnerability from cvelistv5 – Published: 2026-07-15 17:15 – Updated: 2026-07-15 19:29

Title

Better Auth: Server-side request forgery via unvalidated OIDC endpoints on @better-auth/sso provider registration

Summary

Better Auth is an authentication and authorization library for TypeScript. Prior to 1.6.11, the @better-auth/sso plugin's POST /sso/register and POST /sso/update-provider endpoints accept attacker-controlled oidcConfig.userInfoEndpoint, tokenEndpoint, and jwksEndpoint URLs when skipDiscovery: true is set, store them on the ssoProvider row without origin validation, and fetch them during OIDC callback, allowing non-blind server-side request forgery and possible account linking when trustEmailVerified: true is configured. This issue is fixed in version 1.6.11.

Severity

9.6 (Critical)


                        
                          CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N

SSVC

Exploitation: none Automatable: no Technical Impact: total

CISA Coordinator (v2.0.3)

CWE

CWE-20 - Improper Input Validation
CWE-345 - Insufficient Verification of Data Authenticity
CWE-441 - Unintended Proxy or Intermediary ('Confused Deputy')
CWE-918 - Server-Side Request Forgery (SSRF)

Assigner

GitHub_M

References

4 references

URL	Tags
https://github.com/better-auth/better-auth/securi…	x_refsource_CONFIRM
https://github.com/better-auth/better-auth/pull/9574	x_refsource_MISC
https://github.com/better-auth/better-auth/commit…	x_refsource_MISC
https://github.com/better-auth/better-auth/releas…	x_refsource_MISC

Impacted products

2 products

Vendor	Product	Version
better-auth	better-auth	Affected: >= 0.1.0, < 1.6.11
@better-auth	sso	Affected: >= 0.1.0, < 1.6.11

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-53513",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-15T19:28:52.542592Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-15T19:29:02.266Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "better-auth",
          "vendor": "better-auth",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 0.1.0, \u003c 1.6.11"
            }
          ]
        },
        {
          "product": "sso",
          "vendor": "@better-auth",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 0.1.0, \u003c 1.6.11"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Better Auth is an authentication and authorization library for TypeScript. Prior to 1.6.11, the @better-auth/sso plugin\u0027s POST /sso/register and POST /sso/update-provider endpoints accept attacker-controlled oidcConfig.userInfoEndpoint, tokenEndpoint, and jwksEndpoint URLs when skipDiscovery: true is set, store them on the ssoProvider row without origin validation, and fetch them during OIDC callback, allowing non-blind server-side request forgery and possible account linking when trustEmailVerified: true is configured. This issue is fixed in version 1.6.11."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 9.6,
            "baseSeverity": "CRITICAL",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-20",
              "description": "CWE-20: Improper Input Validation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-345",
              "description": "CWE-345: Insufficient Verification of Data Authenticity",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-441",
              "description": "CWE-441: Unintended Proxy or Intermediary (\u0027Confused Deputy\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-918",
              "description": "CWE-918: Server-Side Request Forgery (SSRF)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-15T17:15:59.611Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/better-auth/better-auth/security/advisories/GHSA-5rr4-8452-hf4v",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-5rr4-8452-hf4v"
        },
        {
          "name": "https://github.com/better-auth/better-auth/pull/9574",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/better-auth/better-auth/pull/9574"
        },
        {
          "name": "https://github.com/better-auth/better-auth/commit/37f60cb176cb53147da7dfd5ec15afa5b486e81e",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/better-auth/better-auth/commit/37f60cb176cb53147da7dfd5ec15afa5b486e81e"
        },
        {
          "name": "https://github.com/better-auth/better-auth/releases/tag/v1.6.11",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/better-auth/better-auth/releases/tag/v1.6.11"
        }
      ],
      "source": {
        "advisory": "GHSA-5rr4-8452-hf4v",
        "discovery": "UNKNOWN"
      },
      "title": "Better Auth: Server-side request forgery via unvalidated OIDC endpoints on @better-auth/sso provider registration"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-53513",
    "datePublished": "2026-07-15T17:15:59.611Z",
    "dateReserved": "2026-06-09T17:30:33.455Z",
    "dateUpdated": "2026-07-15T19:29:02.266Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

GHSA-5RR4-8452-HF4V

Am I affected?

Summary

Details

Patches

Workarounds

Impact

Credit

Resources

CVE-2026-53513 (GCVE-0-2026-53513)

Tags

Sightings

Nomenclature