How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

357,869

Total vulnerabilities in the database

@better-auth/scim: Account/provider takeover via missing owner binding on non-org SCIM providers — @better-auth / scim

Authorization Bypass Through User-Controlled Key

Am I affected?

Users are affected if all of these hold:

They install and register the @better-auth/scim plugin (plugins: [scim()]).
They create SCIM providers without an organizationId, that is, non-organization ("personal") providers. Organization-scoped providers are not affected because they enforce organization membership and role.
Their application's deployment has more than one authenticated user, so one account can target another user's provider.
They have not set providerOwnership: { enabled: true }.

The SCIM management endpoints first shipped in 1.5.0, so every stable release from 1.5.0 onward is affected, and the stable line is not patched. On the pre-release line, builds through 1.7.0-beta.3 are affected, and 1.7.0-beta.4 carries the fix.

Fix:

Upgrade to @better-auth/[email protected] (then 1.7.0). This is a breaking change: it removes the providerOwnership option, makes owner binding mandatory, and adds a permanent scimProvider.userId column.
Run the schema migration after upgrading (npx auth migrate). Connections created before the upgrade carry no owner and become unreachable through the management endpoints, so reclaim them at the database level.
The 1.6.x stable line is not patched. If developers stay on it, apply the workaround below.

Summary

@better-auth/scim does not bind non-organization SCIM providers to their creator in the default configuration. Any authenticated user can manage another user's non-org provider, including reading its metadata, listing connections, regenerating its SCIM bearer token, and deleting the connection. Regenerating the token rotates it: the legitimate token stops working and the attacker holds a valid one.

Details

The plugin tracks provider ownership through an opt-in providerOwnership option and a scimProvider.userId column. Both default to off. When ownership is disabled, a non-org provider row is created without a userId, and the management access check denies access only when a stored owner id is present and differs from the caller:

// non-organization branch of the access check
} else if (provider.userId &amp;&amp; provider.userId !== userId) {
  throw new APIError(&quot;FORBIDDEN&quot;, { message: &quot;You must be the owner to access this provider&quot; });
}

Because the default row has no userId, the condition is false and the request is allowed. The same gap reaches every management operation: token generation and regeneration, single-provider read, the connection list (which returns providers where p.userId === userId || !p.userId), and provider deletion.

The most sensitive operation is token regeneration. If Alice creates a non-org provider corp-idp, Bob can call the same generate-token endpoint with providerId: "corp-idp". The existing row passes the ownerless access check, so the plugin deletes it, creates a fresh row, and returns a new SCIM bearer token to Bob. Alice's previous token is now invalid, and Bob's token authenticates against that provider's SCIM API routes.

This requires no organization membership and no elevated role. It is reachable in the default scim() configuration whenever non-organization providers are used.

Proof of concept

Two authenticated users, Alice and Bob, in a default scim() setup:

Alice signs in and creates a non-org provider: POST /scim/generate-token with { "providerId": "corp-idp" }.
Bob signs in and reads Alice's provider: GET /scim/get-provider-connection?providerId=corp-idp returns 200 with { "providerId": "corp-idp" }.
Bob regenerates the token: POST /scim/generate-token with { "providerId": "corp-idp" } returns 201 and a new scimToken.
Alice's old token is rejected at GET /scim/v2/Users (401); Bob's regenerated token is accepted (200).

The behavior is reproducible through Better Auth's public API surface with two distinct sessions.

Patches

Fixed in @better-auth/[email protected] (then 1.7.0). The fix makes owner binding mandatory: generateSCIMToken records the creator's userId on every personal connection, and the management endpoints grant access only to that owner. Organization-scoped connections keep their existing membership and role checks. The 1.6.x stable line is not patched.

This release is breaking. It removes the providerOwnership option, owner binding can no longer be disabled, and the scimProvider.userId column becomes a permanent part of the schema, so run npx auth migrate after upgrading. Connections created before the upgrade carry no owner and fail closed; reclaim them by deleting scimProvider rows that have neither organizationId nor userId, or by setting userId to the intended owner, then regenerating tokens.

Workarounds

Until a patched version is available:

Set providerOwnership: { enabled: true } when registering the plugin, then run the schema update so the scimProvider.userId column exists (npx auth generate or npx auth migrate). New non-org providers are then owner-bound and non-owners are denied. Providers created before enabling ownership stay ownerless until recreated.
Or scope every SCIM provider to an organization by always passing organizationId. Organization providers enforce membership and role and are not exposed.
Or restrict access to the SCIM management endpoints at the edge while non-org providers remain ownerless.

Impact

Any authenticated user can take over non-organization SCIM providers created by other users when the plugin runs with its default ownership configuration. An attacker can discover non-org provider connections, read provider metadata, regenerate another user's SCIM token (invalidating the legitimate one), authenticate to the SCIM API routes with the new token, manage SCIM-provisioned users subject to the enabled SCIM functionality, and delete the provider connection.

Credit

Reported by Jvr2022 through a private GitHub Security Advisory.

Resources

CWE-862 Missing Authorization: https://cwe.mitre.org/data/definitions/862.html
CWE-639 Authorization Bypass Through User-Controlled Key: https://cwe.mitre.org/data/definitions/639.html
SCIM 2.0 Protocol (RFC 7644): https://datatracker.ietf.org/doc/html/rfc7644
OAuth 2.0 Bearer Token Usage (RFC 6750): https://datatracker.ietf.org/doc/html/rfc6750

Published: Jul 7, 2026
Updated: Jul 8, 2026
GHSA: GHSA-j8v8-g9cx-5qf4
Severity: High
Exploit:
CISA KEV:

CVSS v3:

Severity: High
Score: 8.3
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L

CWEs:

OWASP TOP 10:

A5 - Broken Access Control

Affected Software
References

Software	From	Fixed in
@better-auth / scim	1.5.0	1.7.0-beta.4

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.