GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-598

Allowed

Use of HTTP Request With Sensitive Query String

Abstraction: Variant · Status: Draft

The web application uses an HTTP method to process a request, but the request includes sensitive information in the query string.

162 vulnerabilities reference this CWE, most recent first.

GHSA-X9P5-W45C-7FFC

Vulnerability from github – Published: 2026-03-05 19:50 – Updated: 2026-03-06 00:58
VLAI
Summary
Gogs: Access tokens get exposed through URL params in API requests
Details

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.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "gogs.io/gogs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.13.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-26196"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-598"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-05T19:50:35Z",
    "nvd_published_at": "2026-03-05T19:16:04Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe Gogs API still accepts tokens in URL parameters such as `token` and `access_token`, which can leak through logs, browser history, and referrers.\n\n### Details\n\nA static review shows that the API still checks tokens in the URL query before looking at headers:\n\n  - internal/context/auth.go reads `c.Query(\"token\")`\n  - internal/context/auth.go falls back to `c.Query(\"access_token\")`\n  - internal/context/auth.go only checks the `Authorization` header when the query token is empty\n  - internal/context/auth.go authenticates using that token and marks the request as token-authenticated\n\nToken-authenticated requests are accepted by API routes through `c.IsTokenAuth` checks:\n  - internal/route/api/v1/api.go\n\n### Impact\n\nIf 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.\n\n### Recommended Fix\n\n- Authentication headers should be used exclusively for token transmission.\n- Token parameters should be blocked at the proxy or WAF level.\n- Query strings should be scrubbed from logs.\n- A strict referrer policy should be set.\n\n### Remediation\n\nA fix is available at https://github.com/gogs/gogs/releases/tag/v0.14.2.",
  "id": "GHSA-x9p5-w45c-7ffc",
  "modified": "2026-03-06T00:58:07Z",
  "published": "2026-03-05T19:50:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/security/advisories/GHSA-x9p5-w45c-7ffc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26196"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/pull/8177"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/commit/295bfba72993c372e7b338438947d8e1a6bed8fd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gogs/gogs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/releases/tag/v0.14.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Gogs: Access tokens get exposed through URL params in API requests"
}

GHSA-XWPR-8R3X-2877

Vulnerability from github – Published: 2025-08-28 15:30 – Updated: 2025-09-08 18:31
VLAI
Details

QuickCMS sends password and login via GET Request. This allows a local attacker with access to the victim's browser history to obtain the necessary credentials to log in as the user.

The vendor was notified early about this vulnerability, but didn't respond with the details of vulnerability or vulnerable version range. Only version 6.8 was tested and confirmed as vulnerable, other versions were not tested and might also be vulnerable.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-54542"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-598"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-28T11:15:32Z",
    "severity": "MODERATE"
  },
  "details": "QuickCMS sends password and login via GET Request. This allows a\u00a0local attacker with access to the victim\u0027s browser history to obtain the necessary credentials to log in as the user.\n\nThe vendor was notified early about this vulnerability, but didn\u0027t respond with the details of vulnerability or vulnerable version range. Only version 6.8 was tested and confirmed as vulnerable, other versions were not tested and might also be vulnerable.",
  "id": "GHSA-xwpr-8r3x-2877",
  "modified": "2025-09-08T18:31:27Z",
  "published": "2025-08-28T15:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54542"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/posts/2025/08/CVE-2025-54540"
    },
    {
      "type": "WEB",
      "url": "https://opensolution.org"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

Mitigation
Implementation

When sending sensitive information, only include it in the request body or request headers instead of the query string. This may require avoiding use of GET requests.

No CAPEC attack patterns related to this CWE.