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
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Am I affected? You are affected if all of the following are true: - You depend on @better-auth/sso at any version in = 1.2.10, < 1.6.11, or any current next pre-release. - You enable both sso() and organization() plugins. - providersLimit is at its default (10) or any non-zero value, so SSO provider registration is enabled for authenticated users. - An organization has non-admin members, or your application can add users to organizations as regular members. You are at the highest risk if any of these also hold: - Organization membership can be obtained without a direct admin decision, such as through open invitations, self-serve onboarding, public team joins, or SCIM bulk imports. - organizationProvisioning.defaultRole or organizationProvisioning.getRole returns admin or higher for SSO-provisioned users. The bug then becomes unauthorized admin creation in the org. - domainVerification.enabled is false (the default). The malicious provider is immediately usable. Fix: 1. Upgrade to…
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.
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: 1. Upgrade to @better-auth/sso@1.6.11 or later. 2. If developers cannot upgrade, see workarounds below. Summary The @better-auth/sso plugin's POST…
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.