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.

147 vulnerabilities reference this CWE, most recent first.

GHSA-9PG3-25FQ-P6CC

Vulnerability from github – Published: 2026-06-10 22:13 – Updated: 2026-06-10 22:13
VLAI
Summary
nebula-mesh: Newly-minted operator API key exposed in redirect URL (Referer, history, proxy logs)
Details

internal/web/operators.go:251 — after handleOperatorCreateAPIKey mints a fresh 32-byte bearer token, the redirect points the operator's browser at:

/ui/operators/<id>?new_key=<raw-token>&key_name=<name>

The raw API key ends up: - in the browser's URL history - in the Referer header on every cross-origin asset the detail page loads (any third-party SVG/CSS/JS resource the layout pulls in) - in any reverse-proxy or load-balancer access log on the path (nginx default combined log captures the query string) - in any structured log sink the operator's local browser-history backup tool ships out

Authorization: Bearer <token> headers go through the same hops without these problems because access logs typically don't capture request headers and the browser doesn't replay headers cross-origin.

Same handler also appends name (r.FormValue("name")) to the query string without url.QueryEscape, so an & in the operator-supplied key name corrupts query parsing and a \r\n in older proxies could split response headers.

Affected

All released versions up to v0.3.1.

Reproducer

As admin, create an API key via /ui/operators/<id>/api-keys (form POST). The 303 Location header carries the raw token in the query string. Open browser DevTools → Network → response headers; or check the reverse-proxy access log; or check the operator-detail page's Referer-emitting fetches.

Suggested fix

Stash the raw key in a one-shot server-side flash storage (e.g., a row in operator_sessions keyed by session token, with a one_shot_token column and consumed_at) or in a short-lived signed cookie. Render the key once inline on the detail page after the redirect, and clear the storage on render. Pattern mirrors the recovery-codes display in the TOTP flow.

If the flash-storage refactor is too invasive, the minimal fix is to render the key inline via a POST200 OK with HTML (no redirect), losing the post-redirect-get idiom but eliminating the URL exposure.

Also fix name query encoding with url.QueryEscape regardless of which fix shape lands.

CVSS estimate

AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N — 5.5 (medium). AV:L because realistic exploit requires log-read access on shared infrastructure (proxy, CDN, browser-history backup) the operator's session touches.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.3.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/juev/nebula-mesh"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47768"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116",
      "CWE-532",
      "CWE-598"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-10T22:13:45Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "`internal/web/operators.go:251` \u2014 after `handleOperatorCreateAPIKey` mints a fresh 32-byte bearer token, the redirect points the operator\u0027s browser at:\n\n    /ui/operators/\u003cid\u003e?new_key=\u003craw-token\u003e\u0026key_name=\u003cname\u003e\n\nThe raw API key ends up:\n- in the browser\u0027s URL history\n- in the `Referer` header on every cross-origin asset the detail page loads (any third-party SVG/CSS/JS resource the layout pulls in)\n- in any reverse-proxy or load-balancer access log on the path (nginx default `combined` log captures the query string)\n- in any structured log sink the operator\u0027s local browser-history backup tool ships out\n\n`Authorization: Bearer \u003ctoken\u003e` headers go through the same hops without these problems because access logs typically don\u0027t capture request headers and the browser doesn\u0027t replay headers cross-origin.\n\nSame handler also appends `name` (`r.FormValue(\"name\")`) to the query string without `url.QueryEscape`, so an `\u0026` in the operator-supplied key name corrupts query parsing and a `\\r\\n` in older proxies could split response headers.\n\n## Affected\nAll released versions up to v0.3.1.\n\n## Reproducer\nAs admin, create an API key via `/ui/operators/\u003cid\u003e/api-keys` (form POST). The 303 Location header carries the raw token in the query string. Open browser DevTools \u2192 Network \u2192 response headers; or check the reverse-proxy access log; or check the operator-detail page\u0027s `Referer`-emitting fetches.\n\n## Suggested fix\nStash the raw key in a one-shot server-side flash storage (e.g., a row in `operator_sessions` keyed by session token, with a `one_shot_token` column and `consumed_at`) or in a short-lived signed cookie. Render the key once inline on the detail page after the redirect, and clear the storage on render. Pattern mirrors the recovery-codes display in the TOTP flow.\n\nIf the flash-storage refactor is too invasive, the minimal fix is to render the key inline via a `POST` \u2192 `200 OK with HTML` (no redirect), losing the post-redirect-get idiom but eliminating the URL exposure.\n\nAlso fix `name` query encoding with `url.QueryEscape` regardless of which fix shape lands.\n\n## CVSS estimate\nAV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N \u2014 5.5 (medium). AV:L because realistic exploit requires log-read access on shared infrastructure (proxy, CDN, browser-history backup) the operator\u0027s session touches.",
  "id": "GHSA-9pg3-25fq-p6cc",
  "modified": "2026-06-10T22:13:45Z",
  "published": "2026-06-10T22:13:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/juev/nebula-mesh/security/advisories/GHSA-9pg3-25fq-p6cc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/juev/nebula-mesh"
    }
  ],
  "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"
    }
  ],
  "summary": "nebula-mesh: Newly-minted operator API key exposed in redirect URL (Referer, history, proxy logs)"
}

