Every CVE Search/ Get API key

CVE-2026-55987

OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)

8.1 HighFix available

OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
Low
User interaction
None

What an attacker can affect

Confidentiality
High
Integrity
High
Availability
None

Exploit likelihood

0.41%Up 0.3 points since Aug 14, 2026
90%50%10%1%

What each source reports

CVE List Score used 8.1

OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)

OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)

Record
CVE-2026-55987
CVSS 3.1
8.1 HighCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Weakness
CWE-863
Updated
2026-11-02
EUVDEUVD-2026-58141 8.1

OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)

Record
EUVD-2026-58141
CVSS 3.1
8.1 HighCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Updated
2026-11-02
GitHub AdvisoriesGHSA-vrhc-jjfc-m3m3 8.1

Gitea: OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)

Description

Gitea's OAuth2 sign-in callback reactivates a deactivated user account (IsActive=false) when the user signs in through an authentication source that does not issue refresh tokens (notably GitHub, and any OIDC/OAuth2 source configured without offline_access). PR #38009 added a gate intended to reactivate users only when the OAuth2 auto-sync cron had disabled them, using "the stored refresh token is empty" as the signal. That signal is wrong: for sources that never issue refresh tokens, an empty refresh token is the normal state of every user, so the gate cannot distinguish a cron-disabled account from one an administrator deliberately deactivated. The next time the administrator-deactivated user signs in through the provider, Gitea sets IsActive=true and grants a full session, silently undoing the administrator's action. This is the exact behavior #38009 was written to prevent. (ProhibitLogin, the hard ban, is enforced separately and is not affected.)

No special privileges are required beyond being the deactivated user and being able to sign in through the source.

Root Cause

routers/web/auth/oauth.go (the handleOAuth2SignIn reactivation gate):

if !u.IsActive {
    extLogin, hasExt, err := user_model.GetExternalLogin(ctx, authSource.ID, gothUser.UserID)
    if err != nil { ctx.ServerError("GetExternalLogin", err); return }
    isDisabledByAutoSync := hasExt && extLogin.RefreshToken == ""   // wrong signal
    if isDisabledByAutoSync {
        opts.IsActive = optional.Some(true)                          // reactivates the account
    }
}

The assumption that RefreshToken == "" is produced only by the auto-sync cron is false:

  • The cron's disable path is unreachable for sources without refresh tokens. services/auth/source/oauth2/source_sync.go returns early: if !provider.RefreshTokenAvailable() { return ... }, so it never disables (or touches the tokens of) such users.
  • The stored token is exactly what the provider returned, with no synthesizing: services/externalaccount/user.go stores RefreshToken: gothUser.RefreshToken. When the provider issues none, this is "" from the first login.
  • GitHub never issues a refresh token: goth hardcodes func (p *Provider) RefreshTokenAvailable() bool { return false } (providers/github/github.go). OIDC/OAuth2 without offline_access likewise store "".

So for a GitHub (or no-refresh-token) source, RefreshToken == "" is the state of every user, including one an administrator deactivated, and the gate reactivates them.

Proof of Concept

Setup:

  • A Gitea instance with a GitHub authentication source (Admin Panel -> Authentication Sources -> OAuth2 -> GitHub), or any OAuth2/OIDC source configured without offline_access.
  • Account V: a normal user who has signed in at least once through that source (an external_login_user row exists with empty refresh_token).

Steps:

  1. As an administrator, open Admin Panel -> Users -> V and uncheck "Activated" (is_active=false). Confirm V's requests now bounce to the activation page.
  2. As V, sign in again via "Sign in with GitHub" and complete the provider flow.
  3. V lands in the application with a working session. SELECT is_active FROM "user" WHERE lower_name='v'; now returns true.

Expected (intended by #38009): V stays is_active=false and is routed to the activation page. Actual: V is is_active=true with a full session — the administrator's deactivation is undone.

- GitHub user, ADMIN deactivated                 refreshToken=""    -> REACTIVATED + session granted   <<< admin action undone
- OIDC user w/ refresh token, ADMIN deactivated  refreshToken="..." -> stays disabled  (control)
- OIDC user, AUTO-SYNC cron disabled             refreshToken=""    -> REACTIVATED (intended)
RESULT: BYPASS CONFIRMED.

Gitea's own regression test TestOAuth2CallbackReactivationGating ("auto-sync-disabled user is reactivated") sets RefreshToken="" and asserts reactivation after…

Record
GHSA-vrhc-jjfc-m3m3
CVSS 3.1
8.1 HighCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Weakness
CWE-863
Updated
2026-11-02
NVD 8.1

OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)

