Repository navigation
MISP Analyzer: Unable to filter for unpublished events due to boolean logic flaw #3566
Description
What happened
Right now, the MISP analyzer doesn’t properly handle filtering for unpublished events. Even if published=False is selected in the configuration, that value never actually makes it into the API request sent to MISP.
This happens because of the current check:
if self.published:
Since False evaluates to falsy in Python, the condition fails and the parameter gets skipped entirely. As a result, the request is sent without any published filter.
Environment
- OS: Linux
What did you expect to happen
Setting published=False should send {"published": False} to the MISP API. This allows analysts to specifically hunt for fresh, indicators that analysts may want to specifically query.
How to reproduce your issue
- Uncheck the published box in a MISP analyzer configuration.
- Run any analysis.
- Observe that the API call sent to MISP (line 100 of misp.py) contains no published parameter
because if self.published: evaluates to False and skips the assignment.
I’ve already tested a fix for this locally. I’d be happy to take this up and open a PR please assign it to me.
Activity
mlodic commentedon Mar 27, 2026
not sure this is a real issue and was not intended actually...also a fix would require a MISP installation and interaction with it to hard proof that it works
gks281263 commentedon Apr 21, 2026
This issue is a duplicate of #3429 and has already been resolved by PR #3565.
The fix (commit 644cb8f) replaced the truthiness check:
Before (broken)
if self.published:
params["published"] = self.published
with an isinstance check that correctly handles False:
After (fixed)
if isinstance(self.published, bool):
params["published"] = self.published
The same fix was also applied to the metadata parameter which had the identical bug. Unit tests covering the published=False case were added in test_misp.py (MISPPublishedFalseTestCase).
@mlodic
github-actions commentedon May 21, 2026
This issue has been marked as stale because it has had no activity for 30 days. If you are still working on this, please provide some updates.