CVE-2026-91002: Maltrail Authentication Bypass Vulnerability

CVE-2026-91002 Overview

CVE-2026-91002 is a missing authentication vulnerability [CWE-287] affecting Maltrail, an open-source malicious traffic detection system maintained by stamparm. The flaw resides in the _blacklist function inside core/httpd.py, which serves the /blacklist endpoint without requiring authentication. Any remote client that can reach the Maltrail server can pull the blacklist output, exposing source IP addresses collected from the event log. The issue affects Maltrail versions up to and including 3.0.1 and was resolved in version 3.1 via commit d95868dff3da4d3bd4f942837a26cb7c73a797ae. A public exploit exists, increasing the likelihood of opportunistic scanning against exposed instances.

Critical Impact
Unauthenticated remote attackers can retrieve blacklist data containing source IPs harvested from the Maltrail event log, enabling reconnaissance of monitored networks.

Affected Products

Maltrail versions up to and including 3.0.1
Component: core/httpd.py Blacklist Endpoint (/blacklist)
Fixed in Maltrail 3.1

Discovery Timeline

2026-09-15 - CVE-2026-91002 published to the National Vulnerability Database (NVD)
2026-09-15 - Vendor released version 3.1 containing patch commit d95868dff3da4d3bd4f942837a26cb7c73a797ae the same day the issue was reported
2026-09-15 - Last updated in NVD database

Technical Details for CVE-2026-91002

Vulnerability Analysis

Maltrail exposes an HTTP endpoint at /blacklist intended for downstream firewall automation to pull generated blacklists. Prior to version 3.1, the _blacklist handler in core/httpd.py performed no authentication check and no source-IP allowlist enforcement. A remote caller could issue a plain HTTP GET request to /blacklist and receive the current blacklist output. Because blacklist entries derive from the event log, disclosure reveals which source IPs the sensor has observed, and by extension which internal assets participated in flagged sessions. The endpoint sits alongside /fail2ban, which was already gated by the FAIL2BAN_ALLOWLIST option; /blacklist lacked equivalent gating.

Root Cause

The root cause is missing authentication and missing access control on a sensitive HTTP endpoint. The handler did not verify an authenticated session and did not consult any network allowlist before returning data. The fix introduces a general __is_allowlisted helper and adds a new BLACKLIST_ALLOWLIST configuration option. When neither BLACKLIST_ALLOWLIST nor FAIL2BAN_ALLOWLIST is set, the endpoint denies unauthenticated requests by default.

Attack Vector

The attack vector is network-based and requires no privileges or user interaction. An attacker sends an unauthenticated HTTP request to the /blacklist path on an exposed Maltrail server and receives blacklist contents.

python

# Security patch in core/httpd.py - gate /blacklist like /fail2ban
            return PING_RESPONSE

-        def __is_fail2ban_allowed(self):
-            allowlist = getattr(config, "FAIL2BAN_ALLOWLIST", None)
+        def __is_allowlisted(self, *options):
+            """Is the caller's IP in the first configured allowlist among `options`?
+
+            Deny when none of them is set: these endpoints hand out source IPs from the event log,
+            so an unset allowlist has to mean "nobody", not "everybody".
+            """
+            allowlist = None
+            for option in options:
+                allowlist = getattr(config, option, None)
+                if allowlist:
+                    break
            if not allowlist:
                return False  # secure by default

Source: Maltrail Commit d95868d

Detection Methods for CVE-2026-91002

Indicators of Compromise

Unauthenticated HTTP GET requests to the /blacklist path on Maltrail servers from unexpected source IPs.
Web server access logs showing repeated /blacklist retrievals outside of configured firewall-automation hosts.
External scanners fingerprinting Maltrail HTTP responses on TCP port 8338 (default listener).

Detection Strategies

Review Maltrail HTTP access logs for requests to /blacklist that do not originate from allowlisted management or firewall-automation subnets.
Correlate /blacklist requests against session authentication events to identify unauthenticated pulls.
Use network flow telemetry to identify Internet-exposed Maltrail instances that should be firewalled or placed behind a reverse proxy.

Monitoring Recommendations

Alert on any 200 OK response to /blacklist returned to a non-allowlisted client IP.
Track version banners of deployed Maltrail sensors and flag any instance running 3.0.1 or earlier.
Monitor for public exploit tooling referencing the GitHub Gist proof of concept.

How to Mitigate CVE-2026-91002

Immediate Actions Required

Upgrade Maltrail to version 3.1 or later, which includes commit d95868dff3da4d3bd4f942837a26cb7c73a797ae.
If immediate upgrade is not possible, restrict network access to the Maltrail HTTP interface using host firewall rules or a reverse proxy that enforces authentication.
Audit HTTP logs for prior unauthenticated access to /blacklist and treat any exposed source-IP data as compromised reconnaissance data.

Patch Information

The fix is available in the Maltrail 3.1 release. The vendor patched the issue the same day it was reported by gating the /blacklist endpoint on either an authenticated session or the new BLACKLIST_ALLOWLIST configuration option. When BLACKLIST_ALLOWLIST is unset, the code falls back to FAIL2BAN_ALLOWLIST; if both are unset, the endpoint is blocked. See the patch commit for full details.

Workarounds

Place the Maltrail HTTP listener behind a reverse proxy that enforces authentication and IP allowlisting.
Block inbound access to the Maltrail HTTP port from untrusted networks using perimeter or host firewalls.
Once upgraded, explicitly configure BLACKLIST_ALLOWLIST in maltrail.conf to the specific firewall-automation hosts that need to consume the blacklist.

bash

# Configuration example for maltrail.conf after upgrading to 3.1
# If unset/empty, /fail2ban will be blocked
FAIL2BAN_ALLOWLIST 127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

# Who may pull /blacklist (same syntax as FAIL2BAN_ALLOWLIST).
# Unset -> FAIL2BAN_ALLOWLIST is used; if that is unset too, /blacklist is blocked.
# An authenticated session is always allowed, so this only governs unauthenticated
# pullers such as firewall automation.
BLACKLIST_ALLOWLIST 127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16