GHSA-9VC3-VM42-FJHM

Vulnerability from github – Published: 2025-04-25 15:31 – Updated: 2025-04-25 17:06
VLAI
Summary
Moodle's mod_data edit/delete pages pass CSRF token in GET parameter
Details

A security vulnerability was found in Moodle where confidential information that prevents cross-site request forgery (CSRF) attacks was shared publicly through the site's URL. This vulnerability occurred specifically on two types of pages within the mod_data module: edit and delete pages.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 4.1.18"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.3.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.3.0-beta"
            },
            {
              "fixed": "4.3.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.4.0-beta"
            },
            {
              "fixed": "4.4.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.5.0-beta"
            },
            {
              "fixed": "4.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-3637"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-598"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-25T17:06:27Z",
    "nvd_published_at": "2025-04-25T15:15:37Z",
    "severity": "LOW"
  },
  "details": "A security vulnerability was found in Moodle where confidential information that prevents cross-site request forgery (CSRF) attacks was shared publicly through the site\u0027s URL. This vulnerability occurred specifically on two types of pages within the mod_data module: edit and delete pages.",
  "id": "GHSA-9vc3-vm42-fjhm",
  "modified": "2025-04-25T17:06:27Z",
  "published": "2025-04-25T15:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3637"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moodle/moodle/commit/052007b7324ef24aebe36a876ffa4fa97fac4f81"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-3637"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2359727"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moodle/moodle"
    },
    {
      "type": "WEB",
      "url": "https://moodle.org/mod/forum/discuss.php?d=467599"
    },
    {
      "type": "WEB",
      "url": "http://git.moodle.org/gw?p=moodle.git\u0026a=search\u0026h=HEAD\u0026st=commit\u0026s=MDL-65356"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Moodle\u0027s mod_data edit/delete pages pass CSRF token in GET parameter"
}

GHSA-CPMJ-JRPC-57WC

Vulnerability from github – Published: 2026-01-12 06:30 – Updated: 2026-01-14 18:31
VLAI
Details

Information Exposure Through Query Strings in GET Request vulnerability in Broadcom DX NetOps Spectrum on Windows, Linux allows Session Hijacking.This issue affects DX NetOps Spectrum: 24.3.8 and earlier.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-69270"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-598"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-12T05:16:10Z",
    "severity": "LOW"
  },
  "details": "Information Exposure Through Query Strings in GET Request vulnerability in Broadcom DX NetOps Spectrum on Windows, Linux allows Session Hijacking.This issue affects DX NetOps Spectrum: 24.3.8 and earlier.",
  "id": "GHSA-cpmj-jrpc-57wc",
  "modified": "2026-01-14T18:31:18Z",
  "published": "2026-01-12T06:30:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69270"
    },
    {
      "type": "WEB",
      "url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36756"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L/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"
    }
  ]
}

GHSA-CX27-6J8X-H4H6

Vulnerability from github – Published: 2026-07-17 03:31 – Updated: 2026-07-17 03:31
VLAI
Details