Record
CVE-2026-55987
CVSS 3.1
8.1 HighCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Weakness
CWE-863
Updated
2026-11-02
OSV 8.1

OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)

OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)

Record
CVE-2026-55987
CVSS 3.1
8.1 HighCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Weakness
CWE-863
Updated
2026-11-02
OSVGHSA-vrhc-jjfc-m3m3 8.1

Gitea: OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)

Description

Gitea's OAuth2 sign-in callback reactivates a deactivated user account (IsActive=false) when the user signs in through an authentication source that does not issue refresh tokens (notably GitHub, and any OIDC/OAuth2 source configured without offline_access). PR #38009 added a gate intended to reactivate users only when the OAuth2 auto-sync cron had disabled them, using "the stored refresh token is empty" as the signal. That signal is wrong: for sources that never issue refresh tokens, an empty refresh token is the normal state of every user, so the gate cannot distinguish a cron-disabled account from one an administrator deliberately deactivated. The next time the administrator-deactivated user signs in through the provider, Gitea sets IsActive=true and grants a full session, silently undoing the administrator's action. This is the exact behavior #38009 was written to prevent. (ProhibitLogin, the hard ban, is enforced separately and is not affected.)

No special privileges are required beyond being the deactivated user and being able to sign in through the source.

Root Cause

routers/web/auth/oauth.go (the handleOAuth2SignIn reactivation gate):

if !u.IsActive {
    extLogin, hasExt, err := user_model.GetExternalLogin(ctx, authSource.ID, gothUser.UserID)
    if err != nil { ctx.ServerError("GetExternalLogin", err); return }
    isDisabledByAutoSync := hasExt && extLogin.RefreshToken == ""   // wrong signal
    if isDisabledByAutoSync {
        opts.IsActive = optional.Some(true)                          // reactivates the account
    }
}

The assumption that RefreshToken == "" is produced only by the auto-sync cron is false:

  • The cron's disable path is unreachable for sources without refresh tokens. services/auth/source/oauth2/source_sync.go returns early: if !provider.RefreshTokenAvailable() { return ... }, so it never disables (or touches the tokens of) such users.
  • The stored token is exactly what the provider returned, with no synthesizing: services/externalaccount/user.go stores RefreshToken: gothUser.RefreshToken. When the provider issues none, this is "" from the first login.
  • GitHub never issues a refresh token: goth hardcodes func (p *Provider) RefreshTokenAvailable() bool { return false } (providers/github/github.go). OIDC/OAuth2 without offline_access likewise store "".

So for a GitHub (or no-refresh-token) source, RefreshToken == "" is the state of every user, including one an administrator deactivated, and the gate reactivates them.

Proof of Concept

Setup:

  • A Gitea instance with a GitHub authentication source (Admin Panel -> Authentication Sources -> OAuth2 -> GitHub), or any OAuth2/OIDC source configured without offline_access.
  • Account V: a normal user who has signed in at least once through that source (an external_login_user row exists with empty refresh_token).

Steps:

  1. As an administrator, open Admin Panel -> Users -> V and uncheck "Activated" (is_active=false). Confirm V's requests now bounce to the activation page.
  2. As V, sign in again via "Sign in with GitHub" and complete the provider flow.
  3. V lands in the application with a working session. SELECT is_active FROM "user" WHERE lower_name='v'; now returns true.

