Refine your search

3 vulnerabilities found for misp-guard by MISP

CVE-2026-118173 (GCVE-0-2026-118173)
Vulnerability from cvelistv5
Published
2026-10-27 18:11
Modified
2026-10-27 18:11
CWE
  • CWE-20 - Improper Input Validation
  • CWE-285 - Improper Authorization
Summary
MISP Guard, a proxy that enforces security policies on MISP feed data, contained an incomplete validation check for required taxonomy tags. When a feed event or its attributes carried tags belonging to a required taxonomy (for example, TLP), the guard only verified that at least one tag of that taxonomy matched the configured allowed list. It did not verify that every tag of the required taxonomy present on the event or attribute was in the allowed list. As a result, an event or attribute could simultaneously carry an allowed tag (e.g., tlp:clear) and a non-allowed tag (e.g., tlp:red or tlp:amber) and still pass the guard's policy check. This allowed data marked with a higher classification or sensitivity level to be distributed through feeds configured to only distribute lower-classification data, effectively bypassing the intended data-handling restrictions. The vulnerability affected both event-level and attribute-level tag validation, including attributes nested within objects and shadow attributes. An attacker with the ability to author or modify MISP events in a feed source could include non-allowed taxonomy tags alongside allowed ones to exfiltrate more sensitive data to feed consumers than the guard policy intended to permit.
Impacted products
Vendor Product Version
MISP misp-guard Version: 0   ≤
    cpe:2.3:a:misp:misp-guard:*:*:*:*:*:*:*:*
Create a notification for this product.
Show details on NVD website


