Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Am I affected? You are affected if your application registers the @better-auth/scim plugin and lets authenticated users generate SCIM tokens. The default canGenerateToken policy was affected, and custom policies were affected when they did not reject provider IDs already used by other account providers. The provider-ID collision issue additionally requires SSO, SAML, OIDC, generic OAuth, or social providers whose account rows use custom provider IDs, plus existing account rows under those IDs. The deprovisioning and email-update issues require only the SCIM plugin and a valid SCIM bearer token. Published versions from @better-auth/scim@1.4.0-beta.27 through 1.6.21 are affected. Beta versions from 1.7.0-beta.0 through 1.7.0-beta.9 are affected. Upgrade to @better-auth/scim@1.6.22 or 1.7.0-beta.10. Summary @better-auth/scim used the same logical provider ID for SCIM provider configuration and account ownership. SCIM token issuance did not reject all account-provider namespaces. An…
Recommended action: Upgrade to 1.7.0-beta.10 (pre-release) or 1.6.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 1. Upgrade to @better-auth/scim@1.7.0-beta.4 (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. 2. Run the schema…
Recommended action: Upgrade to 1.7.0-beta.4 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Am I affected? Users are affected if all of the following are true: - They configure secondaryStorage on betterAuth(...) (Redis, KV, or any external session cache). - session.storeSessionInDatabase is left unset or set to false (the default). - Their application's deployment uses one or more of: - The admin plugin and calls auth.api.removeUser(...) or authClient.admin.removeUser(...). - The anonymous plugin and exposes /delete-anonymous-user or relies on the after-link hook to clean up the anonymous user. - The @better-auth/scim plugin and exposes DELETE /scim/v2/Users/:userId. If storeSessionInDatabase is true, sessions are also written to the database, and the database delete cascades; users are not affected. Fix: 1. Upgrade to better-auth@<patched-version or later (and @better-auth/scim@<patched-version if they use SCIM). 2. If they cannot upgrade, see workarounds below. Summary When secondaryStorage is configured and storeSessionInDatabase is false, three user-deletion endpoints…
Recommended action: Upgrade to 1.6.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.