Expected (intended by #38009): V stays is_active=false and is routed to the activation page. Actual: V is is_active=true with a full session — the administrator's deactivation is undone.

- GitHub user, ADMIN deactivated                 refreshToken=""    -> REACTIVATED + session granted   <<< admin action undone
- OIDC user w/ refresh token, ADMIN deactivated  refreshToken="..." -> stays disabled  (control)
- OIDC user, AUTO-SYNC cron disabled             refreshToken=""    -> REACTIVATED (intended)
RESULT: BYPASS CONFIRMED.

Gitea's own regression test TestOAuth2CallbackReactivationGating ("auto-sync-disabled user is reactivated") sets RefreshToken="" and asserts reactivation after…

Record
GHSA-vrhc-jjfc-m3m3
CVSS 3.1
8.1 HighCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Weakness
CWE-863
Updated
2026-11-02
Show 4 moreShow less
OSVGO-2026-6078 No score

Gitea: OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009) in gitea.dev

Gitea: OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009) in gitea.dev

Record
GO-2026-6078
Updated
2026-11-02
OSVopenSUSE-SU-2026:21551-1 No score

Security update for govulncheck-vulndb

This update for govulncheck-vulndb fixes the following issues:

  • Update to version 0.0.20260727T201416 2026-07-27T20:14:16Z (jsc#PED-11136):

Go CVE Numbering Authority IDs added or updated with aliases:

  • GO-2026-5046 CVE-2026-46385 GHSA-w8j3-pq8g-8m7w
  • GO-2026-5047 CVE-2026-46384 GHSA-mc57-h6j3-3hmv
  • GO-2026-5048 GHSA-mx64-mj3q-7prj
  • GO-2026-5051
  • GO-2026-5069 CVE-2026-30246 GHSA-35hp-hqmv-8qg8
  • GO-2026-5074 CVE-2026-45022 GHSA-389r-gv7p-r3rp
  • GO-2026-5105 CVE-2026-41506 GHSA-3xc5-wrhm-f963
  • GO-2026-5116 CVE-2026-44517 GHSA-49p4-px3h-rq49
  • GO-2026-5158 CVE-2026-41178 GHSA-5wrp-cwcj-q835
  • GO-2026-5198 CVE-2026-41642 GHSA-7235-89m6-f4px
  • GO-2026-5208 CVE-2026-40890 GHSA-77fj-vx54-gvh7
  • GO-2026-5266 CVE-2026-41643 GHSA-8rxh-r2p6-7f2q
  • GO-2026-5309 GHSA-c3wq-j5vh-68rc
  • GO-2026-5327 CVE-2026-2303 GHSA-cp6g-7hqx-qxhp
  • GO-2026-5336 CVE-2026-45571 GHSA-crhj-59gh-8x96
  • GO-2026-5346 CVE-2026-52845 GHSA-f59h-q822-g45g
  • GO-2026-5408 GHSA-gx7w-56w6-g48x
  • GO-2026-5426 CVE-2026-39883 GHSA-hfvc-g4fc-pqhx
  • GO-2026-5435 CVE-2026-35206 GHSA-hr2v-4r36-88hr
  • GO-2026-5452 CVE-2026-34783 GHSA-j6v5-g24h-vg4j
  • GO-2026-5463 CVE-2026-8276 GHSA-jcqv-2g3v-gm88
  • GO-2026-5471 CVE-2026-6993 GHSA-jj45-xvq5-rhh9
  • GO-2026-5490 CVE-2026-44740 GHSA-m3xc-h892-ggx6
  • GO-2026-5492 CVE-2026-45135 GHSA-m675-2p33-xv9g
  • GO-2026-5506 CVE-2026-29181 GHSA-mh2q-q3fh-2475
  • GO-2026-5525 CVE-2026-42285 GHSA-p3w2-64xm-833j
  • GO-2026-5543 CVE-2026-32952 GHSA-pjcq-xvwq-hhpj
  • GO-2026-5548 CVE-2026-44166 GHSA-pq7p-mc74-g65w
  • GO-2026-5566 CVE-2026-35205 GHSA-q5jf-9vfq-h4h7
  • GO-2026-5569 GHSA-q76j-gcg9-vxc6
  • GO-2026-5585 CVE-2026-42554 GHSA-qjv7-627w-8qjv
  • GO-2026-5593 CVE-2026-40611 GHSA-qqx8-2xmm-jrv8
  • GO-2026-5595 CVE-2026-52844 GHSA-qrp7-cvwr-j2c6
  • GO-2026-5597 CVE-2026-44973 GHSA-qw64-3x98-g7q2
  • GO-2026-5606 GHSA-r46f-3rpw-hxrv
  • GO-2026-5617 CVE-2026-42306 GHSA-rg2x-37c3-w2rh
  • GO-2026-5660 CVE-2026-52846 GHSA-vcc4-2c75-vc9v
  • GO-2026-5666 CVE-2026-35204 GHSA-vmx8-mqv2-9gmg
  • GO-2026-5684 CVE-2026-42328 GHSA-w239-58x2-q8p5
  • GO-2026-5693 GHSA-w5pp-99ch-qj29
  • GO-2026-5730 GHSA-wwhq-w58m-w29c
  • GO-2026-5736 CVE-2026-44283 GHSA-x35m-3gp4-4fh5
  • GO-2026-5740 CVE-2026-44301 GHSA-x597-9fr4-5857
  • GO-2026-5748 CVE-2026-7482 GHSA-x8qc-fggm-mpqg
  • GO-2026-5750 CVE-2026-7020 GHSA-x99g-8v8j-25j2
  • GO-2026-5774 GHSA-3fxj-6jh8-hvhx
  • GO-2026-5775 GHSA-9g5q-2w5x-hmxf
  • GO-2026-5777 GHSA-rjr7-jggh-pgcp
  • GO-2026-5781
  • GO-2026-5841 GHSA-259r-337f-4rfw
  • GO-2026-5879 CVE-2026-50162 GHSA-8xwf-rjm4-xvhv
  • GO-2026-5880 CVE-2026-50163 GHSA-fxhp-mv3v-67qp
  • GO-2026-5882 CVE-2026-50151 GHSA-jxpm-75mh-9fp7
  • GO-2026-5884 GHSA-vh4v-2xq2-g5cg
  • GO-2026-5885 CVE-2026-48978 GHSA-xf85-363p-868w
  • GO-2026-5886 CVE-2026-44332 GHSA-g5vh-55hw-rxm8
  • GO-2026-5887 CVE-2026-45045 GHSA-gcfq-8gqf-4876
  • GO-2026-5912 CVE-2026-53624 GHSA-gv83-gqw6-9j2c
  • GO-2026-5954 CVE-2026-49838 GHSA-frrj-87jh-2772
  • GO-2026-5955 CVE-2026-49837 GHSA-gjrg-jjr3-56cm
  • GO-2026-5960 CVE-2026-54063 GHSA-h69g-9hx6-f3v4
  • GO-2026-5971 CVE-2026-37462 GHSA-pw7p-7fqv-hpj8
  • GO-2026-5983 CVE-2026-54448 GHSA-q3fv-x8vg-qqm4
  • GO-2026-6000 CVE-2026-50274 GHSA-74j5-xf3v-crq8
  • GO-2026-6058 CVE-2026-58442 GHSA-h2x6-g7q6-344v
  • GO-2026-6059 CVE-2026-58431 GHSA-h56g-4qw7-2mxg
  • GO-2026-6060 CVE-2026-58426 GHSA-hg5r-vq93-9fv6
  • GO-2026-6061 GHSA-hrxh-6v49-42gf
  • GO-2026-6062 CVE-2026-58434 GHSA-j2w3-9c3r-g83q
  • GO-2026-6063 CVE-2026-58417 GHSA-jr5x-6h83-wrxf
  • GO-2026-6064 CVE-2026-55984 GHSA-m932-crvm-gcp5
  • GO-2026-6065 CVE-2026-55982 GHSA-mg4f-x9v4-6h2p
  • GO-2026-6066 CVE-2026-58507 GHSA-p4mj-98mv-xq26
  • GO-2026-6067 CVE-2026-58445 GHSA-pgqf-926r-548m
  • GO-2026-6068 CVE-2026-58427 GHSA-prr9-9mp4-5gp2
  • GO-2026-6069 CVE-2026-58510 GHSA-q423-49rw-g9mh
  • GO-2026-6070 CVE-2026-58432 GHSA-q9pg-jj6x-j9p6
  • GO-2026-6071 CVE-2026-59766 GHSA-qf2f-qh6p-7v89
  • GO-2026-6072 CVE-2026-56750 GHSA-rgv6-xp99-6mgj
  • GO-2026-6073 CVE-2026-58435…
Record
openSUSE-SU-2026:21551-1
Updated
2026-11-02
OSVSUSE-SU-2026:23216-1 No score

Security update for govulncheck-vulndb

This update for govulncheck-vulndb fixes the following issues:

  • Update to version 0.0.20260727T201416 2026-07-27T20:14:16Z (jsc#PED-11136):

Go CVE Numbering Authority IDs added or updated with aliases:

  • GO-2026-5046 CVE-2026-46385 GHSA-w8j3-pq8g-8m7w
  • GO-2026-5047 CVE-2026-46384 GHSA-mc57-h6j3-3hmv
  • GO-2026-5048 GHSA-mx64-mj3q-7prj
  • GO-2026-5051
  • GO-2026-5069 CVE-2026-30246 GHSA-35hp-hqmv-8qg8
  • GO-2026-5074 CVE-2026-45022 GHSA-389r-gv7p-r3rp
  • GO-2026-5105 CVE-2026-41506 GHSA-3xc5-wrhm-f963
  • GO-2026-5116 CVE-2026-44517 GHSA-49p4-px3h-rq49
  • GO-2026-5158 CVE-2026-41178 GHSA-5wrp-cwcj-q835
  • GO-2026-5198 CVE-2026-41642 GHSA-7235-89m6-f4px
  • GO-2026-5208 CVE-2026-40890 GHSA-77fj-vx54-gvh7
  • GO-2026-5266 CVE-2026-41643 GHSA-8rxh-r2p6-7f2q
  • GO-2026-5309 GHSA-c3wq-j5vh-68rc
  • GO-2026-5327 CVE-2026-2303 GHSA-cp6g-7hqx-qxhp
  • GO-2026-5336 CVE-2026-45571 GHSA-crhj-59gh-8x96
  • GO-2026-5346 CVE-2026-52845 GHSA-f59h-q822-g45g
  • GO-2026-5408 GHSA-gx7w-56w6-g48x
  • GO-2026-5426 CVE-2026-39883 GHSA-hfvc-g4fc-pqhx
  • GO-2026-5435 CVE-2026-35206 GHSA-hr2v-4r36-88hr
  • GO-2026-5452 CVE-2026-34783 GHSA-j6v5-g24h-vg4j
  • GO-2026-5463 CVE-2026-8276 GHSA-jcqv-2g3v-gm88
  • GO-2026-5471 CVE-2026-6993 GHSA-jj45-xvq5-rhh9
  • GO-2026-5490 CVE-2026-44740 GHSA-m3xc-h892-ggx6
  • GO-2026-5492 CVE-2026-45135 GHSA-m675-2p33-xv9g
  • GO-2026-5506 CVE-2026-29181 GHSA-mh2q-q3fh-2475
  • GO-2026-5525 CVE-2026-42285 GHSA-p3w2-64xm-833j
  • GO-2026-5543 CVE-2026-32952 GHSA-pjcq-xvwq-hhpj
  • GO-2026-5548 CVE-2026-44166 GHSA-pq7p-mc74-g65w
  • GO-2026-5566 CVE-2026-35205 GHSA-q5jf-9vfq-h4h7
  • GO-2026-5569 GHSA-q76j-gcg9-vxc6
  • GO-2026-5585 CVE-2026-42554 GHSA-qjv7-627w-8qjv
  • GO-2026-5593 CVE-2026-40611 GHSA-qqx8-2xmm-jrv8
  • GO-2026-5595 CVE-2026-52844 GHSA-qrp7-cvwr-j2c6
  • GO-2026-5597 CVE-2026-44973 GHSA-qw64-3x98-g7q2
  • GO-2026-5606 GHSA-r46f-3rpw-hxrv
  • GO-2026-5617 CVE-2026-42306 GHSA-rg2x-37c3-w2rh
  • GO-2026-5660 CVE-2026-52846 GHSA-vcc4-2c75-vc9v
  • GO-2026-5666 CVE-2026-35204 GHSA-vmx8-mqv2-9gmg
  • GO-2026-5684 CVE-2026-42328 GHSA-w239-58x2-q8p5
  • GO-2026-5693 GHSA-w5pp-99ch-qj29
  • GO-2026-5730 GHSA-wwhq-w58m-w29c
  • GO-2026-5736 CVE-2026-44283 GHSA-x35m-3gp4-4fh5
  • GO-2026-5740 CVE-2026-44301 GHSA-x597-9fr4-5857
  • GO-2026-5748 CVE-2026-7482 GHSA-x8qc-fggm-mpqg
  • GO-2026-5750 CVE-2026-7020 GHSA-x99g-8v8j-25j2
  • GO-2026-5774 GHSA-3fxj-6jh8-hvhx
  • GO-2026-5775 GHSA-9g5q-2w5x-hmxf
  • GO-2026-5777 GHSA-rjr7-jggh-pgcp
  • GO-2026-5781
  • GO-2026-5841 GHSA-259r-337f-4rfw
  • GO-2026-5879 CVE-2026-50162 GHSA-8xwf-rjm4-xvhv
  • GO-2026-5880 CVE-2026-50163 GHSA-fxhp-mv3v-67qp
  • GO-2026-5882 CVE-2026-50151 GHSA-jxpm-75mh-9fp7
  • GO-2026-5884 GHSA-vh4v-2xq2-g5cg
  • GO-2026-5885 CVE-2026-48978 GHSA-xf85-363p-868w
  • GO-2026-5886 CVE-2026-44332 GHSA-g5vh-55hw-rxm8
  • GO-2026-5887 CVE-2026-45045 GHSA-gcfq-8gqf-4876
  • GO-2026-5912 CVE-2026-53624 GHSA-gv83-gqw6-9j2c
  • GO-2026-5954 CVE-2026-49838 GHSA-frrj-87jh-2772
  • GO-2026-5955 CVE-2026-49837 GHSA-gjrg-jjr3-56cm
  • GO-2026-5960 CVE-2026-54063 GHSA-h69g-9hx6-f3v4
  • GO-2026-5971 CVE-2026-37462 GHSA-pw7p-7fqv-hpj8
  • GO-2026-5983 CVE-2026-54448 GHSA-q3fv-x8vg-qqm4
  • GO-2026-6000 CVE-2026-50274 GHSA-74j5-xf3v-crq8
  • GO-2026-6058 CVE-2026-58442 GHSA-h2x6-g7q6-344v
  • GO-2026-6059 CVE-2026-58431 GHSA-h56g-4qw7-2mxg
  • GO-2026-6060 CVE-2026-58426 GHSA-hg5r-vq93-9fv6
  • GO-2026-6061 GHSA-hrxh-6v49-42gf
  • GO-2026-6062 CVE-2026-58434 GHSA-j2w3-9c3r-g83q
  • GO-2026-6063 CVE-2026-58417 GHSA-jr5x-6h83-wrxf
  • GO-2026-6064 CVE-2026-55984 GHSA-m932-crvm-gcp5
  • GO-2026-6065 CVE-2026-55982 GHSA-mg4f-x9v4-6h2p
  • GO-2026-6066 CVE-2026-58507 GHSA-p4mj-98mv-xq26
  • GO-2026-6067 CVE-2026-58445 GHSA-pgqf-926r-548m
  • GO-2026-6068 CVE-2026-58427 GHSA-prr9-9mp4-5gp2
  • GO-2026-6069 CVE-2026-58510 GHSA-q423-49rw-g9mh
  • GO-2026-6070 CVE-2026-58432 GHSA-q9pg-jj6x-j9p6
  • GO-2026-6071 CVE-2026-59766 GHSA-qf2f-qh6p-7v89
  • GO-2026-6072 CVE-2026-56750 GHSA-rgv6-xp99-6mgj
  • GO-2026-6073 CVE-2026-58435…
Record
SUSE-SU-2026:23216-1
Updated
2026-11-02
OSVSUSE-SU-2026:23227-1 No score

Security update for govulncheck-vulndb

This update for govulncheck-vulndb fixes the following issues:

  • Update to version 0.0.20260727T201416 2026-07-27T20:14:16Z (jsc#PED-11136):

Go CVE Numbering Authority IDs added or updated with aliases:

  • GO-2026-5046 CVE-2026-46385 GHSA-w8j3-pq8g-8m7w
  • GO-2026-5047 CVE-2026-46384 GHSA-mc57-h6j3-3hmv
  • GO-2026-5048 GHSA-mx64-mj3q-7prj
  • GO-2026-5051
  • GO-2026-5069 CVE-2026-30246 GHSA-35hp-hqmv-8qg8
  • GO-2026-5074 CVE-2026-45022 GHSA-389r-gv7p-r3rp
  • GO-2026-5105 CVE-2026-41506 GHSA-3xc5-wrhm-f963
  • GO-2026-5116 CVE-2026-44517 GHSA-49p4-px3h-rq49
  • GO-2026-5158 CVE-2026-41178 GHSA-5wrp-cwcj-q835
  • GO-2026-5198 CVE-2026-41642 GHSA-7235-89m6-f4px
  • GO-2026-5208 CVE-2026-40890 GHSA-77fj-vx54-gvh7
  • GO-2026-5266 CVE-2026-41643 GHSA-8rxh-r2p6-7f2q
  • GO-2026-5309 GHSA-c3wq-j5vh-68rc
  • GO-2026-5327 CVE-2026-2303 GHSA-cp6g-7hqx-qxhp
  • GO-2026-5336 CVE-2026-45571 GHSA-crhj-59gh-8x96
  • GO-2026-5346 CVE-2026-52845 GHSA-f59h-q822-g45g
  • GO-2026-5408 GHSA-gx7w-56w6-g48x
  • GO-2026-5426 CVE-2026-39883 GHSA-hfvc-g4fc-pqhx
  • GO-2026-5435 CVE-2026-35206 GHSA-hr2v-4r36-88hr
  • GO-2026-5452 CVE-2026-34783 GHSA-j6v5-g24h-vg4j
  • GO-2026-5463 CVE-2026-8276 GHSA-jcqv-2g3v-gm88
  • GO-2026-5471 CVE-2026-6993 GHSA-jj45-xvq5-rhh9
  • GO-2026-5490 CVE-2026-44740 GHSA-m3xc-h892-ggx6
  • GO-2026-5492 CVE-2026-45135 GHSA-m675-2p33-xv9g
  • GO-2026-5506 CVE-2026-29181 GHSA-mh2q-q3fh-2475
  • GO-2026-5525 CVE-2026-42285 GHSA-p3w2-64xm-833j
  • GO-2026-5543 CVE-2026-32952 GHSA-pjcq-xvwq-hhpj
  • GO-2026-5548 CVE-2026-44166 GHSA-pq7p-mc74-g65w
  • GO-2026-5566 CVE-2026-35205 GHSA-q5jf-9vfq-h4h7
  • GO-2026-5569 GHSA-q76j-gcg9-vxc6
  • GO-2026-5585 CVE-2026-42554 GHSA-qjv7-627w-8qjv
  • GO-2026-5593 CVE-2026-40611 GHSA-qqx8-2xmm-jrv8
  • GO-2026-5595 CVE-2026-52844 GHSA-qrp7-cvwr-j2c6
  • GO-2026-5597 CVE-2026-44973 GHSA-qw64-3x98-g7q2
  • GO-2026-5606 GHSA-r46f-3rpw-hxrv
  • GO-2026-5617 CVE-2026-42306 GHSA-rg2x-37c3-w2rh
  • GO-2026-5660 CVE-2026-52846 GHSA-vcc4-2c75-vc9v
  • GO-2026-5666 CVE-2026-35204 GHSA-vmx8-mqv2-9gmg
  • GO-2026-5684 CVE-2026-42328 GHSA-w239-58x2-q8p5
  • GO-2026-5693 GHSA-w5pp-99ch-qj29
  • GO-2026-5730 GHSA-wwhq-w58m-w29c
  • GO-2026-5736 CVE-2026-44283 GHSA-x35m-3gp4-4fh5
  • GO-2026-5740 CVE-2026-44301 GHSA-x597-9fr4-5857
  • GO-2026-5748 CVE-2026-7482 GHSA-x8qc-fggm-mpqg
  • GO-2026-5750 CVE-2026-7020 GHSA-x99g-8v8j-25j2
  • GO-2026-5774 GHSA-3fxj-6jh8-hvhx
  • GO-2026-5775 GHSA-9g5q-2w5x-hmxf
  • GO-2026-5777 GHSA-rjr7-jggh-pgcp
  • GO-2026-5781
  • GO-2026-5841 GHSA-259r-337f-4rfw
  • GO-2026-5879 CVE-2026-50162 GHSA-8xwf-rjm4-xvhv
  • GO-2026-5880 CVE-2026-50163 GHSA-fxhp-mv3v-67qp
  • GO-2026-5882 CVE-2026-50151 GHSA-jxpm-75mh-9fp7
  • GO-2026-5884 GHSA-vh4v-2xq2-g5cg
  • GO-2026-5885 CVE-2026-48978 GHSA-xf85-363p-868w
  • GO-2026-5886 CVE-2026-44332 GHSA-g5vh-55hw-rxm8
  • GO-2026-5887 CVE-2026-45045 GHSA-gcfq-8gqf-4876
  • GO-2026-5912 CVE-2026-53624 GHSA-gv83-gqw6-9j2c
  • GO-2026-5954 CVE-2026-49838 GHSA-frrj-87jh-2772
  • GO-2026-5955 CVE-2026-49837 GHSA-gjrg-jjr3-56cm
  • GO-2026-5960 CVE-2026-54063 GHSA-h69g-9hx6-f3v4
  • GO-2026-5971 CVE-2026-37462 GHSA-pw7p-7fqv-hpj8
  • GO-2026-5983 CVE-2026-54448 GHSA-q3fv-x8vg-qqm4
  • GO-2026-6000 CVE-2026-50274 GHSA-74j5-xf3v-crq8
  • GO-2026-6058 CVE-2026-58442 GHSA-h2x6-g7q6-344v
  • GO-2026-6059 CVE-2026-58431 GHSA-h56g-4qw7-2mxg
  • GO-2026-6060 CVE-2026-58426 GHSA-hg5r-vq93-9fv6
  • GO-2026-6061 GHSA-hrxh-6v49-42gf
  • GO-2026-6062 CVE-2026-58434 GHSA-j2w3-9c3r-g83q
  • GO-2026-6063 CVE-2026-58417 GHSA-jr5x-6h83-wrxf
  • GO-2026-6064 CVE-2026-55984 GHSA-m932-crvm-gcp5
  • GO-2026-6065 CVE-2026-55982 GHSA-mg4f-x9v4-6h2p
  • GO-2026-6066 CVE-2026-58507 GHSA-p4mj-98mv-xq26
  • GO-2026-6067 CVE-2026-58445 GHSA-pgqf-926r-548m
  • GO-2026-6068 CVE-2026-58427 GHSA-prr9-9mp4-5gp2
  • GO-2026-6069 CVE-2026-58510 GHSA-q423-49rw-g9mh
  • GO-2026-6070 CVE-2026-58432 GHSA-q9pg-jj6x-j9p6
  • GO-2026-6071 CVE-2026-59766 GHSA-qf2f-qh6p-7v89
  • GO-2026-6072 CVE-2026-56750 GHSA-rgv6-xp99-6mgj
  • GO-2026-6073 CVE-2026-58435…
Record
SUSE-SU-2026:23227-1
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
code.gitea.io/gitea
Go
 before 1.27.0
1.27.0
gitea.dev
Go
 before 1.27.0
1.27.0
govulncheck-vulndb
SUSE:Linux Enterprise Server 16.0
 before 0.0.20260727T201416-160000.1.1
0.0.20260727T201416-160000.1.1
govulncheck-vulndb
SUSE:Linux Enterprise Server for SAP applications 16.0
 before 0.0.20260727T201416-160000.1.1
0.0.20260727T201416-160000.1.1
govulncheck-vulndb
openSUSE:Leap 16.0
 before 0.0.20260727T201416-160000.1.1
0.0.20260727T201416-160000.1.1

History

History
RecordedChangedSources
first indexedCVE List, EUVD, GitHub Advisories, NVD, OSV

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

In short

CVE-2026-55987 is a high vulnerability (CVSS 8.1) in Gitea Open Source Git Server, published July 21, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.41%, the 35th percentile. Fixed in code.gitea.io/gitea 1.27.0.

References

Show 80 moreShow less
This page doesn't list everything

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

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