{
  "containers": {
    "cna": {
      "affected": [
        {
          "cpes": [
            "cpe:2.3:a:misp:misp-guard:*:*:*:*:*:*:*:*"
          ],
          "modules": [
            "src/mispguard.py"
          ],
          "product": "misp-guard",
          "programFiles": [
            "src/mispguard.py"
          ],
          "repo": "https://github.com/MISP/misp-guard",
          "vendor": "MISP",
          "versions": [
            {
              "lessThan": "1.4",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Luciano Righetti"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eMISP Guard, a proxy that enforces security policies on MISP feed data, contained an incomplete validation check for required taxonomy tags. When a feed event or its attributes carried tags belonging to a required taxonomy (for example, TLP), the guard only verified that at least one tag of that taxonomy matched the configured allowed list. It did not verify that every tag of the required taxonomy present on the event or attribute was in the allowed list. As a result, an event or attribute could simultaneously carry an allowed tag (e.g., tlp:clear) and a non-allowed tag (e.g., tlp:red or tlp:amber) and still pass the guard\u0027s policy check. This allowed data marked with a higher classification or sensitivity level to be distributed through feeds configured to only distribute lower-classification data, effectively bypassing the intended data-handling restrictions. The vulnerability affected both event-level and attribute-level tag validation, including attributes nested within objects and shadow attributes. An attacker with the ability to author or modify MISP events in a feed source could include non-allowed taxonomy tags alongside allowed ones to exfiltrate more sensitive data to feed consumers than the guard policy intended to permit.\u003c/p\u003e"
            }
          ],
          "value": "MISP Guard, a proxy that enforces security policies on MISP feed data, contained an incomplete validation check for required taxonomy tags. When a feed event or its attributes carried tags belonging to a required taxonomy (for example, TLP), the guard only verified that at least one tag of that taxonomy matched the configured allowed list. It did not verify that every tag of the required taxonomy present on the event or attribute was in the allowed list. As a result, an event or attribute could simultaneously carry an allowed tag (e.g., tlp:clear) and a non-allowed tag (e.g., tlp:red or tlp:amber) and still pass the guard\u0027s policy check. This allowed data marked with a higher classification or sensitivity level to be distributed through feeds configured to only distribute lower-classification data, effectively bypassing the intended data-handling restrictions. The vulnerability affected both event-level and attribute-level tag validation, including attributes nested within objects and shadow attributes. An attacker with the ability to author or modify MISP events in a feed source could include non-allowed taxonomy tags alongside allowed ones to exfiltrate more sensitive data to feed consumers than the guard policy intended to permit."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-120",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-120 Parameter Tampering"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 6.1,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "HIGH",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "HIGH",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:N/SC:N/SI:H/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "format": "SSVC",
          "other": {
            "content": {
              "options": [
                {
                  "Exploitation": "none"
                },
                {
                  "Automatable": "yes"
                },
                {
                  "Technical Impact": "partial"
                }
              ],
              "role": "Supplier",
              "timestamp": "2026-10-27T18:09:46Z",
              "version": "2.0.3"
            },
            "type": "SSVC"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-20",
              "description": "CWE-20 Improper Input Validation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-285",
              "description": "CWE-285 Improper Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-27T18:11:51.815Z",
        "orgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
        "shortName": "CIRCL"
      },
      "references": [
        {
          "name": "Security patch",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/MISP/misp-guard/commit/6127d94c350e4dfe31fd4426ba26f51294ed3867"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eThe fix introduces a new validation function, check_required_taxonomy_tags_allowed, that iterates over every tag belonging to a required taxonomy and verifies each one is present in the configured allowed-tags list, raising a ForbiddenException if any tag is not allowed. This check is applied at both the event level and the attribute level. Additionally, an inherit_event_taxonomies flag is introduced so that attributes without their own required-taxonomy tags inherit the event\u0027s already-validated taxonomy, while attributes that do carry tags of the required taxonomy are still fully validated against the allowed list. This ensures that no non-allowed tag of a required taxonomy can pass the guard regardless of whether an allowed tag is also present.\u003c/p\u003e"
            }
          ],
          "value": "The fix introduces a new validation function, check_required_taxonomy_tags_allowed, that iterates over every tag belonging to a required taxonomy and verifies each one is present in the configured allowed-tags list, raising a ForbiddenException if any tag is not allowed. This check is applied at both the event level and the attribute level. Additionally, an inherit_event_taxonomies flag is introduced so that attributes without their own required-taxonomy tags inherit the event\u0027s already-validated taxonomy, while attributes that do carry tags of the required taxonomy are still fully validated against the allowed list. This ensures that no non-allowed tag of a required taxonomy can pass the guard regardless of whether an allowed tag is also present."
        }
      ],
      "title": "MISP Guard Incomplete Tag Validation Allows Non-Allowed Taxonomy Tags to Bypass Feed Policy Enforcement",
      "x_gcve": [
        {
          "extensions": {
            "bcp-05-x-01": {
              "ai_annotations": [
                {
                  "ai_level": "generated",
                  "description": "Draft vulnerability metadata was generated from a git-format patch using an Ollama-hosted language model. Human validation is required before publication.",
                  "gna_source": 1,
                  "models": [
                    {
                      "gna_source": 1,
                      "identifier": "qwen3.8:27b",
                      "name": "qwen3.8:27b",
                      "source": "ollama"
                    }
                  ],
                  "review_status": "partial",
                  "scope": "record",
                  "tags": [
                    "ai-computer-assisted:llm-generated",
                    "ai-computer-assisted:classification"
                  ]
                }
              ]
            },
            "bcp-05-x-02": {
              "x_patch2vuln": {
                "assumptions": [
                  "The CAPEC-120 mapping is the closest available match but is not a perfect fit; the attack involves manipulation of structured MISP event tag fields rather than traditional HTTP parameters. No more specific CAPEC for structured-data tag manipulation exists in the CAPEC catalog.",
                  "The CVSS PR:H assumption is based on the inference that an attacker needs write access to a MISP instance to author events with non-allowed tags. If the guard is deployed in a context where feed sources are fully trusted, the practical exploitability may be lower.",
                  "The exact fixed version is not specified in the patch metadata. The tag_version_boundary indicates v1.4 is the nearest tag with 15 commits after the fix, suggesting the fix landed in a version after 1.4, but the precise version number is unknown.",
                  "The SI:H rating assumes the data distribution policy violation (higher-TLP data reaching lower-TLP consumers) constitutes a significant integrity impact on the feed\u0027s trust model. A different rating (e.g., SI:L) could be argued if the policy is considered advisory rather than binding.",
                  "The patch does not specify whether the vulnerability was discovered through a security audit, bug report, or internal testing. No finder or reporter credit is assigned beyond the remediation developer."
                ],
                "capecRationale": [
                  {
                    "capecId": "CAPEC-120",
                    "rationale": "The closest plausible attack pattern is parameter tampering: an attacker who can author MISP feed events manipulates the tag parameters to include a non-allowed taxonomy tag (e.g., tlp:red) alongside an allowed one (e.g., tlp:clear), exploiting the guard\u0027s incomplete validation that only checked for the presence of at least one allowed tag. The uncertainty is that this is not a traditional HTTP parameter tampering scenario but rather manipulation of structured data fields (tags) within MISP event objects; however, the fundamental technique of altering input values to bypass validation aligns with CAPEC-120."
                  }
                ],
                "commit": "6127d94c350e4dfe31fd4426ba26f51294ed3867",
                "confidence": "medium",
                "cpeReview": [
                  {
                    "api": "https://cpe.gcve.eu/api/cpes",
                    "cpe": "cpe:2.3:a:misp:misp-guard:*:*:*:*:*:*:*:*",
                    "exactSearchTruncated": false,
                    "searchTruncated": false,
                    "status": "not_found"
                  }
                ],
                "credits": [
                  {
                    "lang": "en",
                    "type": "remediation developer",
                    "value": "Luciano Righetti"
                  }
                ],
                "cvssRationale": "AV:N: The vulnerability is exploitable over the network via MISP feed endpoints. AC:L: The attack is straightforward; the attacker simply includes a non-allowed tag alongside an allowed one. AT:N: No need to manipulate or bypass any additional protection. PR:H: The attacker requires high privileges, specifically the ability to author or modify MISP events in a feed source (write access to a MISP instance). UI:N: No user interaction is required. VC:N/VI:N/VA:N: The guard process itself is not compromised in terms of its own confidentiality, integrity, or availability. SC:N: No direct impact on connected systems\u0027 confidentiality. SI:H: The integrity of the data distribution policy is significantly violated; data with higher sensitivity/classification is distributed to consumers who should only receive lower-classification data, undermining the trust model of the feed. SA:N: No cascading security impact on other systems.",
                "fixSummary": "The fix introduces a new validation function, check_required_taxonomy_tags_allowed, that iterates over every tag belonging to a required taxonomy and verifies each one is present in the configured allowed-tags list, raising a ForbiddenException if any tag is not allowed. This check is applied at both the event level and the attribute level. Additionally, an inherit_event_taxonomies flag is introduced so that attributes without their own required-taxonomy tags inherit the event\u0027s already-validated taxonomy, while attributes that do carry tags of the required taxonomy are still fully validated against the allowed list. This ensures that no non-allowed tag of a required taxonomy can pass the guard regardless of whether an allowed tag is also present.",
                "generatedAt": "2026-10-27T18:09:46.639416Z",
                "generator": "patch2vuln.py",
                "model": "qwen3.8:27b",
                "modelComparison": {
                  "rankings": [
                    {
                      "agreementScore": 11,
                      "assumptionCount": 5,
                      "confidence": "medium",
                      "model": "qwen3.8:27b",
                      "score": 7
                    }
                  ],
                  "selectedModel": "qwen3.8:27b",
                  "selectionMethod": "deterministic-consensus-v1",
                  "selectionNotice": "The selected result is closest to model consensus; this heuristic does not establish factual correctness and human review remains required."
                },
                "patchSha256": "96c08da8be43b5e5165fc57cebe9904273d91d56fcf14a0566ecd3dfb50ce099",
                "patchSummary": "In src/mispguard.py: (1) Added a new method check_required_taxonomy_tags_allowed that loops over all tags of a required taxonomy and rejects any tag not in the allowed list. (2) Modified check_event_required_taxonomies to call the new method after the existing existence check. (3) Modified check_attribute_required_taxonomies to accept an inherit_event_taxonomies parameter; when True, the existence check is skipped (the event already satisfied it) but the new allowed-tags check still runs on any tags the attribute does hold. (4) Added the inherit_event_taxonomies parameter to check_attribute_level_rules and check_object_level_rules, threading it through recursive calls for ShadowAttribute and object attributes. (5) Updated check_required_taxonomy_exists to accept an entity parameter for clearer error messages. (6) Added 172 lines of test cases in src/test/test_misp_guard.py covering: event with both allowed and non-allowed taxonomy tags (blocked), untagged attribute under a tagged event (allowed), attribute in",
                "patchTruncated": false,
                "patches": [
                  {
                    "commit": "6127d94c350e4dfe31fd4426ba26f51294ed3867",
                    "date": "Mon, 26 Oct 2026 08:44:32 +0100",
                    "patchSha256": "96c08da8be43b5e5165fc57cebe9904273d91d56fcf14a0566ecd3dfb50ce099",
                    "source": "https://github.com/MISP/misp-guard/commit/6127d94c350e4dfe31fd4426ba26f51294ed3867.patch",
                    "sourceUrl": "https://github.com/MISP/misp-guard/commit/6127d94c350e4dfe31fd4426ba26f51294ed3867.patch",
                    "subject": "fix: [security] enforce allowed tags on every tag of a"
                  }
                ],
                "source": "https://github.com/MISP/misp-guard/commit/6127d94c350e4dfe31fd4426ba26f51294ed3867.patch",
                "ssvc": {
                  "options": [
                    {
                      "Exploitation": "none"
                    },
                    {
                      "Automatable": "yes"
                    },
                    {
                      "Technical Impact": "partial"
                    }
                  ],
                  "role": "Supplier",
                  "timestamp": "2026-10-27T18:09:46Z",
                  "version": "2.0.3"
                },
                "subject": "fix: [security] enforce allowed tags on every tag of a",
                "tagVersionBoundary": {
                  "commits_after_fix": 15,
                  "repository": "https://github.com/MISP/misp-guard",
                  "tag": "v1.4",
                  "version": "1.4",
                  "version_type": "custom"
                },
                "weaknessRationale": [
                  {
                    "cweId": "CWE-20",
                    "rationale": "The guard\u0027s validation logic for required taxonomy tags was incomplete: it only checked for the existence of at least one allowed tag rather than verifying that all tags of the required taxonomy were in the allowed list. This is a classic incomplete input validation flaw where the check does not cover all relevant input values."
                  },
                  {
                    "cweId": "CWE-285",
                    "rationale": "The guard\u0027s purpose is to enforce authorization policies on data flowing through MISP feeds. The incomplete tag check effectively allowed unauthorized (non-allowed) tags to pass, resulting in improper enforcement of the data distribution authorization policy."
                  }
                ]
              }
            },
            "bcp-05-x-03": {
              "x_timeline": {
                "events": [
                  {
                    "description": "Corrective change authored (6127d94c350e4dfe31fd4426ba26f51294ed3867): fix: [security] enforce allowed tags on every tag of a",
                    "id": "evt-fix-developed-1",
                    "references": [
                      "https://github.com/MISP/misp-guard/commit/6127d94c350e4dfe31fd4426ba26f51294ed3867.patch"
                    ],
                    "timestamp": "2026-10-26T07:44:32Z",
                    "type": "fix-developed"
                  }
                ]
              }
            }
          },
          "recordType": "advisory",
          "vulnId": "gcve-1-2026-20219"
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
    "assignerShortName": "CIRCL",
    "cveId": "CVE-2026-118173",
    "datePublished": "2026-10-27T18:11:51.815Z",
    "dateReserved": "2026-10-27T18:11:43.078Z",
    "dateUpdated": "2026-10-27T18:11:51.815Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2026-116469 (GCVE-0-2026-116469)
Vulnerability from cvelistv5
Published
2026-10-26 10:35
Modified
2026-10-27 18:14
CWE
  • CWE-178 - Improper Handling of Case Sensitivity
  • CWE-20 - Improper Input Validation
Summary
MISP Guard, a proxy-based security filter for MISP feed distribution, contains a case-sensitivity flaw in multiple policy enforcement checks. The functions check_required_taxonomy_exists, check_required_taxonomy_tags_allowed, check_blocked_attribute_categories, and check_blocked_analyst_data_sharing_groups_uuids performed case-sensitive string comparisons when matching event tags, attribute categories, and sharing-group UUIDs against configured allow/block lists. An attacker with the ability to create or modify events in a MISP instance (or a connected instance that pushes events through the guard) could craft events using different letter case in taxonomy tag names, attribute categories, or sharing-group UUIDs to bypass the configured security policies. For example, if the policy requires the 'tlp' taxonomy with only 'tlp:clear' allowed, an event tagged 'TLP:AMBER' would not be recognized as belonging to the 'tlp' taxonomy and would therefore not be checked against the allowed-tags list, resulting in the event being forwarded to feed consumers. Similarly, a blocked attribute category such as 'Person' would not match a configured block entry of 'person', allowing the attribute to pass through the filter. The security impact is unauthorized disclosure of threat-intelligence data that the operator intended to restrict. Events carrying non-allowed TLP (Traffic Light Protocol) markings, blocked attribute categories, or blocked sharing-group associations are forwarded to downstream feed consumers in violation of the configured distribution policy. This undermines the confidentiality controls that MISP Guard is designed to enforce. The vulnerability is trivially exploitable: the attacker only needs to alter the letter case of a tag, category, or UUID string. No authentication beyond normal MISP event-creation privileges is required, and no user interaction is needed.
Impacted products
Vendor Product Version
MISP misp-guard Version: 0   ≤ 1.3
    cpe:2.3:a:misp:misp-guard:*:*:*:*:*:*:*:*
Create a notification for this product.
Show details on NVD website


{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-116469",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-26T13:32:47.760705Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-26T14:35:18.399Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "cpes": [
            "cpe:2.3:a:misp:misp-guard:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unaffected",
          "modules": [
            "src/mispguard.py"
          ],
          "product": "misp-guard",
          "programFiles": [
            "src/mispguard.py"
          ],
          "repo": "https://github.com/MISP/misp-guard",
          "vendor": "MISP",
          "versions": [
            {
              "lessThanOrEqual": "1.3",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Luciano Righetti"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Claude Opus 5.5 (1M context)"
        },
        {
          "lang": "en",
          "type": "tool",
          "value": "Claude Opus 5.5 (1M context)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eMISP Guard, a proxy-based security filter for MISP feed distribution, contains a case-sensitivity flaw in multiple policy enforcement checks. The functions check_required_taxonomy_exists, check_required_taxonomy_tags_allowed, check_blocked_attribute_categories, and check_blocked_analyst_data_sharing_groups_uuids performed case-sensitive string comparisons when matching event tags, attribute categories, and sharing-group UUIDs against configured allow/block lists.\u003c/p\u003e\u003cp\u003eAn attacker with the ability to create or modify events in a MISP instance (or a connected instance that pushes events through the guard) could craft events using different letter case in taxonomy tag names, attribute categories, or sharing-group UUIDs to bypass the configured security policies. For example, if the policy requires the \u0027tlp\u0027 taxonomy with only \u0027tlp:clear\u0027 allowed, an event tagged \u0027TLP:AMBER\u0027 would not be recognized as belonging to the \u0027tlp\u0027 taxonomy and would therefore not be checked against the allowed-tags list, resulting in the event being forwarded to feed consumers. Similarly, a blocked attribute category such as \u0027Person\u0027 would not match a configured block entry of \u0027person\u0027, allowing the attribute to pass through the filter.\u003c/p\u003e\u003cp\u003eThe security impact is unauthorized disclosure of threat-intelligence data that the operator intended to restrict. Events carrying non-allowed TLP (Traffic Light Protocol) markings, blocked attribute categories, or blocked sharing-group associations are forwarded to downstream feed consumers in violation of the configured distribution policy. This undermines the confidentiality controls that MISP Guard is designed to enforce.\u003c/p\u003e\u003cp\u003eThe vulnerability is trivially exploitable: the attacker only needs to alter the letter case of a tag, category, or UUID string. No authentication beyond normal MISP event-creation privileges is required, and no user interaction is needed.\u003c/p\u003e"
            }
          ],
          "value": "MISP Guard, a proxy-based security filter for MISP feed distribution, contains a case-sensitivity flaw in multiple policy enforcement checks. The functions check_required_taxonomy_exists, check_required_taxonomy_tags_allowed, check_blocked_attribute_categories, and check_blocked_analyst_data_sharing_groups_uuids performed case-sensitive string comparisons when matching event tags, attribute categories, and sharing-group UUIDs against configured allow/block lists.\n\nAn attacker with the ability to create or modify events in a MISP instance (or a connected instance that pushes events through the guard) could craft events using different letter case in taxonomy tag names, attribute categories, or sharing-group UUIDs to bypass the configured security policies. For example, if the policy requires the \u0027tlp\u0027 taxonomy with only \u0027tlp:clear\u0027 allowed, an event tagged \u0027TLP:AMBER\u0027 would not be recognized as belonging to the \u0027tlp\u0027 taxonomy and would therefore not be checked against the allowed-tags list, resulting in the event being forwarded to feed consumers. Similarly, a blocked attribute category such as \u0027Person\u0027 would not match a configured block entry of \u0027person\u0027, allowing the attribute to pass through the filter.\n\nThe security impact is unauthorized disclosure of threat-intelligence data that the operator intended to restrict. Events carrying non-allowed TLP (Traffic Light Protocol) markings, blocked attribute categories, or blocked sharing-group associations are forwarded to downstream feed consumers in violation of the configured distribution policy. This undermines the confidentiality controls that MISP Guard is designed to enforce.\n\nThe vulnerability is trivially exploitable: the attacker only needs to alter the letter case of a tag, category, or UUID string. No authentication beyond normal MISP event-creation privileges is required, and no user interaction is needed."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-10",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-10 Parameter Tampering"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "privilegesRequired": "LOW",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "format": "SSVC",
          "other": {
            "content": {
              "options": [
                {
                  "Exploitation": "none"
                },
                {
                  "Automatable": "yes"
                },
                {
                  "Technical Impact": "partial"
                }
              ],
              "role": "Supplier",
              "timestamp": "2026-10-26T10:33:59Z",
              "version": "2.0.3"
            },
            "type": "SSVC"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-178",
              "description": "CWE-178 Improper Handling of Case Sensitivity",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-20",
              "description": "CWE-20 Improper Input Validation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-27T18:14:58.333Z",
        "orgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
        "shortName": "CIRCL"
      },
      "references": [
        {
          "name": "Security patch",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/MISP/misp-guard/commit/9868b1d93fc9cc40cc7c69ca11c86afd825bbc1c"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eThe fix makes all policy-matching comparisons case-insensitive by applying .lower() to both the input value (tag name, attribute category, sharing-group UUID) and the configured policy value (required taxonomy prefix, allowed tags, blocked categories, blocked UUIDs) before performing the comparison. This ensures that a tag such as \u0027TLP:AMBER\u0027 is correctly recognized as belonging to the \u0027tlp\u0027 taxonomy and is checked against the allowed-tags list, and that a blocked category or UUID is matched regardless of letter case.\u003c/p\u003e"
            }
          ],
          "value": "The fix makes all policy-matching comparisons case-insensitive by applying .lower() to both the input value (tag name, attribute category, sharing-group UUID) and the configured policy value (required taxonomy prefix, allowed tags, blocked categories, blocked UUIDs) before performing the comparison. This ensures that a tag such as \u0027TLP:AMBER\u0027 is correctly recognized as belonging to the \u0027tlp\u0027 taxonomy and is checked against the allowed-tags list, and that a blocked category or UUID is matched regardless of letter case."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "MISP Guard Case-Sensitive Policy Bypass Allows Unauthorized Feed Data Forwarding",
      "x_gcve": [
        {
          "extensions": {
            "bcp-05-x-01": {
              "ai_annotations": [
                {
                  "ai_level": "generated",
                  "description": "Draft vulnerability metadata was generated from a git-format patch using an Ollama-hosted language model. Human validation is required before publication.",
                  "gna_source": 1,
                  "models": [
                    {
                      "gna_source": 1,
                      "identifier": "qwen3.8:27b",
                      "name": "qwen3.8:27b",
                      "source": "ollama"
                    }
                  ],
                  "review_status": "partial",
                  "scope": "record",
                  "tags": [
                    "ai-computer-assisted:llm-generated",
                    "ai-computer-assisted:classification"
                  ]
                }
              ]
            },
            "bcp-05-x-02": {
              "x_patch2vuln": {
                "assumptions": [
                  "The MISP Guard is assumed to operate as a proxy filtering outbound MISP feed data; the attacker is assumed to have the ability to create or modify events in a MISP instance that feeds through the guard. The patch does not specify the exact deployment topology.",
                  "PR:L assumes that creating events in MISP requires at least a low-privilege authenticated account. If the guard is used in a context where events are pushed from a connected MISP instance without per-event authentication, PR could be None.",
                  "The CAPEC-10 mapping is the closest available pattern; the actual attack involves modifying structured JSON event fields rather than traditional HTTP parameters, so the mapping is approximate.",
                  "No specific affected or fixed version numbers are provided in the patch metadata; the version range is marked as unspecified.",
                  "The commit message references \u0027ID 004\u0027 as a prior related fix, suggesting this is a follow-up to an earlier incomplete case-sensitivity fix, but no further details about that prior fix are available in the patch."
                ],
                "capecRationale": [
                  {
                    "capecId": "CAPEC-10",
                    "rationale": "The attacker tampers with the letter case of tag names, attribute categories, or sharing-group UUIDs in MISP events to bypass the guard\u0027s policy checks. This is a form of parameter tampering where the input is modified in a way that the validation logic does not anticipate. CAPEC-10 is the closest available pattern; the uncertainty is that the tampering occurs in structured event data rather than in a traditional request parameter, but the underlying technique (modifying input to evade validation) aligns with this pattern."
                  }
                ],
                "commit": "9868b1d93fc9cc40cc7c69ca11c86afd825bbc1c",
                "confidence": "medium",
                "credits": [
                  {
                    "lang": "en",
                    "type": "remediation developer",
                    "value": "Luciano Righetti"
                  },
                  {
                    "lang": "en",
                    "type": "remediation developer",
                    "value": "Claude Opus 5.5 (1M context)"
                  },
                  {
                    "lang": "en",
                    "type": "tool",
                    "value": "Claude Opus 5.5 (1M context)"
                  }
                ],
                "cvssRationale": "AV:N: The MISP feed is consumed over the network (HTTP). AC:L: Exploitation requires only changing the letter case of a tag, category, or UUID string. AT:N: No log or audit tampering is needed. PR:L: The attacker needs the ability to create or modify events in a MISP instance, which typically requires a low-privilege user account or a connected instance. UI:N: No user interaction is required. VC:H: The primary impact is unauthorized disclosure of data that the operator intended to restrict (non-allowed TLP tags, blocked categories, blocked sharing groups are forwarded to feed consumers). VI:N: The data content is not modified, only improperly shared. VA:N: No availability impact. SC/SI/SA:N: No secondary system impact is evidenced.",
                "fixSummary": "The fix makes all policy-matching comparisons case-insensitive by applying .lower() to both the input value (tag name, attribute category, sharing-group UUID) and the configured policy value (required taxonomy prefix, allowed tags, blocked categories, blocked UUIDs) before performing the comparison. This ensures that a tag such as \u0027TLP:AMBER\u0027 is correctly recognized as belonging to the \u0027tlp\u0027 taxonomy and is checked against the allowed-tags list, and that a blocked category or UUID is matched regardless of letter case.",
                "generatedAt": "2026-10-26T10:33:59.935580Z",
                "generator": "patch2vuln.py",
                "model": "qwen3.8:27b",
                "modelComparison": {
                  "rankings": [
                    {
                      "agreementScore": 11,
                      "assumptionCount": 5,
                      "confidence": "medium",
                      "model": "qwen3.8:27b",
                      "score": 7
                    }
                  ],
                  "selectedModel": "qwen3.8:27b",
                  "selectionMethod": "deterministic-consensus-v1",
                  "selectionNotice": "The selected result is closest to model consensus; this heuristic does not establish factual correctness and human review remains required."
                },
                "patchSha256": "26a847175a70394b7c0feaa57f7286f41fb131fc28c4c540412e88018c749628",
                "patchSummary": "In src/mispguard.py, four comparison sites were changed: (1) check_required_taxonomy_exists now uses tag[\u0027name\u0027].lower().startswith(required_taxonomy.lower() + \u0027:\u0027) instead of a case-sensitive startswith; (2) check_required_taxonomy_tags_allowed applies .lower() to both the tag name and the required taxonomy prefix in the startswith check; (3) check_blocked_attribute_categories compares attribute[\u0027category\u0027].lower() against a lowercased list of blocked categories; (4) check_blocked_analyst_data_sharing_groups_uuids compares the UUID in lowercase against a lowercased list of blocked UUIDs. Ninety-one lines of test cases were added to src/test/test_misp_guard.py covering mixed-case TLP tags in required-taxonomy checks and mixed-case blocked attribute categories.",
                "patchTruncated": false,
                "patches": [
                  {
                    "commit": "9868b1d93fc9cc40cc7c69ca11c86afd825bbc1c",
                    "date": "Mon, 26 Oct 2026 10:25:52 +0100",
                    "patchSha256": "26a847175a70394b7c0feaa57f7286f41fb131fc28c4c540412e88018c749628",
                    "source": "https://github.com/MISP/misp-guard/commit/9868b1d93fc9cc40cc7c69ca11c86afd825bbc1c.patch",
                    "sourceUrl": "https://github.com/MISP/misp-guard/commit/9868b1d93fc9cc40cc7c69ca11c86afd825bbc1c.patch",
                    "subject": "fix: [security] match categories and required taxonomies"
                  }
                ],
                "source": "https://github.com/MISP/misp-guard/commit/9868b1d93fc9cc40cc7c69ca11c86afd825bbc1c.patch",
                "ssvc": {
                  "options": [
                    {
                      "Exploitation": "none"
                    },
                    {
                      "Automatable": "yes"
                    },
                    {
                      "Technical Impact": "partial"
                    }
                  ],
                  "role": "Supplier",
                  "timestamp": "2026-10-26T10:33:59Z",
                  "version": "2.0.3"
                },
                "subject": "fix: [security] match categories and required taxonomies",
                "weaknessRationale": [
                  {
                    "cweId": "CWE-178",
                    "rationale": "The root cause is that string comparisons used to enforce security policies (taxonomy prefix matching, category blocking, UUID blocking) were case-sensitive, allowing an attacker to bypass the checks by altering letter case. CWE-178 is the most specific and accurate mapping."
                  },
                  {
                    "cweId": "CWE-20",
                    "rationale": "More broadly, the guard failed to validate input against the policy in a canonical form, which is a form of improper input validation. CWE-20 is included as a secondary, broader mapping."
                  }
                ]
              }
            },
            "bcp-05-x-03": {
              "x_timeline": {
                "events": [
                  {
                    "description": "Corrective change authored (9868b1d93fc9cc40cc7c69ca11c86afd825bbc1c): fix: [security] match categories and required taxonomies",
                    "id": "evt-fix-developed-1",
                    "references": [
                      "https://github.com/MISP/misp-guard/commit/9868b1d93fc9cc40cc7c69ca11c86afd825bbc1c.patch"
                    ],
                    "timestamp": "2026-10-26T09:25:52Z",
                    "type": "fix-developed"
                  }
                ]
              }
            }
          },
          "recordType": "advisory",
          "vulnId": "gcve-1-2026-20344"
        }
      ],
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
    "assignerShortName": "CIRCL",
    "cveId": "CVE-2026-116469",
    "datePublished": "2026-10-26T10:35:51.992Z",
    "dateReserved": "2026-10-26T10:35:05.591Z",
    "dateUpdated": "2026-10-27T18:14:58.333Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2026-116372 (GCVE-0-2026-116372)
Vulnerability from cvelistv5
Published
2026-10-26 08:36
Modified
2026-10-26 08:36
CWE
  • CWE-20 - Improper Input Validation
Summary
MISP mispguard is a security filtering proxy that inspects and blocks MISP feed responses based on configured rules. The process_feed_response method in src/mispguard.py was responsible for evaluating feed responses before they reached the MISP instance. The original logic only explicitly handled the case where the HTTP status code was not 200 by passing the response through without filtering, on the assumption that non-200 responses would not carry ingestible event data. However, HTTP 2xx status codes other than 200 (such as 201 Created, 203 Non-Authoritative Information, and 206 Partial Content) were also passed through unfiltered. Because MISP may still ingest content from these responses, a malicious or compromised feed host could return a 203 or 206 status code with arbitrary content, effectively bypassing all of mispguard's filtering rules. This allowed unfiltered or malicious feed data to be ingested into the MISP instance, undermining the security controls that mispguard is designed to enforce. The vulnerability requires the attacker to control or compromise a feed endpoint configured in the MISP instance. No authentication or user interaction is required beyond the feed polling mechanism already in place.
Impacted products
Vendor Product Version
MISP misp-guard Version: 0   ≤ 1.3
    cpe:2.3:a:misp:misp-guard:*:*:*:*:*:*:*:*
Create a notification for this product.
Show details on NVD website


{
  "containers": {
    "cna": {
      "affected": [
        {
          "cpes": [
            "cpe:2.3:a:misp:misp-guard:*:*:*:*:*:*:*:*"
          ],
          "modules": [
            "src/mispguard.py (process_feed_response)"
          ],
          "product": "misp-guard",
          "programFiles": [
            "src/mispguard.py"
          ],
          "repo": "https://github.com/MISP/misp-guard",
          "vendor": "MISP",
          "versions": [
            {
              "lessThanOrEqual": "1.3",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Luciano Righetti"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Claude Opus 5.5 (1M context)"
        },
        {
          "lang": "en",
          "type": "tool",
          "value": "Claude Opus 5.5 (1M context)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eMISP mispguard is a security filtering proxy that inspects and blocks MISP feed responses based on configured rules. The process_feed_response method in src/mispguard.py was responsible for evaluating feed responses before they reached the MISP instance. The original logic only explicitly handled the case where the HTTP status code was not 200 by passing the response through without filtering, on the assumption that non-200 responses would not carry ingestible event data. However, HTTP 2xx status codes other than 200 (such as 201 Created, 203 Non-Authoritative Information, and 206 Partial Content) were also passed through unfiltered. Because MISP may still ingest content from these responses, a malicious or compromised feed host could return a 203 or 206 status code with arbitrary content, effectively bypassing all of mispguard\u0027s filtering rules. This allowed unfiltered or malicious feed data to be ingested into the MISP instance, undermining the security controls that mispguard is designed to enforce. The vulnerability requires the attacker to control or compromise a feed endpoint configured in the MISP instance. No authentication or user interaction is required beyond the feed polling mechanism already in place.\u003c/p\u003e"
            }
          ],
          "value": "MISP mispguard is a security filtering proxy that inspects and blocks MISP feed responses based on configured rules. The process_feed_response method in src/mispguard.py was responsible for evaluating feed responses before they reached the MISP instance. The original logic only explicitly handled the case where the HTTP status code was not 200 by passing the response through without filtering, on the assumption that non-200 responses would not carry ingestible event data. However, HTTP 2xx status codes other than 200 (such as 201 Created, 203 Non-Authoritative Information, and 206 Partial Content) were also passed through unfiltered. Because MISP may still ingest content from these responses, a malicious or compromised feed host could return a 203 or 206 status code with arbitrary content, effectively bypassing all of mispguard\u0027s filtering rules. This allowed unfiltered or malicious feed data to be ingested into the MISP instance, undermining the security controls that mispguard is designed to enforce. The vulnerability requires the attacker to control or compromise a feed endpoint configured in the MISP instance. No authentication or user interaction is required beyond the feed polling mechanism already in place."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-2",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-2 Input Parameter Manipulation"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 7.7,
            "baseSeverity": "HIGH",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "HIGH",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:H/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "format": "SSVC",
          "other": {
            "content": {
              "options": [
                {
                  "Exploitation": "none"
                },
                {
                  "Automatable": "yes"
                },
                {
                  "Technical Impact": "partial"
                }
              ],
              "role": "Supplier",
              "timestamp": "2026-10-26T08:33:29Z",
              "version": "2.0.3"
            },
            "type": "SSVC"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-20",
              "description": "CWE-20 Improper Input Validation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-26T08:36:16.664Z",
        "orgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
        "shortName": "CIRCL"
      },
      "references": [
        {
          "name": "Security patch",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/MISP/misp-guard/commit/b5f606a4e57a49cc4dbf9b3ef0c6ddd19f866735"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eThe fix adds an explicit check in process_feed_response that rejects any HTTP response with a status code in the 201-299 range (i.e., successful responses other than 200) by returning a 403 Forbidden response. This ensures that only responses with exactly status code 200 are subject to the normal filtering pipeline, and all other 2xx responses are blocked before they can reach the MISP instance, closing the bypass vector.\u003c/p\u003e"
            }
          ],
          "value": "The fix adds an explicit check in process_feed_response that rejects any HTTP response with a status code in the 201-299 range (i.e., successful responses other than 200) by returning a 403 Forbidden response. This ensures that only responses with exactly status code 200 are subject to the normal filtering pipeline, and all other 2xx responses are blocked before they can reach the MISP instance, closing the bypass vector."
        }
      ],
      "title": "MISP mispguard: Feed responses with 2xx status codes other than 200 bypass filtering rules",
      "x_gcve": [
        {
          "extensions": {
            "bcp-05-x-01": {
              "ai_annotations": [
                {
                  "ai_level": "generated",
                  "description": "Draft vulnerability metadata was generated from a git-format patch using an Ollama-hosted language model. Human validation is required before publication.",
                  "gna_source": 1,
                  "models": [
                    {
                      "gna_source": 1,
                      "identifier": "qwen3.8:27b",
                      "name": "qwen3.8:27b",
                      "source": "ollama"
                    }
                  ],
                  "review_status": "partial",
                  "scope": "record",
                  "tags": [
                    "ai-computer-assisted:llm-generated",
                    "ai-computer-assisted:classification"
                  ]
                }
              ]
            },
            "bcp-05-x-02": {
              "x_patch2vuln": {
                "assumptions": [
                  "The affected version range is unknown; the patch does not specify a version boundary or tag. All versions of mispguard prior to this commit are assumed affected.",
                  "The assumption that MISP will ingest content from 2xx responses other than 200 is stated in the commit message and code comments but not independently verified; the fix treats this as a security requirement regardless.",
                  "CAPEC-2 (Input Parameter Manipulation) is the closest available pattern; no CAPEC specifically covers HTTP status code manipulation to bypass proxy filtering logic.",
                  "The CVSS vector assumes the attacker controls or compromises a feed endpoint configured in the MISP instance; no additional authentication or network position is assumed beyond that.",
                  "The SSVC technical impact is assessed as \u0027partial\u0027 based on the assumption that the MISP instance remains operational but with degraded filtering; a \u0027total\u0027 impact would require evidence of data corruption or system failure.",
                  "The commit date (26 Oct 2026) is in the future relative to typical analysis timelines; this is taken at face value from the patch metadata."
                ],
                "capecRationale": [
                  {
                    "capecId": "CAPEC-2",
                    "rationale": "The attacker (a feed host) manipulates the HTTP response status code parameter to a value (203, 206) that the filtering logic does not properly handle, causing the response to bypass all filtering rules. This is the closest CAPEC pattern: the attacker controls an input parameter (the status code) to trigger an unintended code path. Uncertainty: no CAPEC pattern specifically addresses HTTP status code manipulation for proxy bypass; CAPEC-2 is the best available match for parameter-level manipulation to defeat validation logic."
                  }
                ],
                "commit": "b5f606a4e57a49cc4dbf9b3ef0c6ddd19f866735",
                "confidence": "medium",
                "credits": [
                  {
                    "lang": "en",
                    "type": "remediation developer",
                    "value": "Luciano Righetti"
                  },
                  {
                    "lang": "en",
                    "type": "remediation developer",
                    "value": "Claude Opus 5.5 (1M context)"
                  },
                  {
                    "lang": "en",
                    "type": "tool",
                    "value": "Claude Opus 5.5 (1M context)"
                  }
                ],
                "cvssRationale": "The vulnerability is exploitable over the network (AV:N) with low complexity (AC:L) since the attacker only needs to return a different HTTP status code. No attack target manipulation (AT:N), no privileges (PR:N) since the attacker is the feed host itself, and no user interaction (UI:N) is required. The vulnerable component (mispguard) itself suffers no direct confidentiality, integrity, or availability impact (VC:N, VI:N, VA:N). The primary impact is on the downstream MISP instance, whose integrity is compromised because unfiltered feed data is ingested (SI:H). No secondary confidentiality or availability impact (SC:N, SA:N) is evidenced.",
                "fixSummary": "The fix adds an explicit check in process_feed_response that rejects any HTTP response with a status code in the 201-299 range (i.e., successful responses other than 200) by returning a 403 Forbidden response. This ensures that only responses with exactly status code 200 are subject to the normal filtering pipeline, and all other 2xx responses are blocked before they can reach the MISP instance, closing the bypass vector.",
                "generatedAt": "2026-10-26T08:33:29.004607Z",
                "generator": "patch2vuln.py",
                "model": "qwen3.8:27b",
                "modelComparison": {
                  "rankings": [
                    {
                      "agreementScore": 11,
                      "assumptionCount": 6,
                      "confidence": "medium",
                      "model": "qwen3.8:27b",
                      "score": 6
                    }
                  ],
                  "selectedModel": "qwen3.8:27b",
                  "selectionMethod": "deterministic-consensus-v1",
                  "selectionNotice": "The selected result is closest to model consensus; this heuristic does not establish factual correctness and human review remains required."
                },
                "patchSha256": "c553e477781b3c949ccb2f9eda15d3d9797652c9e0c257afe8580f39db5b0e71",
                "patchSummary": "In src/mispguard.py, a new conditional block is inserted at the top of process_feed_response, before the existing status-code check. The new block tests whether flow.response.status_code is greater than 200 and less than 300, and if so, calls self.forbidden() to return a 403 response with a descriptive log message. In src/test/test_misp_guard.py, a new parametrized async test test_feed_non_200_success_response_is_blocked is added, covering status codes 201, 203, and 206, asserting that the response is blocked (status 403) and the appropriate log message is emitted.",
                "patchTruncated": false,
                "patches": [
                  {
                    "commit": "b5f606a4e57a49cc4dbf9b3ef0c6ddd19f866735",
                    "date": "Mon, 26 Oct 2026 08:53:50 +0100",
                    "patchSha256": "c553e477781b3c949ccb2f9eda15d3d9797652c9e0c257afe8580f39db5b0e71",
                    "source": "https://github.com/MISP/misp-guard/commit/b5f606a4e57a49cc4dbf9b3ef0c6ddd19f866735.patch",
                    "sourceUrl": "https://github.com/MISP/misp-guard/commit/b5f606a4e57a49cc4dbf9b3ef0c6ddd19f866735.patch",
                    "subject": "fix: [security] block successful feed responses other than"
                  }
                ],
                "source": "https://github.com/MISP/misp-guard/commit/b5f606a4e57a49cc4dbf9b3ef0c6ddd19f866735.patch",
                "ssvc": {
                  "options": [
                    {
                      "Exploitation": "none"
                    },
                    {
                      "Automatable": "yes"
                    },
                    {
                      "Technical Impact": "partial"
                    }
                  ],
                  "role": "Supplier",
                  "timestamp": "2026-10-26T08:33:29Z",
                  "version": "2.0.3"
                },
                "subject": "fix: [security] block successful feed responses other than",
                "weaknessRationale": [
                  {
                    "cweId": "CWE-20",
                    "rationale": "The code validated the HTTP status code incompletely: it checked for != 200 to decide whether to pass through, but failed to account for other 2xx codes (201, 203, 206) that represent successful responses whose content MISP may still ingest. The validation logic did not cover the full range of inputs that required filtering, constituting improper input validation."
                  }
                ]
              }
            },
            "bcp-05-x-03": {
              "x_timeline": {
                "events": [
                  {
                    "description": "Corrective change authored (b5f606a4e57a49cc4dbf9b3ef0c6ddd19f866735): fix: [security] block successful feed responses other than",
                    "id": "evt-fix-developed-1",
                    "references": [
                      "https://github.com/MISP/misp-guard/commit/b5f606a4e57a49cc4dbf9b3ef0c6ddd19f866735.patch"
                    ],
                    "timestamp": "2026-10-26T07:53:50Z",
                    "type": "fix-developed"
                  }
                ]
              }
            }
          },
          "recordType": "advisory",
          "vulnId": "gcve-1-2026-20298"
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
    "assignerShortName": "CIRCL",
    "cveId": "CVE-2026-116372",
    "datePublished": "2026-10-26T08:36:16.664Z",
    "dateReserved": "2026-10-26T08:36:08.354Z",
    "dateUpdated": "2026-10-26T08:36:16.664Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}