MISP mispguard CVE-2026-116372

Requires (1) mispguard deployed as the filtering proxy in front of a MISP instance, and (2) the attacker controlling or compromising a feed endpoint that is already configured and polled by that MISP instance. Exploitation then occurs automatically through the existing feed polling mechanism with no authentication or user interaction, by returning any HTTP 2xx status other than 200 - specifically 201, 203, or 206 per the fix - carrying unfiltered content. Limiting factors: the attacker gains nothing without an attacker-controlled configured feed, only successful (2xx, non-200) responses bypass filtering, and the issue affects only the pre-patch process_feed_response logic in src/mispguard.py.

CVSS 4.0 rates this 7.7 (High), driven entirely by subsequent-system integrity impact (SI:H) with no confidentiality, availability, or code-execution impact (VC:N/VI:N/VA:N). The vector is network, low-complexity, no-privilege, no-interaction (AV:N/AC:L/PR:N/UI:N), but that does not mean trivial internet-wide exploitation: the description makes clear the attacker must already control or compromise a feed endpoint that the victim's MISP instance is configured to poll, so reachability depends on that trust relationship rather than open network access. The vuln.today decision label is 'this_week', consistent with a real but non-emergency integrity flaw in a security control. No EPSS score, no CISA KEV listing, and no public exploit were provided in the input, so there is no signal of active or widespread exploitation - this reads as a defense-weakening filter bypass to remediate on a normal patch cadence, not a high-CVSS issue being mass-exploited. Note a conflict in the metadata: the 'RCE' tag is inconsistent with the CVSS vector and description, which describe unfiltered data ingestion (integrity), not remote code execution.

An operator deploys mispguard to filter an external threat-intel feed; the feed host is attacker-controlled or later compromised. During a routine feed poll, the host returns an HTTP 203 or 206 response carrying crafted MISP event data, which mispguard passes through unfiltered because its logic only blocked non-200 responses, allowing the malicious events to be ingested. No public exploit was identified in the input, but the trigger is straightforward given control of the feed response.