The Grav API plugin (getgrav/grav-plugin-api) before 1.0.0-rc.16 accepts JWT access tokens through the ?token= URL query parameter on every API route (JwtAuthenticator::extractBearerToken fallback). Because tokens are embedded in URLs, they are logged verbatim in web server access logs, leaked via the Referer header, stored in browser history, and captured by upstream proxy and CDN logs, exposing valid admin access tokens. A leaked token grants unauthorized API access, including reading configuration and user data, creating admin accounts, modifying system settings, and deleting pages.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-62386"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-598"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-17T02:18:11Z",
    "severity": "HIGH"
  },
  "details": "The Grav API plugin (getgrav/grav-plugin-api) before 1.0.0-rc.16 accepts JWT access tokens through the ?token= URL query parameter on every API route (JwtAuthenticator::extractBearerToken fallback). Because tokens are embedded in URLs, they are logged verbatim in web server access logs, leaked via the Referer header, stored in browser history, and captured by upstream proxy and CDN logs, exposing valid admin access tokens. A leaked token grants unauthorized API access, including reading configuration and user data, creating admin accounts, modifying system settings, and deleting pages.",
  "id": "GHSA-cx27-6j8x-h4h6",
  "modified": "2026-07-17T03:31:24Z",
  "published": "2026-07-17T03:31:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav/security/advisories/GHSA-4hpj-wmpw-ghwq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62386"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/grav-rc-16-authentication-bypass-via-token-url-parameter"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/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"
    }
  ]
}

GHSA-F2Q6-8FX7-GJF8

Vulnerability from github – Published: 2026-05-29 12:31 – Updated: 2026-05-29 12:31
VLAI
Details

A flaw was found in the Quay config-tool's GitLab OAuth validator. This vulnerability causes sensitive credentials, specifically client_id and client_secret, to be transmitted as plaintext in URL query parameters during POST requests to the GitLab endpoint. This insecure transmission can lead to the disclosure of these credentials in various system logs, such as server access logs, reverse proxy logs, and other monitoring systems. An attacker with access to these logs could potentially obtain these credentials, leading to unauthorized information disclosure.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-10078"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-598"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-29T11:16:16Z",
    "severity": "LOW"
  },
  "details": "A flaw was found in the Quay config-tool\u0027s GitLab OAuth validator. This vulnerability causes sensitive credentials, specifically client_id and client_secret, to be transmitted as plaintext in URL query parameters during POST requests to the GitLab endpoint. This insecure transmission can lead to the disclosure of these credentials in various system logs, such as server access logs, reverse proxy logs, and other monitoring systems. An attacker with access to these logs could potentially obtain these credentials, leading to unauthorized information disclosure.",
  "id": "GHSA-f2q6-8fx7-gjf8",
  "modified": "2026-05-29T12:31:25Z",
  "published": "2026-05-29T12:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10078"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-10078"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2483168"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F347-P5G7-4GG7

Vulnerability from github – Published: 2023-11-27 15:30 – Updated: 2023-11-27 15:30
VLAI
Details

Sensitive data exposure in Webconf in Tribe29 Checkmk Appliance before 1.6.8 allows local attacker to retrieve passwords via reading log files.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-6287"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-532",
      "CWE-598"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-27T14:15:08Z",
    "severity": "LOW"
  },
  "details": "Sensitive data exposure in Webconf in Tribe29 Checkmk Appliance before 1.6.8 allows local attacker to retrieve passwords via reading log files.",
  "id": "GHSA-f347-p5g7-4gg7",
  "modified": "2023-11-27T15:30:56Z",
  "published": "2023-11-27T15:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6287"
    },
    {
      "type": "WEB",
      "url": "https://checkmk.com/werk/9554"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FFQ7-HH2J-R24P

Vulnerability from github – Published: 2026-07-14 19:31 – Updated: 2026-07-14 19:31
VLAI
Summary
Auth0 Symfony SDK Accepted Bearer Tokens via URL Query Parameter
Details

Description

Applications built with the Auth0 Symphony SDK, using the Authorizer security authenticator to protect HTTP routes may accept OAuth 2.0 bearer access tokens provided through a URL query parameter, in addition to the standard Authorization header, which may increase the risk of access token exposure and replay against protected API endpoints.

Resolution

Upgrade auth0/symfony to version 5.9.0 or greater.

Acknowledgement

Okta would like to thank Alex Yeara for their discovery.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.8.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "auth0/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-BETA0"
            },
            {
              "fixed": "5.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50157"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-598",
      "CWE-200"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-14T19:31:23Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Description\nApplications built with the Auth0 Symphony SDK, using the Authorizer security authenticator to protect HTTP routes may accept OAuth 2.0 bearer access tokens provided through a URL query parameter, in addition to the standard Authorization header, which may increase the risk of access token exposure and replay against protected API endpoints.\n\n### Resolution\nUpgrade auth0/symfony to version 5.9.0 or greater.\n\n### Acknowledgement\nOkta would like to thank Alex Yeara for their discovery.",
  "id": "GHSA-ffq7-hh2j-r24p",
  "modified": "2026-07-14T19:31:23Z",
  "published": "2026-07-14T19:31:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/auth0/symfony/security/advisories/GHSA-ffq7-hh2j-r24p"
    },
    {
      "type": "WEB",
      "url": "https://github.com/auth0/symfony/commit/172d1d3e0b9d1e93610d786118389a811179bc8a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/auth0/symfony/commit/bd1851b14ae15e99cbe87c96496cf25da025288a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/auth0/symfony"
    },
    {
      "type": "WEB",
      "url": "https://github.com/auth0/symfony/releases/tag/5.9.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Auth0 Symfony SDK Accepted Bearer Tokens via URL Query Parameter"
}

