Every CVE Search/ Get API key

CVE-2026-35511

Authorizer: Zero-click account takeover via OAuth identity linking to unverified email accounts

8.7 HighFix available

The OAuth callback handler links incoming OAuth identities (Google, GitHub, etc.) to existing accounts matched by email address without verifying that the existing account's email was verified by its original owner. An attacker who pre-registers with a victim's email address (without verifying it) gains persistent password-based access to the victim's account after the victim completes a normal OAuth login. Verified against HEAD (commit 73679fa).

Root Cause

In internal/http_handlers/oauth_callback.go, when an OAuth login occurs for an email that already exists in the database:

Line 125: The existing user is looked up by email:

existingUser, err := h.StorageProvider.GetUserByEmail(ctx, refs.StringValue(user.Email))

Line 164: The OAuth user object is replaced with the existing user:

user = existingUser

Lines 173-176: The OAuth provider is appended to the existing user's signup methods:

signupMethod := existingUser.SignupMethods
if !strings.Contains(signupMethod, provider) {
    signupMethod = signupMethod + "," + provider
}
user.SignupMethods = signupMethod

Lines 179-181: If the existing account's email was NOT verified, it is automatically verified:

if user.EmailVerifiedAt == nil {
    now := time.Now().Unix()
    user.EmailVerifiedAt = &now
}

Line 219: The merged user is saved to the database:

user, err = h.StorageProvider.UpdateUser(ctx, user)

At no point is the existing account's password invalidated or the owner notified that a new OAuth identity was linked.

