CWE-598
AllowedUse 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.
139 vulnerabilities reference this CWE, most recent first.
GHSA-4QQ5-MXXX-M6GG
Vulnerability from github – Published: 2023-11-16 21:30 – Updated: 2024-03-01 21:26An attacker is able to arbitrarily create an account in MLflow bypassing any authentication requirement.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "mlflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.8.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-6014"
],
"database_specific": {
"cwe_ids": [
"CWE-598"
],
"github_reviewed": true,
"github_reviewed_at": "2023-11-17T22:49:27Z",
"nvd_published_at": "2023-11-16T21:15:09Z",
"severity": "CRITICAL"
},
"details": "An attacker is able to arbitrarily create an account in MLflow bypassing any authentication requirement.",
"id": "GHSA-4qq5-mxxx-m6gg",
"modified": "2024-03-01T21:26:17Z",
"published": "2023-11-16T21:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6014"
},
{
"type": "WEB",
"url": "https://github.com/mlflow/mlflow/issues/9669"
},
{
"type": "WEB",
"url": "https://github.com/mlflow/mlflow/pull/9700"
},
{
"type": "WEB",
"url": "https://github.com/mlflow/mlflow/commit/32de2154ef9f946160e5dc01a4d8a449dd0bd259"
},
{
"type": "PACKAGE",
"url": "https://github.com/mlflow/mlflow"
},
{
"type": "WEB",
"url": "https://github.com/mlflow/mlflow/releases/tag/v2.8.0"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/3e64df69-ddc2-463e-9809-d07c24dc1de4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "MLflow authentication requirement bypass can allow a user to arbitrarily create an account"
}
GHSA-4RH7-JWG9-M28M
Vulnerability from github – Published: 2026-04-01 21:12 – Updated: 2026-04-01 21:12Summary
Refresh tokens are accepted as URL query parameters in the keyserver and telemetry server routes.
Affected Code
# openssl_encrypt_server/modules/keyserver/routes.py:214-215
# openssl_encrypt_server/modules/telemetry/routes.py:90-91
async def refresh_token(
request: Request,
refresh_token: str = Query(..., description="Refresh token")
):
Impact
Tokens in URL query parameters are exposed in: - Server access logs - Proxy/CDN logs - Browser history - HTTP Referer headers - Network monitoring tools
This creates significant token leakage risk.
Recommended Fix
- Accept refresh tokens in the request body (POST) instead of query parameters
- Use
Body(...)instead ofQuery(...)
Fix
Fixed in commit 4b2adb0 on branch releases/1.4.x — moved refresh token from Query parameter to POST body via RefreshRequest Pydantic model.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "openssl-encrypt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-598"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-01T21:12:19Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nRefresh tokens are accepted as URL query parameters in the keyserver and telemetry server routes.\n\n### Affected Code\n\n```python\n# openssl_encrypt_server/modules/keyserver/routes.py:214-215\n# openssl_encrypt_server/modules/telemetry/routes.py:90-91\nasync def refresh_token(\n request: Request,\n refresh_token: str = Query(..., description=\"Refresh token\")\n):\n```\n\n### Impact\n\nTokens in URL query parameters are exposed in:\n- Server access logs\n- Proxy/CDN logs\n- Browser history\n- HTTP Referer headers\n- Network monitoring tools\n\nThis creates significant token leakage risk.\n\n### Recommended Fix\n\n- Accept refresh tokens in the request body (POST) instead of query parameters\n- Use `Body(...)` instead of `Query(...)`\n\n### Fix\n\nFixed in commit `4b2adb0` on branch `releases/1.4.x` \u2014 moved refresh token from Query parameter to POST body via RefreshRequest Pydantic model.",
"id": "GHSA-4rh7-jwg9-m28m",
"modified": "2026-04-01T21:12:19Z",
"published": "2026-04-01T21:12:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-4rh7-jwg9-m28m"
},
{
"type": "WEB",
"url": "https://github.com/jahlives/openssl_encrypt/commit/4b2adb05cde8a7ee03cdd271755da3b377c68011"
},
{
"type": "PACKAGE",
"url": "https://github.com/jahlives/openssl_encrypt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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:U",
"type": "CVSS_V4"
}
],
"summary": "openssl-encrypt accepts refresh tokens as URL query parameters causing token leakage"
}
GHSA-569Q-P62W-X28H
Vulnerability from github – Published: 2025-02-18 18:33 – Updated: 2025-02-19 21:31Webkul QloApps v1.6.1 exposes authentication tokens in URLs during redirection. When users access the admin panel or other protected areas, the application appends sensitive authentication tokens directly to the URL.
{
"affected": [],
"aliases": [
"CVE-2025-26058"
],
"database_specific": {
"cwe_ids": [
"CWE-598"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-18T18:15:35Z",
"severity": "MODERATE"
},
"details": "Webkul QloApps v1.6.1 exposes authentication tokens in URLs during redirection. When users access the admin panel or other protected areas, the application appends sensitive authentication tokens directly to the URL.",
"id": "GHSA-569q-p62w-x28h",
"modified": "2025-02-19T21:31:37Z",
"published": "2025-02-18T18:33:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26058"
},
{
"type": "WEB",
"url": "https://github.com/mano257200/QloApps-VUL"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-5V68-527Q-PRQV
Vulnerability from github – Published: 2026-05-27 09:31 – Updated: 2026-05-27 09:31A use of get request method with sensitive query strings vulnerability in volume encryption of Synology Storage Manager package before 1.0.1-1100 allows local attackers to obtain sensitive information.
{
"affected": [],
"aliases": [
"CVE-2026-2237"
],
"database_specific": {
"cwe_ids": [
"CWE-598"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T09:16:27Z",
"severity": "MODERATE"
},
"details": "A use of get request method with sensitive query strings vulnerability in volume encryption of Synology Storage Manager package before 1.0.1-1100 allows local attackers to obtain sensitive information.",
"id": "GHSA-5v68-527q-prqv",
"modified": "2026-05-27T09:31:16Z",
"published": "2026-05-27T09:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2237"
},
{
"type": "WEB",
"url": "https://www.synology.com/en-global/security/advisory/Synology_SA_26_01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5W8W-26CH-V5CW
Vulnerability from github – Published: 2026-05-05 19:08 – Updated: 2026-05-13 14:19Summary
plugin/MobileManager/oauth2.php completes an OAuth login by sending an HTTP 302 Location: oauth2Success.php?user=<email>&pass=<HASH> where <HASH> is the victim's stored password hash (md5(hash("whirlpool", sha1(password)))) read directly from the users table. AVideo's own login endpoint (objects/login.json.php) accepts an encodedPass=1 flag that bypasses hashing and performs a direct string comparison between the supplied value and the stored hash. Anyone who captures the redirect URL — via server logs, referrer leakage, or browser history — therefore obtains a credential equivalent to the plaintext password and can fully take over the account, including admin accounts.
Details
Sink: hash inlined in a GET redirect
plugin/MobileManager/oauth2.php:98-102:
$pass = rand();
$users_id = User::createUserIfNotExists($user, $pass, $name, $email, $photoURL);
$adapter->disconnect();
$userObject = new User($users_id);
header("Location: oauth2Success.php?user=" . $userObject->getUser() . "&pass=" . $userObject->getPassword());
$userObject->getPassword() returns the raw database column (objects/user.php:159-162):
public function getPassword()
{
return strip_tags($this->password);
}
The returned value is the stored password hash for the account (existing or freshly-created). It is transported to the browser as a query-string parameter in the Location: header, so it is written to:
- Web-server access logs (
combined/mainlog formats record the full request line including query string). - Upstream proxy / CDN / WAF logs.
- Any error monitoring / APM that captures request URLs (Sentry, Datadog, New Relic defaults).
- The victim's browser history (persistent local artifact).
- The
Refererheader on subsequent navigation from the renderedoauth2Success.phppage if the page or its assets load any external origin and the browser'sReferrer-Policyis not strict.
Hash equals plaintext for login
objects/login.json.php:182-209:
if (!empty($_GET['user'])) {
$_POST['user'] = $_GET['user'];
}
if (!empty($_GET['pass'])) {
$_POST['pass'] = $_GET['pass'];
}
if (!empty($_GET['encodedPass'])) {
$_POST['encodedPass'] = $_GET['encodedPass'];
}
...
$user = new User(0, $_POST['user'], $_POST['pass']);
...
$resp = $user->login(false, @$_POST['encodedPass']);
objects/user.php:1272-1279 passes $encodedPass to find():
if (strtolower($encodedPass) === 'false') {
$encodedPass = false;
}
...
$user = $this->find($this->user, $this->password, true, $encodedPass);
objects/user.php:1785-1794:
if ($pass !== false) {
if (!encryptPasswordVerify($pass, $result['password'], $encodedPass)) {
...
return false;
}
}
objects/functions.php:2312-2331:
function encryptPasswordVerify(#[\SensitiveParameter] $password, $hash, $encodedPass = false)
{
global $advancedCustom, $global;
if (!$encodedPass || $encodedPass === 'false') {
$passwordSalted = encryptPassword($password);
$passwordUnSalted = encryptPassword($password, true);
} else {
$passwordSalted = $password; // <- direct use, no hashing
$passwordUnSalted = $password;
}
$isValid = $passwordSalted === $hash || $passwordUnSalted === $hash;
...
}
When encodedPass is truthy, the supplied value is compared as-is against the stored hash. The captured redirect parameter pass=<HASH> is therefore a valid login credential when replayed with encodedPass=1.
Compounding factors
- The redirect is a raw
Location:(GET), not a POST — the secret is placed in a URL which is by definition non-confidential transport. - No CSRF token, no
stateparameter tied to the session, and no single-use token is used on/plugin/MobileManager/oauth2.php. login.json.phpdoes not require a CSRF token or captcha on the first attempt (checkLoginAttempts()atobjects/user.php:1282only rate-limits after failures, and the attacker succeeds on the first try).- By contrast, the non-plugin flow in
objects/login.json.php:144-145already sets session state server-side ($userObject->login(true)), demonstrating the project already has a safer pattern available.
PoC
Prerequisites: MobileManager plugin enabled and at least one supported login provider (e.g. LoginGoogle) configured with valid keys — both are common production settings for this product.
- Victim initiates the mobile OAuth flow:
GET /plugin/MobileManager/oauth2.php?type=Google
- After the victim authorizes at the provider, the server sends:
HTTP/1.1 302 Found
Location: oauth2Success.php?user=victim%40example.com&pass=9d7ab4...stored-hash...
This request-line — including the password hash — is written to the web server's access log (default combined format) and to any upstream proxy/CDN log. It also appears in the victim's browser history.
-
Attacker obtains
<HASH>from any of those channels. -
Attacker logs in as the victim without knowing the plaintext password:
curl -i -c cookies.txt \
'https://target.example.com/objects/login.json.php?user=victim@example.com&pass=<HASH>&encodedPass=1'
Expected response: 200 OK with JSON containing id, user, PHPSESSID, isAdmin, email, and a Set-Cookie: PHPSESSID=... that grants full account access. The attacker can now browse, upload, modify the victim's channel, or — if the victim is an admin — access /mvideos and all admin endpoints.
Impact
- Full account takeover of any user who has ever logged in through the MobileManager OAuth endpoint.
- If the victim is an administrator, the attacker gains administrative control of the AVideo instance (user management, plugin config, site-wide content).
- The exposed hash works indefinitely: it remains valid for as long as the victim does not change their password, so a one-time log/history/referrer capture yields a persistent credential.
- Passes silently — from the application's perspective, the attacker is just a legitimate login with
encodedPass=1(a flag the product itself uses for mobile-app "remember me" flows).
Recommended Fix
- Never place the password hash (or any credential-equivalent material) in a URL. In
plugin/MobileManager/oauth2.php, mirror whatobjects/login.json.php:143-146already does for the web flow — establish the session server-side and redirect to a URL with no credentials:
php
$userObject = new User(0, $user, $pass);
$userObject->login(true); // server-side session
header("Location: oauth2Success.php");
-
Additionally, remove or hard-restrict the
encodedPassbranch inobjects/functions.php:2319-2329. If a "hash-equivalent" credential must exist for the mobile app, replace it with a short-lived, single-use, server-issued bearer token bound to the session, rather than the persistent database hash. -
Add a
stateparameter and CSRF protection on/plugin/MobileManager/oauth2.phpso the redirect cannot be initiated from a third-party origin. -
For defense-in-depth, strip query strings containing
pass=from access-log formats and ensureoauth2Success.phpsetsReferrer-Policy: no-referrerwhile it is being deprecated.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "wwbn/avideo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "29.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-43875"
],
"database_specific": {
"cwe_ids": [
"CWE-598"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-05T19:08:45Z",
"nvd_published_at": "2026-05-11T22:22:11Z",
"severity": "MODERATE"
},
"details": "## Summary\n\n`plugin/MobileManager/oauth2.php` completes an OAuth login by sending an HTTP 302 `Location: oauth2Success.php?user=\u003cemail\u003e\u0026pass=\u003cHASH\u003e` where `\u003cHASH\u003e` is the victim\u0027s stored password hash (`md5(hash(\"whirlpool\", sha1(password)))`) read directly from the `users` table. AVideo\u0027s own login endpoint (`objects/login.json.php`) accepts an `encodedPass=1` flag that bypasses hashing and performs a direct string comparison between the supplied value and the stored hash. Anyone who captures the redirect URL \u2014 via server logs, referrer leakage, or browser history \u2014 therefore obtains a credential equivalent to the plaintext password and can fully take over the account, including admin accounts.\n\n## Details\n\n### Sink: hash inlined in a GET redirect\n\n`plugin/MobileManager/oauth2.php:98-102`:\n\n```php\n$pass = rand();\n$users_id = User::createUserIfNotExists($user, $pass, $name, $email, $photoURL);\n$adapter-\u003edisconnect();\n$userObject = new User($users_id);\nheader(\"Location: oauth2Success.php?user=\" . $userObject-\u003egetUser() . \"\u0026pass=\" . $userObject-\u003egetPassword());\n```\n\n`$userObject-\u003egetPassword()` returns the raw database column (`objects/user.php:159-162`):\n\n```php\npublic function getPassword()\n{\n return strip_tags($this-\u003epassword);\n}\n```\n\nThe returned value is the stored password hash for the account (existing or freshly-created). It is transported to the browser as a query-string parameter in the `Location:` header, so it is written to:\n\n* Web-server access logs (`combined` / `main` log formats record the full request line including query string).\n* Upstream proxy / CDN / WAF logs.\n* Any error monitoring / APM that captures request URLs (Sentry, Datadog, New Relic defaults).\n* The victim\u0027s browser history (persistent local artifact).\n* The `Referer` header on subsequent navigation from the rendered `oauth2Success.php` page if the page or its assets load any external origin and the browser\u0027s `Referrer-Policy` is not strict.\n\n### Hash equals plaintext for login\n\n`objects/login.json.php:182-209`:\n\n```php\nif (!empty($_GET[\u0027user\u0027])) {\n $_POST[\u0027user\u0027] = $_GET[\u0027user\u0027];\n}\nif (!empty($_GET[\u0027pass\u0027])) {\n $_POST[\u0027pass\u0027] = $_GET[\u0027pass\u0027];\n}\nif (!empty($_GET[\u0027encodedPass\u0027])) {\n $_POST[\u0027encodedPass\u0027] = $_GET[\u0027encodedPass\u0027];\n}\n...\n$user = new User(0, $_POST[\u0027user\u0027], $_POST[\u0027pass\u0027]);\n...\n$resp = $user-\u003elogin(false, @$_POST[\u0027encodedPass\u0027]);\n```\n\n`objects/user.php:1272-1279` passes `$encodedPass` to `find()`:\n\n```php\nif (strtolower($encodedPass) === \u0027false\u0027) {\n $encodedPass = false;\n}\n...\n$user = $this-\u003efind($this-\u003euser, $this-\u003epassword, true, $encodedPass);\n```\n\n`objects/user.php:1785-1794`:\n\n```php\nif ($pass !== false) {\n if (!encryptPasswordVerify($pass, $result[\u0027password\u0027], $encodedPass)) {\n ...\n return false;\n }\n}\n```\n\n`objects/functions.php:2312-2331`:\n\n```php\nfunction encryptPasswordVerify(#[\\SensitiveParameter] $password, $hash, $encodedPass = false)\n{\n global $advancedCustom, $global;\n if (!$encodedPass || $encodedPass === \u0027false\u0027) {\n $passwordSalted = encryptPassword($password);\n $passwordUnSalted = encryptPassword($password, true);\n } else {\n $passwordSalted = $password; // \u003c- direct use, no hashing\n $passwordUnSalted = $password;\n }\n $isValid = $passwordSalted === $hash || $passwordUnSalted === $hash;\n ...\n}\n```\n\nWhen `encodedPass` is truthy, the supplied value is compared as-is against the stored hash. The captured redirect parameter `pass=\u003cHASH\u003e` is therefore a valid login credential when replayed with `encodedPass=1`.\n\n### Compounding factors\n\n* The redirect is a raw `Location:` (GET), not a POST \u2014 the secret is placed in a URL which is by definition non-confidential transport.\n* No CSRF token, no `state` parameter tied to the session, and no single-use token is used on `/plugin/MobileManager/oauth2.php`.\n* `login.json.php` does not require a CSRF token or captcha on the first attempt (`checkLoginAttempts()` at `objects/user.php:1282` only rate-limits after failures, and the attacker succeeds on the first try).\n* By contrast, the non-plugin flow in `objects/login.json.php:144-145` already sets session state server-side (`$userObject-\u003elogin(true)`), demonstrating the project already has a safer pattern available.\n\n## PoC\n\nPrerequisites: `MobileManager` plugin enabled and at least one supported login provider (e.g. `LoginGoogle`) configured with valid keys \u2014 both are common production settings for this product.\n\n1. Victim initiates the mobile OAuth flow:\n\n ```\n GET /plugin/MobileManager/oauth2.php?type=Google\n ```\n\n2. After the victim authorizes at the provider, the server sends:\n\n ```\n HTTP/1.1 302 Found\n Location: oauth2Success.php?user=victim%40example.com\u0026pass=9d7ab4...stored-hash...\n ```\n\n This request-line \u2014 including the password hash \u2014 is written to the web server\u0027s access log (default `combined` format) and to any upstream proxy/CDN log. It also appears in the victim\u0027s browser history.\n\n3. Attacker obtains `\u003cHASH\u003e` from any of those channels.\n\n4. Attacker logs in as the victim without knowing the plaintext password:\n\n ```\n curl -i -c cookies.txt \\\n \u0027https://target.example.com/objects/login.json.php?user=victim@example.com\u0026pass=\u003cHASH\u003e\u0026encodedPass=1\u0027\n ```\n\n Expected response: `200 OK` with JSON containing `id`, `user`, `PHPSESSID`, `isAdmin`, `email`, and a `Set-Cookie: PHPSESSID=...` that grants full account access. The attacker can now browse, upload, modify the victim\u0027s channel, or \u2014 if the victim is an admin \u2014 access `/mvideos` and all admin endpoints.\n\n## Impact\n\n* Full account takeover of any user who has ever logged in through the MobileManager OAuth endpoint.\n* If the victim is an administrator, the attacker gains administrative control of the AVideo instance (user management, plugin config, site-wide content).\n* The exposed hash works indefinitely: it remains valid for as long as the victim does not change their password, so a one-time log/history/referrer capture yields a persistent credential.\n* Passes silently \u2014 from the application\u0027s perspective, the attacker is just a legitimate login with `encodedPass=1` (a flag the product itself uses for mobile-app \"remember me\" flows).\n\n## Recommended Fix\n\n1. Never place the password hash (or any credential-equivalent material) in a URL. In `plugin/MobileManager/oauth2.php`, mirror what `objects/login.json.php:143-146` already does for the web flow \u2014 establish the session server-side and redirect to a URL with no credentials:\n\n ```php\n $userObject = new User(0, $user, $pass);\n $userObject-\u003elogin(true); // server-side session\n header(\"Location: oauth2Success.php\");\n ```\n\n2. Additionally, remove or hard-restrict the `encodedPass` branch in `objects/functions.php:2319-2329`. If a \"hash-equivalent\" credential must exist for the mobile app, replace it with a short-lived, single-use, server-issued bearer token bound to the session, rather than the persistent database hash.\n\n3. Add a `state` parameter and CSRF protection on `/plugin/MobileManager/oauth2.php` so the redirect cannot be initiated from a third-party origin.\n\n4. For defense-in-depth, strip query strings containing `pass=` from access-log formats and ensure `oauth2Success.php` sets `Referrer-Policy: no-referrer` while it is being deprecated.",
"id": "GHSA-5w8w-26ch-v5cw",
"modified": "2026-05-13T14:19:29Z",
"published": "2026-05-05T19:08:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-5w8w-26ch-v5cw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43875"
},
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/commit/977cd6930a97571a26da4239e25c8096dd4ecbc1"
},
{
"type": "PACKAGE",
"url": "https://github.com/WWBN/AVideo"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "AVideo: Password Hash Leak in MobileManager OAuth Redirect URL Enables Account Takeover"
}
GHSA-5XJ4-3CF7-R6MM
Vulnerability from github – Published: 2025-07-14 18:30 – Updated: 2025-07-14 21:31An authenticated arbitrary file download vulnerability in the component /admin/Backups.php of Mccms v2.7.0 allows attackers to download arbitrary files via a crafted GET request.
{
"affected": [],
"aliases": [
"CVE-2025-51651"
],
"database_specific": {
"cwe_ids": [
"CWE-598"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-14T17:15:33Z",
"severity": "MODERATE"
},
"details": "An authenticated arbitrary file download vulnerability in the component /admin/Backups.php of Mccms v2.7.0 allows attackers to download arbitrary files via a crafted GET request.",
"id": "GHSA-5xj4-3cf7-r6mm",
"modified": "2025-07-14T21:31:45Z",
"published": "2025-07-14T18:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-51651"
},
{
"type": "WEB",
"url": "https://github.com/Y4y17/CVE/blob/main/Arbitrary%20file%20download%20vulnerability.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-63F7-76JF-XF93
Vulnerability from github – Published: 2026-05-14 18:32 – Updated: 2026-05-14 18:32HCL AION is affected by a vulnerability where sensitive information may be included in URL parameters. Passing sensitive data in URLs may expose it through browser history, logs, or intermediary systems, potentially leading to unintended information disclosure under certain conditions.
{
"affected": [],
"aliases": [
"CVE-2025-62317"
],
"database_specific": {
"cwe_ids": [
"CWE-598"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-14T17:16:19Z",
"severity": "LOW"
},
"details": "HCL AION is affected by a vulnerability where sensitive information may be included in URL parameters. Passing sensitive data in URLs may expose it through browser history, logs, or intermediary systems, potentially leading to unintended information disclosure under certain conditions.",
"id": "GHSA-63f7-76jf-xf93",
"modified": "2026-05-14T18:32:56Z",
"published": "2026-05-14T18:32:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62317"
},
{
"type": "WEB",
"url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0130636"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:L/UI:R/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6CF6-8HVR-R68W
Vulnerability from github – Published: 2024-04-04 14:21 – Updated: 2024-04-05 15:44Impact
In dectalk-tts@1.0.0, network requests to the third-party API are sent over HTTP, which is unencrypted. Unencrypted traffic can be easily intercepted and modified by attackers. Anyone who uses the package could be the victim of a man-in-the-middle (MITM) attack.
Theft
Because dectalk-tts is a text-to-speech package, user requests are expected to only contain natural language. The package README warns that user input is sent to a third-party API, so users should not send sensitive information regardless.
But if users ignore the warnings and send sensitive information anyway, that information could be stolen by attackers.
Modification
Attackers could manipulate requests to the API. However, the worst a modified request could do is return an incorrect audio file or bad request rejection.
Attackers could also manipulate responses from the API, returning malicious output to the user. Output is expected to be a wav-encoded buffer, which users will likely save to a file. This could be a dangerous entrypoint to the user's filesystem.
Patches
The network request was upgraded to HTTPS in version 1.0.1. No other changes were made, so updating is risk-free.
Workarounds
There are no workarounds, but here are some precautions:
-
Do not send any sensitive information.
-
Carefully verify the API response before saving it.
References
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "dectalk-tts"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.0.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.0.0"
]
}
],
"aliases": [
"CVE-2024-31206"
],
"database_specific": {
"cwe_ids": [
"CWE-300",
"CWE-319",
"CWE-598"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-04T14:21:19Z",
"nvd_published_at": "2024-04-04T23:15:15Z",
"severity": "HIGH"
},
"details": "### Impact\n\nIn `dectalk-tts@1.0.0`, network requests to the third-party API are sent over HTTP, which is unencrypted. Unencrypted traffic can be easily intercepted and modified by attackers. Anyone who uses the package could be the victim of a [man-in-the-middle (MITM)](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) attack.\n\n\u003cins\u003eTheft\u003c/ins\u003e\n\nBecause `dectalk-tts` is a text-to-speech package, user requests are expected to only contain natural language. The package [README](https://github.com/JstnMcBrd/dectalk-tts/blob/main/README.md) warns that user input is sent to a third-party API, so users should not send sensitive information regardless.\n\nBut if users ignore the warnings and send sensitive information anyway, that information could be stolen by attackers.\n\n\u003cins\u003eModification\u003c/ins\u003e\n\nAttackers could manipulate requests to the API. However, the worst a modified request could do is return an incorrect audio file or bad request rejection.\n\nAttackers could also manipulate responses from the API, returning malicious output to the user. Output is expected to be a wav-encoded buffer, which users will likely save to a file. This could be a dangerous entrypoint to the user\u0027s filesystem.\n\n### Patches\n\nThe network request was upgraded to HTTPS in version `1.0.1`. No other changes were made, so updating is risk-free.\n\n### Workarounds\n\nThere are no workarounds, but here are some precautions:\n\n- Do not send any sensitive information.\n\n- Carefully verify the API response before saving it.\n\n### References\n\n[Vulnerable code](https://github.com/JstnMcBrd/dectalk-tts/blob/b3e92156cbb699218ac9b9c7d8979abd0e635767/src/index.ts#L18)\n[Original report](https://github.com/JstnMcBrd/dectalk-tts/issues/3)\n[Patch pull request](https://github.com/JstnMcBrd/dectalk-tts/pull/4)\n",
"id": "GHSA-6cf6-8hvr-r68w",
"modified": "2024-04-05T15:44:23Z",
"published": "2024-04-04T14:21:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/JstnMcBrd/dectalk-tts/security/advisories/GHSA-6cf6-8hvr-r68w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31206"
},
{
"type": "WEB",
"url": "https://github.com/JstnMcBrd/dectalk-tts/issues/3"
},
{
"type": "WEB",
"url": "https://github.com/JstnMcBrd/dectalk-tts/pull/4"
},
{
"type": "WEB",
"url": "https://github.com/JstnMcBrd/dectalk-tts/commit/3600d8ac156f27da553ac4ead46d16989a350105"
},
{
"type": "PACKAGE",
"url": "https://github.com/JstnMcBrd/dectalk-tts"
},
{
"type": "WEB",
"url": "https://github.com/JstnMcBrd/dectalk-tts/blob/b3e92156cbb699218ac9b9c7d8979abd0e635767/src/index.ts#L18"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "dectalk-tts Uses Unencrypted HTTP Request"
}
GHSA-6CXR-8Q3M-JWRR
Vulnerability from github – Published: 2023-11-16 21:30 – Updated: 2025-01-09 23:39LFI in Ray's /static/ directory allows attackers to read any file on the server without authentication. The issue is fixed in version 2.8.1+. Ray maintainers response can be found here: https://www.anyscale.com/blog/update-on-ray-cves-cve-2023-6019-cve-2023-6020-cve-2023-6021-cve-2023-48022-cve-2023-48023
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "ray"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-6020"
],
"database_specific": {
"cwe_ids": [
"CWE-598",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2023-11-27T23:21:39Z",
"nvd_published_at": "2023-11-16T21:15:09Z",
"severity": "CRITICAL"
},
"details": "LFI in Ray\u0027s /static/ directory allows attackers to read any file on the server without authentication. The issue is fixed in version 2.8.1+. Ray maintainers response can be found here: https://www.anyscale.com/blog/update-on-ray-cves-cve-2023-6019-cve-2023-6020-cve-2023-6021-cve-2023-48022-cve-2023-48023",
"id": "GHSA-6cxr-8q3m-jwrr",
"modified": "2025-01-09T23:39:13Z",
"published": "2023-11-16T21:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6020"
},
{
"type": "WEB",
"url": "https://github.com/ray-project/ray"
},
{
"type": "WEB",
"url": "https://github.com/ray-project/ray/releases/tag/ray-2.8.1"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/83dd8619-6dc3-4c98-8f1b-e620fedcd1f6"
},
{
"type": "WEB",
"url": "https://www.anyscale.com/blog/update-on-ray-cves-cve-2023-6019-cve-2023-6020-cve-2023-6021-cve-2023-48022-cve-2023-48023"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Ray Missing Authorization vulnerability"
}
GHSA-6RJW-935F-MW9Q
Vulnerability from github – Published: 2025-02-27 15:31 – Updated: 2025-02-27 15:31A Password Transmitted over Query String vulnerability has been found in Trivision Camera NC227WF v5.8.0 from TrivisionSecurity, exposing this sensitive information to a third party.
{
"affected": [],
"aliases": [
"CVE-2025-1738"
],
"database_specific": {
"cwe_ids": [
"CWE-598"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T13:15:11Z",
"severity": "MODERATE"
},
"details": "A Password Transmitted over Query String vulnerability has been found in Trivision Camera NC227WF v5.8.0 from TrivisionSecurity, exposing this sensitive information to a third party.",
"id": "GHSA-6rjw-935f-mw9q",
"modified": "2025-02-27T15:31:51Z",
"published": "2025-02-27T15:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1738"
},
{
"type": "WEB",
"url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-trivision-camera-nc227wf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
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.