NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐹 Go
Not in CISA KEV

CVE-2026-26196 — gogs

Fix: gogs/gogs@295bfba

CVE-2026-26196 is a CWE-598 vulnerability in gogs.io/gogs. The records list no fixed version yet; check the vendor advisory below and apply the mitigations in the meantime.

Gogs: Access tokens get exposed through URL params in API requests

Also known asGHSA-x9p5-w45c-7ffcGO-2026-4619
Published
Updated
Affected
1 pkg
Patched
See advisory
Exploits
None indexed
Exploitation data as of Nov 2, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-26196.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs22th percentile — riskier than 22% of all scored CVEsHighest risk
0.00%0.30%0.61%0.91%0.0%0.3%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected
🐹gogs.io/gogs

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

The Gogs API still accepts tokens in URL parameters such as token and access_token, which can leak through logs, browser history, and referrers.

Details

A static review shows that the API still checks tokens in the URL query before looking at headers:

  • internal/context/auth.go reads c.Query("token")
  • internal/context/auth.go falls back to c.Query("access_token")
  • internal/context/auth.go only checks the Authorization header when the query token is empty
  • internal/context/auth.go authenticates using that token and marks the request as token-authenticated

Token-authenticated requests are accepted by API routes through c.IsTokenAuth checks:

  • internal/route/api/v1/api.go

Impact

If tokens are sent in URLs such as /api/v1/user?token=..., they can leak in logs, browser or shell history, and referrer headers, and can be reused until revoked.

Recommended Fix

  • Authentication headers should be used exclusively for token transmission.
  • Token parameters should be blocked at the proxy or WAF level.
  • Query strings should be scrubbed from logs.
  • A strict referrer policy should be set.

Remediation

A fix is available at https://github.com/gogs/gogs/releases/tag/v0.14.2.

Affected Packages

1 total
EcosystemPackageVulnerable rangeFix
🐹Gogogs.io/gogsall versionsNo fix

Affected Products

1 product · 1 configurations
Application
gogsgogs
< 0.14.2
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for gogs.io/gogs, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Remediation status

    The records we use list no patched version of gogs.io/gogs for CVE-2026-26196. Check the maintainer's advisory, and where your build allows, override or pin the dependency away from the vulnerable range.

  3. Mitigate without a patch

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

### Summary The Gogs API still accepts tokens in URL parameters such as `token` and `access_token`, which can leak through logs, browser history, and referrers. ### Details A static review shows that the API still checks tokens in the URL query before looking at headers: - internal/context/auth.go reads `c.Query("token")` - internal/context/auth.go falls back to `c.Query("access_token")` - internal/context/auth.go only checks the `Authorization` header when the query token is empty - internal/context/auth.go authenticates using that token and marks the request as token-authenticate
O3 Security · Impact-Aware SCA

Is CVE-2026-26196 in your dependencies?

Find it across Go, including transitive dependencies.

CVE-2026-26196: gogs