Attack Chain

  1. Attacker signs up with [email protected] using email/password. Attacker sets a known password but does NOT click the email verification link. The account exists in the database with EmailVerifiedAt = nil.

  2. Some time later, the real owner of [email protected] logs in via Google OAuth (a completely normal action).

  3. The OAuth callback at line 125 finds the attacker's existing account by email.

  4. At line 164, the Google OAuth identity is linked to the attacker's account.

  5. At line 179-181, the email is automatically verified (the attacker never verified it, but now it's marked as verified).

  6. At line 175, "google" is appended to the signup methods. The account now has both "basic_auth" and "google" as valid login methods.

  7. The attacker's original password is still valid in the database. It was never cleared, changed, or invalidated.

  8. The attacker logs in with [email protected] and the password they originally set. They now have full access to the victim's account, including any data the victim added via their Google session.

Why This Is Zero-Click

The victim performs no unusual action. They simply log in via their Google account, which is the expected, secure behavior. The attacker staged the account beforehand and gains access without any further interaction.

This is a classic Account Linking vulnerability (cited in OWASP authentication guidelines). The core logic flaw is a trust boundary violation. Authorizer correctly trusts that Google has verified the email address, but it incorrectly extends that trust to validate the password that was set by the unverified attacker. The attacker maintains persistent, password-based backdoor access to the victim's account, even if the victim later revokes Authorizer's OAuth access from their Google account settings. The password was set before Google was ever involved and is never invalidated by the linking process.

Impact

  • Full account takeover for any user who logs in via OAuth
  • Attacker maintains persistent password-based access even after the victim changes OAuth providers
  • All data the victim creates after OAuth login is accessible to the attacker
  • The victim has no indication their account was pre-staged
  • Affects every OAuth provider configured in Authorizer (Google, GitHub, Facebook, Apple, LinkedIn, Twitter, Discord, Twitch, Roblox, Microsoft)

Suggested Fix

Before linking an OAuth identity to an existing account, verify that the existing account's email is already verified:

existingUser, err := h.StorageProvider.GetUserByEmail(ctx, refs.StringValue(user.Email))
if err == nil {
    // Account exists. Only link if email is already verified.
    if existingUser.EmailVerifiedAt == nil {
        // Email not verified by original owner. Do NOT link.
        // Either: reject the login, or create a new separate account,
        // or delete the unverified account and create a fresh one for the OAuth user.
    }
}

Additionally, when linking a new OAuth identity, invalidate any existing password on the account or require the user to re-authenticate via the original method.

Credit

Koda Reef

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
None
User interaction
Passive

What an attacker can affect

Confidentiality
High
Integrity
High
Availability
High

What each source reports

GitHub Advisories Score usedGHSA-29rf-f4vv-pvq6 8.7

Authorizer: Zero-click account takeover via OAuth identity linking to unverified email accounts

The OAuth callback handler links incoming OAuth identities (Google, GitHub, etc.) to existing accounts matched by email address without verifying that the existing account's email was verified by its original owner. An attacker who pre-registers with a victim's email address (without verifying it) gains persistent password-based access to the victim's account after the victim completes a normal OAuth login. Verified against HEAD (commit 73679fa).

Root Cause

In internal/http_handlers/oauth_callback.go, when an OAuth login occurs for an email that already exists in the database:

Line 125: The existing user is looked up by email:

existingUser, err := h.StorageProvider.GetUserByEmail(ctx, refs.StringValue(user.Email))

Line 164: The OAuth user object is replaced with the existing user:

user = existingUser

Lines 173-176: The OAuth provider is appended to the existing user's signup methods:

signupMethod := existingUser.SignupMethods
if !strings.Contains(signupMethod, provider) {
    signupMethod = signupMethod + "," + provider
}
user.SignupMethods = signupMethod

Lines 179-181: If the existing account's email was NOT verified, it is automatically verified:

if user.EmailVerifiedAt == nil {
    now := time.Now().Unix()
    user.EmailVerifiedAt = &now
}

Line 219: The merged user is saved to the database:

user, err = h.StorageProvider.UpdateUser(ctx, user)

At no point is the existing account's password invalidated or the owner notified that a new OAuth identity was linked.

Attack Chain

  1. Attacker signs up with [email protected] using email/password. Attacker sets a known password but does NOT click the email verification link. The account exists in the database with EmailVerifiedAt = nil.

  2. Some time later, the real owner of [email protected] logs in via Google OAuth (a completely normal action).

  3. The OAuth callback at line 125 finds the attacker's existing account by email.

  4. At line 164, the Google OAuth identity is linked to the attacker's account.

  5. At line 179-181, the email is automatically verified (the attacker never verified it, but now it's marked as verified).

  6. At line 175, "google" is appended to the signup methods. The account now has both "basic_auth" and "google" as valid login methods.

  7. The attacker's original password is still valid in the database. It was never cleared, changed, or invalidated.

  8. The attacker logs in with [email protected] and the password they originally set. They now have full access to the victim's account, including any data the victim added via their Google session.

Why This Is Zero-Click

The victim performs no unusual action. They simply log in via their Google account, which is the expected, secure behavior. The attacker staged the account beforehand and gains access without any further interaction.

This is a classic Account Linking vulnerability (cited in OWASP authentication guidelines). The core logic flaw is a trust boundary violation. Authorizer correctly trusts that Google has verified the email address, but it incorrectly extends that trust to validate the password that was set by the unverified attacker. The attacker maintains persistent, password-based backdoor access to the victim's account, even if the victim later revokes Authorizer's OAuth access from their Google account settings. The password was set before Google was ever involved and is never invalidated by the linking process.

Impact

  • Full account takeover for any user who logs in via OAuth
  • Attacker maintains persistent password-based access even after the victim changes OAuth providers
  • All data the victim creates after OAuth login is accessible to the attacker
  • The victim has no indication their account was pre-staged
  • Affects every OAuth provider configured in Authorizer (Google, GitHub, Facebook, Apple, LinkedIn, Twitter, Discord, Twitch, Roblox, Microsoft)

Suggested Fix

Before linking an OAuth identity…

Record
GHSA-29rf-f4vv-pvq6
CVSS 4.0
8.7 HighCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Weakness
CWE-287
Updated
2026-11-02
OSVGHSA-29rf-f4vv-pvq6 8.7

Authorizer: Zero-click account takeover via OAuth identity linking to unverified email accounts

The OAuth callback handler links incoming OAuth identities (Google, GitHub, etc.) to existing accounts matched by email address without verifying that the existing account's email was verified by its original owner. An attacker who pre-registers with a victim's email address (without verifying it) gains persistent password-based access to the victim's account after the victim completes a normal OAuth login. Verified against HEAD (commit 73679fa).

Root Cause

In internal/http_handlers/oauth_callback.go, when an OAuth login occurs for an email that already exists in the database:

Line 125: The existing user is looked up by email:

existingUser, err := h.StorageProvider.GetUserByEmail(ctx, refs.StringValue(user.Email))

Line 164: The OAuth user object is replaced with the existing user:

user = existingUser

Lines 173-176: The OAuth provider is appended to the existing user's signup methods:

signupMethod := existingUser.SignupMethods
if !strings.Contains(signupMethod, provider) {
    signupMethod = signupMethod + "," + provider
}
user.SignupMethods = signupMethod

Lines 179-181: If the existing account's email was NOT verified, it is automatically verified:

if user.EmailVerifiedAt == nil {
    now := time.Now().Unix()
    user.EmailVerifiedAt = &now
}

Line 219: The merged user is saved to the database:

user, err = h.StorageProvider.UpdateUser(ctx, user)

At no point is the existing account's password invalidated or the owner notified that a new OAuth identity was linked.

Attack Chain

  1. Attacker signs up with [email protected] using email/password. Attacker sets a known password but does NOT click the email verification link. The account exists in the database with EmailVerifiedAt = nil.

  2. Some time later, the real owner of [email protected] logs in via Google OAuth (a completely normal action).

  3. The OAuth callback at line 125 finds the attacker's existing account by email.

  4. At line 164, the Google OAuth identity is linked to the attacker's account.

  5. At line 179-181, the email is automatically verified (the attacker never verified it, but now it's marked as verified).

  6. At line 175, "google" is appended to the signup methods. The account now has both "basic_auth" and "google" as valid login methods.

  7. The attacker's original password is still valid in the database. It was never cleared, changed, or invalidated.

  8. The attacker logs in with [email protected] and the password they originally set. They now have full access to the victim's account, including any data the victim added via their Google session.

Why This Is Zero-Click

The victim performs no unusual action. They simply log in via their Google account, which is the expected, secure behavior. The attacker staged the account beforehand and gains access without any further interaction.

This is a classic Account Linking vulnerability (cited in OWASP authentication guidelines). The core logic flaw is a trust boundary violation. Authorizer correctly trusts that Google has verified the email address, but it incorrectly extends that trust to validate the password that was set by the unverified attacker. The attacker maintains persistent, password-based backdoor access to the victim's account, even if the victim later revokes Authorizer's OAuth access from their Google account settings. The password was set before Google was ever involved and is never invalidated by the linking process.

Impact

  • Full account takeover for any user who logs in via OAuth
  • Attacker maintains persistent password-based access even after the victim changes OAuth providers
  • All data the victim creates after OAuth login is accessible to the attacker
  • The victim has no indication their account was pre-staged
  • Affects every OAuth provider configured in Authorizer (Google, GitHub, Facebook, Apple, LinkedIn, Twitter, Discord, Twitch, Roblox, Microsoft)

Suggested Fix

Before linking an OAuth identity…

Record
GHSA-29rf-f4vv-pvq6
CVSS 4.0
8.7 HighCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Weakness
CWE-287
Updated
2026-11-02
OSVGO-2026-6227 No score

Authorizer: Zero-click account takeover via OAuth identity linking to unverified email accounts in github.com/authorizerdev/authorizer

Authorizer: Zero-click account takeover via OAuth identity linking to unverified email accounts in github.com/authorizerdev/authorizer

Record
GO-2026-6227
Updated
2026-11-02
OSVopenSUSE-SU-2026:21761-1 No score

Security update for govulncheck-vulndb

This update for govulncheck-vulndb fixes the following issues:

  • Update to version 0.0.20260827T195228 2026-08-27T19:52:28Z (jsc#PED-11136).

    Go CVE Numbering Authority IDs added or updated with aliases:

    • GO-2026-5026 CVE-2026-39821
    • GO-2026-6225
    • GO-2026-6250 CVE-2026-63328 GHSA-8rc5-4fr6-64pw
    • GO-2026-6253 CVE-2026-17106 GHSA-hfg8-hc9c-6c3h
    • GO-2026-6254 CVE-2026-53941 GHSA-vjhx-2cqw-3q6q
    • GO-2026-6255 CVE-2026-61711 GHSA-7236-3392-c5c6
    • GO-2026-6256 CVE-2026-61712 GHSA-72x6-4j93-7w86
    • GO-2026-6258 CVE-2026-45404 GHSA-42cj-99w8-cp2p
    • GO-2026-6259 CVE-2026-32637 GHSA-j2g6-362q-6qc6
    • GO-2026-6260 CVE-2026-55149 GHSA-qqff-5854-px68
    • GO-2026-6261 CVE-2026-54061 GHSA-rrwh-6jrq-wp5v
    • GO-2026-6262 GHSA-22w5-2fxg-vrwx
    • GO-2026-6263 CVE-2026-54168 GHSA-6f2p-296r-cc28
    • GO-2026-6264 CVE-2026-54245 GHSA-7q96-f8xw-jv5j
    • GO-2026-6265 GHSA-8fxq-53rx-ph5f
    • GO-2026-6266 CVE-2026-54167 GHSA-f5f4-3hh4-f54m
    • GO-2026-6267 GHSA-h58c-xccx-75m3
    • GO-2026-6268 GHSA-q9c5-pp7m-fm2g
    • GO-2026-6269 GHSA-rxhg-vcww-2mpw
    • GO-2026-6270 CVE-2026-54162 GHSA-x3g7-qrwc-f6c5
    • GO-2026-6271 CVE-2026-67448 GHSA-8r62-w5wh-fc5m
    • GO-2026-6272 CVE-2026-67447 GHSA-r553-m4fv-5v97
    • GO-2026-6273 CVE-2026-64679 GHSA-26w5-6g95-gj28
    • GO-2026-6274 CVE-2026-76905 GHSA-mmfr-pmjx-hw9w
    • GO-2026-6275 CVE-2026-77354 GHSA-xhj3-7xw9-vr34
    • GO-2026-6277 GHSA-4ph6-mjv7-3fq6
    • GO-2026-6278 GHSA-w67g-5rqw-f597
    • GO-2026-6279 CVE-2026-6046 GHSA-3vmp-whvv-5v9v
    • GO-2026-6280 CVE-2026-7387 GHSA-6hxm-w4hv-vgvw
    • GO-2026-6281 CVE-2026-6961 GHSA-8qq9-cqj8-82w4
    • GO-2026-6282 CVE-2026-7184 GHSA-9p44-r552-4wp9
    • GO-2026-6283 CVE-2026-6689 GHSA-c28q-m4gf-vg4q
    • GO-2026-6284 CVE-2026-55477 GHSA-jm48-m3rr-9hgg
    • GO-2026-6285 CVE-2026-6739 GHSA-m2w9-h2mm-79qr
    • GO-2026-6286 CVE-2026-3433 GHSA-rp4v-qc77-phm4
    • GO-2026-6287 GHSA-vx2m-jpxr-xv7w
    • GO-2026-6288 CVE-2026-11624 GHSA-76g7-m3xw-x9gr
    • GO-2026-6289 GHSA-w8j7-39hp-8x59
    • GO-2026-6290 CVE-2026-55581 GHSA-3x77-wg38-92r3
    • GO-2026-6291 CVE-2026-55582 GHSA-74hp-mggr-hv58
    • GO-2026-6292 CVE-2026-55580 GHSA-f5pj-2738-996m
    • GO-2026-6293 CVE-2026-55677 GHSA-vfp3-v2gw-7wfq
    • GO-2026-6294 CVE-2026-55092 GHSA-mcj4-mphf-j9ff
    • GO-2026-6295 CVE-2026-55637 GHSA-cmwv-wf9p-p8wx
    • GO-2026-6296 CVE-2026-54523 GHSA-79gf-7frw-68m9
    • GO-2026-6297 CVE-2026-50879 GHSA-g743-m6x3-v6wm
    • GO-2026-6298 CVE-2026-54563 GHSA-w5fv-7x5q-g8qp
    • GO-2026-6299 CVE-2026-50884 GHSA-5442-mh7f-72px
    • GO-2026-6300 CVE-2026-50891 GHSA-rcqf-cpv9-g5jf
    • GO-2026-6301 CVE-2026-42350 GHSA-g7gw-m874-7rmf

  • Update to version 0.0.20260819T170606 2026-08-19T17:06:06Z.

    Go CVE Numbering Authority IDs added or updated with aliases:

    • GO-2026-4720 GHSA-v3mg-9v85-fcm7
    • GO-2026-4942 CVE-2026-35172 GHSA-f2g3-hh2r-cwgc
    • GO-2026-4950
    • GO-2026-6093 GHSA-464c-974j-9xm6
    • GO-2026-6094 GHSA-gcjh-h69q-9w9g
    • GO-2026-6095 GHSA-r277-6w6q-xmqw
    • GO-2026-6097 CVE-2026-55495 GHSA-49h3-cwhj-4737
    • GO-2026-6098 CVE-2026-55496 GHSA-8r7f-r8hj-r3rv
    • GO-2026-6099 CVE-2026-57497 GHSA-g35j-m5xg-vh3q
    • GO-2026-6100 CVE-2026-55497 GHSA-g9j2-8w95-3vwv
    • GO-2026-6101 CVE-2026-55502 GHSA-hq88-5x99-x3gf
    • GO-2026-6102 CVE-2026-55499 GHSA-w8x7-h2px-xmq8
    • GO-2026-6103 CVE-2026-73564 GHSA-26gq-p25f-99cp
    • GO-2026-6104 CVE-2026-62323 GHSA-c3jm-gv5r-9wcp
    • GO-2026-6105 GHSA-c534-2w9c-x7fm
    • GO-2026-6106 GHSA-v6w6-358x-2433
    • GO-2026-6107 CVE-2026-73500 GHSA-6vch-q96h-7gc3
    • GO-2026-6108 CVE-2026-73505 GHSA-6xj8-qv9j-xcjq
    • GO-2026-6109 GHSA-86cx-wwf4-phq4
    • GO-2026-6110 CVE-2026-73509 GHSA-95cv-r8x4-vh75
    • GO-2026-6111 CVE-2026-73506 GHSA-fwjx-9p69-h25h
    • GO-2026-6112 CVE-2026-73502 GHSA-jpcw-4wr7-c3vq
    • GO-2026-6113 GHSA-p6ph-3jx2-3337
    • GO-2026-6114 CVE-2026-73499 GHSA-xg4h-6gfc-h4m8
    • GO-2026-6115 CVE-2026-56867
    • GO-2026-6117 GHSA-hp74-gm6m-2qm5
    • GO-2026-6118 CVE-2026-47427 GHSA-w4q6-qw23-4rg7
    • GO-2026-6119 CVE-2026-43983…
Record
openSUSE-SU-2026:21761-1
Updated
2026-11-02
OSVSUSE-SU-2026:23625-1 No score

Security update for govulncheck-vulndb

This update for govulncheck-vulndb fixes the following issues:

  • Update to version 0.0.20260827T195228 2026-08-27T19:52:28Z (jsc#PED-11136).

    Go CVE Numbering Authority IDs added or updated with aliases:

    • GO-2026-5026 CVE-2026-39821
    • GO-2026-6225
    • GO-2026-6250 CVE-2026-63328 GHSA-8rc5-4fr6-64pw
    • GO-2026-6253 CVE-2026-17106 GHSA-hfg8-hc9c-6c3h
    • GO-2026-6254 CVE-2026-53941 GHSA-vjhx-2cqw-3q6q
    • GO-2026-6255 CVE-2026-61711 GHSA-7236-3392-c5c6
    • GO-2026-6256 CVE-2026-61712 GHSA-72x6-4j93-7w86
    • GO-2026-6258 CVE-2026-45404 GHSA-42cj-99w8-cp2p
    • GO-2026-6259 CVE-2026-32637 GHSA-j2g6-362q-6qc6
    • GO-2026-6260 CVE-2026-55149 GHSA-qqff-5854-px68
    • GO-2026-6261 CVE-2026-54061 GHSA-rrwh-6jrq-wp5v
    • GO-2026-6262 GHSA-22w5-2fxg-vrwx
    • GO-2026-6263 CVE-2026-54168 GHSA-6f2p-296r-cc28
    • GO-2026-6264 CVE-2026-54245 GHSA-7q96-f8xw-jv5j
    • GO-2026-6265 GHSA-8fxq-53rx-ph5f
    • GO-2026-6266 CVE-2026-54167 GHSA-f5f4-3hh4-f54m
    • GO-2026-6267 GHSA-h58c-xccx-75m3
    • GO-2026-6268 GHSA-q9c5-pp7m-fm2g
    • GO-2026-6269 GHSA-rxhg-vcww-2mpw
    • GO-2026-6270 CVE-2026-54162 GHSA-x3g7-qrwc-f6c5
    • GO-2026-6271 CVE-2026-67448 GHSA-8r62-w5wh-fc5m
    • GO-2026-6272 CVE-2026-67447 GHSA-r553-m4fv-5v97
    • GO-2026-6273 CVE-2026-64679 GHSA-26w5-6g95-gj28
    • GO-2026-6274 CVE-2026-76905 GHSA-mmfr-pmjx-hw9w
    • GO-2026-6275 CVE-2026-77354 GHSA-xhj3-7xw9-vr34
    • GO-2026-6277 GHSA-4ph6-mjv7-3fq6
    • GO-2026-6278 GHSA-w67g-5rqw-f597
    • GO-2026-6279 CVE-2026-6046 GHSA-3vmp-whvv-5v9v
    • GO-2026-6280 CVE-2026-7387 GHSA-6hxm-w4hv-vgvw
    • GO-2026-6281 CVE-2026-6961 GHSA-8qq9-cqj8-82w4
    • GO-2026-6282 CVE-2026-7184 GHSA-9p44-r552-4wp9
    • GO-2026-6283 CVE-2026-6689 GHSA-c28q-m4gf-vg4q
    • GO-2026-6284 CVE-2026-55477 GHSA-jm48-m3rr-9hgg
    • GO-2026-6285 CVE-2026-6739 GHSA-m2w9-h2mm-79qr
    • GO-2026-6286 CVE-2026-3433 GHSA-rp4v-qc77-phm4
    • GO-2026-6287 GHSA-vx2m-jpxr-xv7w
    • GO-2026-6288 CVE-2026-11624 GHSA-76g7-m3xw-x9gr
    • GO-2026-6289 GHSA-w8j7-39hp-8x59
    • GO-2026-6290 CVE-2026-55581 GHSA-3x77-wg38-92r3
    • GO-2026-6291 CVE-2026-55582 GHSA-74hp-mggr-hv58
    • GO-2026-6292 CVE-2026-55580 GHSA-f5pj-2738-996m
    • GO-2026-6293 CVE-2026-55677 GHSA-vfp3-v2gw-7wfq
    • GO-2026-6294 CVE-2026-55092 GHSA-mcj4-mphf-j9ff
    • GO-2026-6295 CVE-2026-55637 GHSA-cmwv-wf9p-p8wx
    • GO-2026-6296 CVE-2026-54523 GHSA-79gf-7frw-68m9
    • GO-2026-6297 CVE-2026-50879 GHSA-g743-m6x3-v6wm
    • GO-2026-6298 CVE-2026-54563 GHSA-w5fv-7x5q-g8qp
    • GO-2026-6299 CVE-2026-50884 GHSA-5442-mh7f-72px
    • GO-2026-6300 CVE-2026-50891 GHSA-rcqf-cpv9-g5jf
    • GO-2026-6301 CVE-2026-42350 GHSA-g7gw-m874-7rmf

  • Update to version 0.0.20260819T170606 2026-08-19T17:06:06Z.

    Go CVE Numbering Authority IDs added or updated with aliases:

    • GO-2026-4720 GHSA-v3mg-9v85-fcm7
    • GO-2026-4942 CVE-2026-35172 GHSA-f2g3-hh2r-cwgc
    • GO-2026-4950
    • GO-2026-6093 GHSA-464c-974j-9xm6
    • GO-2026-6094 GHSA-gcjh-h69q-9w9g
    • GO-2026-6095 GHSA-r277-6w6q-xmqw
    • GO-2026-6097 CVE-2026-55495 GHSA-49h3-cwhj-4737
    • GO-2026-6098 CVE-2026-55496 GHSA-8r7f-r8hj-r3rv
    • GO-2026-6099 CVE-2026-57497 GHSA-g35j-m5xg-vh3q
    • GO-2026-6100 CVE-2026-55497 GHSA-g9j2-8w95-3vwv
    • GO-2026-6101 CVE-2026-55502 GHSA-hq88-5x99-x3gf
    • GO-2026-6102 CVE-2026-55499 GHSA-w8x7-h2px-xmq8
    • GO-2026-6103 CVE-2026-73564 GHSA-26gq-p25f-99cp
    • GO-2026-6104 CVE-2026-62323 GHSA-c3jm-gv5r-9wcp
    • GO-2026-6105 GHSA-c534-2w9c-x7fm
    • GO-2026-6106 GHSA-v6w6-358x-2433
    • GO-2026-6107 CVE-2026-73500 GHSA-6vch-q96h-7gc3
    • GO-2026-6108 CVE-2026-73505 GHSA-6xj8-qv9j-xcjq
    • GO-2026-6109 GHSA-86cx-wwf4-phq4
    • GO-2026-6110 CVE-2026-73509 GHSA-95cv-r8x4-vh75
    • GO-2026-6111 CVE-2026-73506 GHSA-fwjx-9p69-h25h
    • GO-2026-6112 CVE-2026-73502 GHSA-jpcw-4wr7-c3vq
    • GO-2026-6113 GHSA-p6ph-3jx2-3337
    • GO-2026-6114 CVE-2026-73499 GHSA-xg4h-6gfc-h4m8
    • GO-2026-6115 CVE-2026-56867
    • GO-2026-6117 GHSA-hp74-gm6m-2qm5
    • GO-2026-6118 CVE-2026-47427 GHSA-w4q6-qw23-4rg7
    • GO-2026-6119 CVE-2026-43983…
Record
SUSE-SU-2026:23625-1
Updated
2026-11-02

Affected packages

Affected packages
PackageAffectedFixed
github.com/authorizerdev/authorizer
Go
 before 0.0.0-20260807033110-66fe488fd2a4
0.0.0-20260807033110-66fe488fd2a4
govulncheck-vulndb
SUSE:Linux Enterprise Server 16.0
From an advisory covering 181 CVEs
 before 0.0.20260827T195228-160000.1.1
0.0.20260827T195228-160000.1.1
govulncheck-vulndb
SUSE:Linux Enterprise Server for SAP applications 16.0
From an advisory covering 181 CVEs
 before 0.0.20260827T195228-160000.1.1
0.0.20260827T195228-160000.1.1
govulncheck-vulndb
openSUSE:Leap 16.0
From an advisory covering 181 CVEs
 before 0.0.20260827T195228-160000.1.1
0.0.20260827T195228-160000.1.1

History

History
RecordedChangedSources
affected, facts
first indexedGitHub Advisories, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2026-35511 is a high vulnerability (CVSS 8.7) in github.com/authorizerdev/authorizer, published August 14, 2026. No source lists public exploit code. Fixed in github.com/authorizerdev/authorizer 0.0.0-20260807033110-66fe488fd2a4.

References

Show 181 moreShow less
This page doesn't list everything

Left out here: the rest of 4 source descriptions. The JSON record has them.

Pages All vulnerabilities Browse Docs Sources Guide Get API key
MoveEnter Open