CVE-2026-77522 in MaxKB
Summary
by MITRE • 09/22/2026
MaxKB is an open-source AI assistant for enterprise. In version 2.10.3-lts and earlier, the knowledge web-document import and synchronization crawler passes an authenticated workspace user's URL to Fork.fork, which calls requests.get with verify=False and without restricting schemes, loopback, link-local, private, or reserved addresses. The response body is converted into imported document content, allowing a low-privileged user to read cloud metadata or internal HTTP services through the MaxKB server. No fixed version is available as of this review.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in MaxKB versions 2.10.3-lts and earlier represents a critical Server-Side Request Forgery (SSRF) flaw rooted in improper validation of user-supplied input during the knowledge base document import process. This open-source AI assistant for enterprise environments allows users to ingest documents from web sources by providing URLs, which are then fetched by an internal crawler mechanism. The core technical failure lies in how these URLs are processed before being passed to the underlying HTTP client library. Specifically, when a workspace user provides a URL for synchronization or import, the application utilizes Fork.fork to initiate the request via Python's requests.get method with the verify parameter explicitly set to False. This configuration disables SSL certificate verification, which is already a security anti-pattern in production environments as it exposes the system to man-in-the-middle attacks and identity spoofing by trusting any certificate presented by the target server without validation.
Beyond the insecure TLS handling, the more severe aspect of this vulnerability is the complete absence of URL scheme or destination address restrictions. The application does not validate whether the provided URL points to a safe external resource or attempts to access internal infrastructure components. By allowing arbitrary schemes and unrestricted IP addresses, including loopback (127.0.0.1), link-local, private network ranges (such as 192.168.x.x, 10.x.x.x, 172.16-31.x.x), and reserved address spaces, the vulnerability enables an authenticated low-privileged user to force the MaxKB server to make HTTP requests to internal services that are not intended for public access. This architectural oversight effectively turns the MaxKB application into a proxy tool capable of probing and interacting with the local network topology from within the trusted environment where the server resides.
The operational impact of this flaw is significant, particularly in enterprise deployments where cloud metadata endpoints or internal microservices may be accessible via localhost or private IP ranges. Attackers can leverage this SSRF to read sensitive data from cloud provider metadata services, such as AWS EC2 instance metadata service (IMDS) at 169.254.169.254, which often contains temporary security credentials and configuration details that could lead to full account compromise if exposed. Furthermore, the vulnerability allows for scanning of internal HTTP services running on non-standard ports or hidden administrative interfaces within the corporate network. Since the response body from these internal requests is converted directly into imported document content, attackers can exfiltrate data by observing how it appears in the knowledge base interface or through error messages and timing differences if blind SSRF techniques are employed. This capability effectively bypasses perimeter security controls that rely on IP whitelisting for sensitive internal services, as the traffic originates from a trusted application server rather than an external attacker's machine.
From a classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), specifically involving improper restriction of web resources to externally controlled servers and lack of validation for URL schemes or destination addresses. It also maps to MITRE ATT&CK technique T1557.002 Adversary-in-the-Middle, due to the disabled certificate verification allowing potential interception, although the primary attack vector is SSRF rather than active interception. The use of verify=False further exacerbates the risk by facilitating credential theft if an attacker can redirect requests through a malicious proxy during the initial connection phase.
Mitigation strategies for this vulnerability must address both the input validation and the HTTP client configuration immediately since no fixed version was available at the time of review. Administrators should implement strict allow-listing for URLs permitted in the knowledge import feature, restricting schemes to only http and https while blocking private IP ranges, loopback addresses, link-local scopes, and reserved network blocks using robust regular expressions or dedicated URL validation libraries that enforce these constraints before any network activity occurs. Additionally, the application code must be modified to enable SSL certificate verification by setting verify=True in all requests.get calls unless there is a specific, justified need for self-signed certificates managed through a trusted custom CA bundle. Network-level mitigations include configuring firewalls or reverse proxies to block outbound connections from the MaxKB server IP address to private and reserved IP ranges, thereby adding a layer of defense-in-depth that prevents exploitation even if application-side validation fails. Until an official patch is released by the vendor, these compensating controls are essential to maintain the integrity and confidentiality of enterprise data processed through the platform.