GHSA-FX5H-WV8R-5J9Q

Vulnerability from github – Published: 2026-07-08 15:32 – Updated: 2026-07-08 15:32
VLAI
Details

Grav API plugin before v1.0.0-rc.16 accepts JWT tokens via the ?token= URL query parameter and responds with Access-Control-Allow-Origin: *, allowing unauthenticated attackers to make fully authenticated cross-origin API requests from any malicious website. Attackers who obtain a leaked JWT token from access logs, proxy logs, browser history, or Referrer headers can create persistent backdoor super-admin accounts and exfiltrate sensitive configuration and user data.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-58656"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-598"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-08T14:17:20Z",
    "severity": "HIGH"
  },
  "details": "Grav API plugin before v1.0.0-rc.16 accepts JWT tokens via the ?token= URL query parameter and responds with Access-Control-Allow-Origin: *, allowing unauthenticated attackers to make fully authenticated cross-origin API requests from any malicious website. Attackers who obtain a leaked JWT token from access logs, proxy logs, browser history, or Referrer headers can create persistent backdoor super-admin accounts and exfiltrate sensitive configuration and user data.",
  "id": "GHSA-fx5h-wv8r-5j9q",
  "modified": "2026-07-08T15:32:01Z",
  "published": "2026-07-08T15:32:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav/security/advisories/GHSA-hqm9-5xxw-4qxp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58656"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/grav-api-plugin-cross-origin-admin-account-takeover-via-cors-wildcard-and-jwt-query-parameter"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/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"
    }
  ]
}

GHSA-G2QJ-PRGH-4G9R

Vulnerability from github – Published: 2026-04-01 23:36 – Updated: 2026-04-27 16:20
VLAI
Summary
Nhost Leaks Refresh Tokens via URL Query Parameter in OAuth Provider Callback
Details

Refresh Token Leaked via URL Query Parameter in OAuth Provider Callback

Summary

The auth service's OAuth provider callback flow places the refresh token directly into the redirect URL as a query parameter. Refresh tokens in URLs are logged in browser history, server access logs, HTTP Referer headers, and proxy/CDN logs.

Note that the refresh token is one-time use and all of these leak vectors are on owned infrastructure or services integrated by the application developer.

Affected Component

  • Repository: github.com/nhost/nhost
  • Service: services/auth
  • File: services/auth/go/controller/sign_in_provider_callback_get.go
  • Function: signinProviderProviderCallback (lines 257-261)

Root Cause

In sign_in_provider_callback_get.go:257-261, after successful OAuth sign-in, the refresh token is appended as a URL query parameter:

if session != nil {
    values := redirectTo.Query()
    values.Add("refreshToken", session.RefreshToken)
    redirectTo.RawQuery = values.Encode()
}

This results in a redirect like:

HTTP/1.1 302 Found
Location: https://myapp.com/callback?refreshToken=a1b2c3d4-e5f6-7890-abcd-ef1234567890

Proof of Concept

Step 1: Initiate OAuth login

GET /signin/provider/github?redirectTo=https://myapp.com/callback

Step 2: Complete OAuth flow with provider

Step 3: Auth service redirects with token in URL

HTTP/1.1 302 Found
Location: https://myapp.com/callback?refreshToken=a1b2c3d4-e5f6-7890-abcd-ef1234567890

Step 4: Token is now visible in owned infrastructure and services:

Browser History:

# User's browser history now contains the refresh token

HTTP Referer Header:

# If the callback page loads ANY external resource (image, script, etc.):
GET /resource.js HTTP/1.1
Host: cdn.example.com
Referer: https://myapp.com/callback?refreshToken=a1b2c3d4-e5f6-...
# Note: modern browsers default to strict-origin-when-cross-origin policy,
# which strips query parameters from cross-origin Referer headers.
# Additionally, the Referer is only sent to services integrated by the
# application developer (analytics, CDNs, etc.), not arbitrary third parties.

