CVE-2026-42336: MaxKB AI Assistant SSRF Vulnerability

CVE-2026-42336 Overview

CVE-2026-42336 is a server-side request forgery (SSRF) bypass vulnerability in MaxKB, an open-source AI assistant for enterprise environments. The flaw affects MaxKB version 2.8.0 and earlier releases. The vulnerability resides in the OSS file service URL fetch functionality, where inconsistent DNS resolution between the validation step and actual request execution allows attackers to bypass SSRF protections. Authenticated attackers can leverage this time-of-check time-of-use (TOCTOU) condition to access internal network services that should be unreachable from external requests. The issue is classified under CWE-367 and is fixed in MaxKB version 2.8.1.

Critical Impact

Authenticated attackers can bypass SSRF validation to probe internal network services, enabling reconnaissance of cloud metadata endpoints, internal APIs, and lateral movement preparation.

Affected Products

• MaxKB versions 2.8.0 and prior
• 1Panel-dev MaxKB OSS file service component
• Enterprise deployments using MaxKB AI assistant functionality

Discovery Timeline

• 2026-05-26 - CVE-2026-42336 published to NVD
• 2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-42336

Vulnerability Analysis

The vulnerability is a classic DNS rebinding SSRF bypass rooted in a time-of-check to time-of-use (TOCTOU) race condition. MaxKB's OSS file service accepts user-supplied URLs and fetches their contents. To prevent SSRF, the application validates the destination hostname before issuing the HTTP request. However, the validation routine and the HTTP client perform independent DNS lookups. An attacker controlling an authoritative DNS server can return a public IP address during validation, then return an internal IP address (such as 127.0.0.1, 169.254.169.254, or RFC1918 addresses) during the subsequent fetch.

This gap between check and use defeats hostname allowlists and IP-range blocklists. The attacker reaches internal services without ever supplying a forbidden hostname. Cloud metadata services, internal admin panels, and unauthenticated microservices become reachable through the application's privileged network position.

Root Cause

The root cause is the absence of a single, pinned DNS resolution shared between the validation and fetch phases. The OSS file service performs two separate name resolutions, allowing the answer to change between calls. There is no caching of the validated IP, no enforcement that the connection use the resolved address, and no post-connection check that the peer address belongs to a permitted range.

Attack Vector

Exploitation requires low-privileged authentication on the MaxKB instance. The attacker hosts a domain whose DNS server alternates responses or uses a short TTL to swap between a public IP and an internal target. The attacker submits a URL referencing this domain to the OSS file fetch endpoint. MaxKB validates the first resolution, then re-resolves and connects to the internal address. Response data may be returned to the attacker or inferred through timing and error differentials. The vulnerability mechanism is documented in the GitHub Security Advisory GHSA-6m4p-9wwc-4q5q.

Detection Methods for CVE-2026-42336

Indicators of Compromise

• Outbound DNS queries from MaxKB hosts to attacker-controlled domains with unusually short TTL values.
• Application logs showing OSS file fetch requests where the resolved IP at connect time falls within RFC1918, loopback, or link-local ranges.
• HTTP requests from the MaxKB service account to cloud metadata endpoints such as 169.254.169.254 or internal management interfaces.

Detection Strategies

• Compare DNS resolution logs against subsequent TCP connection destinations for the MaxKB process to identify resolution mismatches.
• Alert on any egress from MaxKB containers or hosts targeting private IP space, loopback, or cloud metadata addresses.
• Inspect MaxKB application logs for repeated OSS URL fetch attempts referencing the same external hostname within short windows.

Monitoring Recommendations

• Forward MaxKB application logs and host-level network telemetry to a centralized analytics platform for correlation of DNS and connection events.
• Baseline normal OSS file fetch destinations and alert on deviations such as private addressing or unusual ASN destinations.
• Monitor authentication logs for accounts repeatedly invoking OSS URL fetch operations, which may indicate enumeration activity.

How to Mitigate CVE-2026-42336

Immediate Actions Required

• Upgrade MaxKB to version 2.8.1 or later, which contains the official fix for the DNS rebinding SSRF bypass.
• Restrict egress network access from MaxKB hosts to only the external endpoints required for normal operation.
• Audit recently created or low-privileged user accounts and review OSS file fetch activity for suspicious URLs.

Patch Information

The vulnerability is fixed in MaxKB version 2.8.1. Upgrade instructions and the full advisory are available in the GitHub Security Advisory GHSA-6m4p-9wwc-4q5q. Administrators should apply the upgrade before re-enabling external URL fetch features in production environments.

Workarounds

• Block outbound connections from MaxKB to internal CIDR ranges, loopback addresses, and cloud metadata endpoints at the network or service-mesh layer.
• Place MaxKB behind an egress proxy that performs its own DNS resolution and enforces destination IP allowlists after connection.
• Temporarily disable the OSS file URL fetch functionality if upgrade cannot be performed immediately.

# Example iptables rules to block MaxKB egress to internal ranges
iptables -A OUTPUT -m owner --uid-owner maxkb -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner maxkb -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner maxkb -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner maxkb -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner maxkb -d 127.0.0.0/8 -j REJECT