CVE-2025-64511: Maxkb RCE Vulnerability

CVE-2025-64511 Overview

CVE-2025-64511 affects MaxKB, an open-source AI assistant for enterprise deployments developed by 1Panel-dev. The vulnerability exists in MaxKB versions prior to 2.3.1 and resides in the tool module. Authenticated users can execute Python code that reaches internal network services, including databases, even though the code runs inside a sandbox. The flaw is classified as Server-Side Request Forgery [CWE-918]. Version 2.3.1 remediates the issue.

Critical Impact

Authenticated attackers can pivot from the MaxKB sandbox to internal network services, exposing databases and other backend systems to unauthorized access and data compromise.

Affected Products

• MaxKB versions prior to 2.3.1
• 1Panel-dev MaxKB open-source AI assistant
• Self-hosted MaxKB enterprise deployments

Discovery Timeline

• 2025-11-13 - CVE-2025-64511 published to NVD
• 2025-12-04 - Last updated in NVD database

Technical Details for CVE-2025-64511

Vulnerability Analysis

MaxKB exposes a tool module that allows users to author and execute Python code as part of AI assistant workflows. The execution environment is wrapped in a sandbox intended to restrict access to the host and surrounding infrastructure. The sandbox boundary fails to constrain outbound network access. As a result, Python code executed inside the tool module can issue requests to internal network endpoints reachable from the MaxKB server.

This behavior matches the Server-Side Request Forgery pattern described in [CWE-918]. Internal services such as databases, metadata endpoints, administrative panels, and other backend APIs are exposed through the application server's network position. An attacker with low-privilege authenticated access to MaxKB can interact with these services directly.

The attack does not require user interaction and can be triggered over the network. Confidentiality, integrity, and availability impacts are all rated high under the published CVSS vector.

Root Cause

The sandbox surrounding the Python tool module restricts code execution semantics but does not enforce egress network controls. Internal hostnames, loopback addresses, and private IP ranges remain reachable from sandboxed code. The application trusts user-supplied tool code to operate within the intended scope without validating destination targets for outbound connections.

Attack Vector

An authenticated MaxKB user creates or modifies a tool that contains Python code. The code opens connections to internal targets reachable from the MaxKB host, such as 127.0.0.1, database service hostnames, or cloud metadata services. When the tool executes, the sandbox permits the network calls. The attacker receives responses or performs writes against the targeted backend, bypassing perimeter controls that assume only the MaxKB application interacts with these services.

The vulnerability manifests in MaxKB's tool execution path. See the GitHub Security Advisory GHSA-9287-g7px-9rp4 for vendor-provided technical details.

Detection Methods for CVE-2025-64511

Indicators of Compromise

• Outbound connections from the MaxKB application process to internal database ports (3306, 5432, 6379, 27017, 1433) that do not match normal application data flows.
• Tool module records or audit entries containing Python code with socket, requests, urllib, or database driver imports targeting private IP ranges or loopback addresses.
• Unexpected authentication attempts or query patterns on internal databases originating from the MaxKB server IP.
• Access attempts to cloud metadata endpoints such as 169.254.169.254 from the MaxKB host.

Detection Strategies

• Review MaxKB tool definitions for code referencing internal hostnames, private CIDR ranges, or sensitive backend ports.
• Correlate MaxKB application logs with network flow records to identify tool executions immediately followed by connections to non-application backends.
• Alert on first-seen destination pairs between the MaxKB host and internal services not previously contacted by the application.

Monitoring Recommendations

• Capture and retain process-level network telemetry from the MaxKB host for retrospective analysis.
• Monitor database authentication logs for connections originating from the MaxKB application identity outside normal query patterns.
• Track tool creation and modification events in MaxKB with the associated user identity for post-incident attribution.

How to Mitigate CVE-2025-64511

Immediate Actions Required

• Upgrade MaxKB to version 2.3.1 or later, which contains the vendor fix.
• Inventory existing tool module definitions and remove or quarantine any tools containing unexpected network or database calls.
• Rotate credentials for internal services reachable from the MaxKB host if exposure is suspected.
• Restrict MaxKB user accounts with tool authoring privileges to trusted administrators until the upgrade is complete.

Patch Information

MaxKB version 2.3.1 fixes the issue. Refer to the GitHub Security Advisory GHSA-9287-g7px-9rp4 for the official advisory and release notes.

Workarounds

• Apply network egress filtering on the MaxKB host to deny outbound traffic to internal subnets, loopback addresses, and cloud metadata endpoints.
• Place MaxKB in a network segment that cannot reach production databases or sensitive backend services.
• Disable or restrict the tool module for non-administrative users until the patch is applied.
• Enforce least-privilege credentials for any backend service that MaxKB legitimately needs to reach.

# Example host-level egress restriction using iptables
# Block MaxKB process traffic to private ranges except required destinations
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 169.254.169.254 -j REJECT