Server Access Logs:

# Reverse proxy, CDN, or load balancer logs on owned infrastructure:
2026-03-08 12:00:00 GET /callback?refreshToken=a1b2c3d4-e5f6-... 200

Step 5: Attacker uses stolen refresh token

# Exchange stolen refresh token for new access token
curl -X POST https://auth.nhost.run/v1/token \
  -H 'Content-Type: application/json' \
  -d '{"refreshToken": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"}'

# Note: refresh tokens are one-time use, so this only works if the
# legitimate client has not already consumed the token and if the attacker has
# compromised your infrastructure to get access to this information

Impact

  1. Session Hijacking: Anyone who obtains the token before it is consumed by the legitimate client can generate new access tokens, though the refresh token is one-time use and cannot be reused after consumption.

  2. Leak Vectors: URL query parameters are visible in owned infrastructure and integrated services:

  3. Browser history (local access)
  4. HTTP Referer headers (mitigated by modern browser default referrer policies; only sent to developer-integrated services)
  5. Server access logs (owned infrastructure)
  6. Proxy/CDN/WAF logs (owned infrastructure)

  7. Affects All OAuth Providers: Every OAuth provider flow (GitHub, Google, Apple, etc.) goes through the same callback handler.

Fix

Implemented PKCE (Proof Key for Code Exchange) for the OAuth flow. With PKCE, the authorization code cannot be exchanged without the code_verifier that only the original client possesses, preventing token misuse even if the URL is logged.

See: https://docs.nhost.io/products/auth/pkce/

Resources

  • OWASP: Session Management - Token Transport: "Session tokens should not be transported in the URL"
  • RFC 6749 Section 10.3: "Access tokens and refresh tokens MUST NOT be included in the redirect URI"
  • CWE-598: Use of GET Request Method With Sensitive Query Strings
  • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nhost/nhost"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260330133707-294954e0fc3a"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34969"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-598"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-01T23:36:10Z",
    "nvd_published_at": "2026-04-06T16:16:38Z",
    "severity": "LOW"
  },
  "details": "# Refresh Token Leaked via URL Query Parameter in OAuth Provider Callback\n\n## Summary\n\nThe auth service\u0027s OAuth provider callback flow places the refresh token directly into the redirect URL as a query parameter. Refresh tokens in URLs are logged in browser history, server access logs, HTTP Referer headers, and proxy/CDN logs.\n\nNote that the refresh token is one-time use and all of these leak vectors are on owned infrastructure or services integrated by the application developer.\n\n## Affected Component\n\n- **Repository**: `github.com/nhost/nhost`\n- **Service**: `services/auth`\n- **File**: `services/auth/go/controller/sign_in_provider_callback_get.go`\n- **Function**: `signinProviderProviderCallback` (lines 257-261)\n\n## Root Cause\n\nIn `sign_in_provider_callback_get.go:257-261`, after successful OAuth sign-in, the refresh token is appended as a URL query parameter:\n\n```go\nif session != nil {\n    values := redirectTo.Query()\n    values.Add(\"refreshToken\", session.RefreshToken)\n    redirectTo.RawQuery = values.Encode()\n}\n```\n\nThis results in a redirect like:\n```\nHTTP/1.1 302 Found\nLocation: https://myapp.com/callback?refreshToken=a1b2c3d4-e5f6-7890-abcd-ef1234567890\n```\n\n## Proof of Concept\n\n### Step 1: Initiate OAuth login\n```\nGET /signin/provider/github?redirectTo=https://myapp.com/callback\n```\n\n### Step 2: Complete OAuth flow with provider\n\n### Step 3: Auth service redirects with token in URL\n```\nHTTP/1.1 302 Found\nLocation: https://myapp.com/callback?refreshToken=a1b2c3d4-e5f6-7890-abcd-ef1234567890\n```\n\n### Step 4: Token is now visible in owned infrastructure and services:\n\n**Browser History:**\n```\n# User\u0027s browser history now contains the refresh token\n```\n\n**HTTP Referer Header:**\n```\n# If the callback page loads ANY external resource (image, script, etc.):\nGET /resource.js HTTP/1.1\nHost: cdn.example.com\nReferer: https://myapp.com/callback?refreshToken=a1b2c3d4-e5f6-...\n# Note: modern browsers default to strict-origin-when-cross-origin policy,\n# which strips query parameters from cross-origin Referer headers.\n# Additionally, the Referer is only sent to services integrated by the\n# application developer (analytics, CDNs, etc.), not arbitrary third parties.\n```\n\n**Server Access Logs:**\n```\n# Reverse proxy, CDN, or load balancer logs on owned infrastructure:\n2026-03-08 12:00:00 GET /callback?refreshToken=a1b2c3d4-e5f6-... 200\n```\n\n### Step 5: Attacker uses stolen refresh token\n```bash\n# Exchange stolen refresh token for new access token\ncurl -X POST https://auth.nhost.run/v1/token \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"refreshToken\": \"a1b2c3d4-e5f6-7890-abcd-ef1234567890\"}\u0027\n\n# Note: refresh tokens are one-time use, so this only works if the\n# legitimate client has not already consumed the token and if the attacker has\n# compromised your infrastructure to get access to this information\n```\n\n## Impact\n\n1. **Session Hijacking**: Anyone who obtains the token before it is consumed by the legitimate client can generate new access tokens, though the refresh token is one-time use and cannot be reused after consumption.\n\n2. **Leak Vectors**: URL query parameters are visible in owned infrastructure and integrated services:\n   - Browser history (local access)\n   - HTTP Referer headers (mitigated by modern browser default referrer policies; only sent to developer-integrated services)\n   - Server access logs (owned infrastructure)\n   - Proxy/CDN/WAF logs (owned infrastructure)\n\n3. **Affects All OAuth Providers**: Every OAuth provider flow (GitHub, Google, Apple, etc.) goes through the same callback handler.\n\n## Fix\n\nImplemented PKCE (Proof Key for Code Exchange) for the OAuth flow. With PKCE, the authorization code cannot be exchanged without the `code_verifier` that only the original client possesses, preventing token misuse even if the URL is logged.\n\nSee: https://docs.nhost.io/products/auth/pkce/\n\n## Resources\n\n- OWASP: Session Management - Token Transport: \"Session tokens should not be transported in the URL\"\n- RFC 6749 Section 10.3: \"Access tokens and refresh tokens MUST NOT be included in the redirect URI\"\n- CWE-598: Use of GET Request Method With Sensitive Query Strings\n- CWE-200: Exposure of Sensitive Information to an Unauthorized Actor",
  "id": "GHSA-g2qj-prgh-4g9r",
  "modified": "2026-04-27T16:20:58Z",
  "published": "2026-04-01T23:36:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nhost/nhost/security/advisories/GHSA-g2qj-prgh-4g9r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34969"
    },
    {
      "type": "WEB",
      "url": "https://docs.nhost.io/products/auth/pkce"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nhost/nhost"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Nhost Leaks Refresh Tokens via URL Query Parameter in OAuth Provider Callback"
}

GHSA-GCVM-C75M-H4P4

Vulnerability from github – Published: 2026-04-09 18:31 – Updated: 2026-04-10 21:35
VLAI
Summary
Apache OpenMeetings Uses GET Request Method With Sensitive Query Strings
Details

Use of GET Request Method With Sensitive Query Strings vulnerability in Apache OpenMeetings.

The REST login endpoint uses HTTP GET method with username and password passed as query parameters. Please check references regarding possible impact

This issue affects Apache OpenMeetings: from 3.1.3 before 9.0.0.

Users are recommended to upgrade to version 9.0.0, which fixes the issue.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.openmeetings:openmeetings-parent"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1.3"
            },
            {
              "fixed": "9.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34020"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-598"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T21:24:43Z",
    "nvd_published_at": "2026-04-09T16:16:27Z",
    "severity": "HIGH"
  },
  "details": "Use of GET Request Method With Sensitive Query Strings vulnerability in Apache OpenMeetings.\n\nThe REST login endpoint uses HTTP GET method with username and password passed as query parameters.\u00a0Please check references regarding possible impact\n\n\nThis issue affects Apache OpenMeetings: from 3.1.3 before 9.0.0.\n\nUsers are recommended to upgrade to version 9.0.0, which fixes the issue.",
  "id": "GHSA-gcvm-c75m-h4p4",
  "modified": "2026-04-10T21:35:15Z",
  "published": "2026-04-09T18:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34020"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/openmeetings"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/2h3h9do5tp17xldr0nps1yjmkx4vs3db"
    },
    {
      "type": "WEB",
      "url": "https://owasp.org/www-community/vulnerabilities/Information_exposure_through_query_strings_in_url"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/04/09/12"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache OpenMeetings Uses GET Request Method With Sensitive Query Strings "
}

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.