MaxKB CVE-2026-77522

Requires an authenticated low-privileged MaxKB workspace user (PR:L) with access to the knowledge-base web-document import or synchronization feature. The exploit needs no user interaction and no special non-default configuration beyond that feature being usable - the crawler (Fork.fork) unconditionally calls requests.get with verify=False and applies no scheme, loopback, link-local, private, or reserved-address restrictions. Real impact is amplified in cloud deployments reachable to instance metadata endpoints (e.g. AWS/GCP IMDS) or with internal HTTP services on the MaxKB server's network; it is limited by the need for valid credentials and by whatever internal targets are actually reachable from the server. No fixed version is available as of this review, so mitigation depends on network egress controls (block IMDS/internal ranges) rather than a patch.

This is a genuine but modest-severity SSRF (CWE-918). The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N = 4.3) confirms network reach with low complexity but requires an authenticated low-privileged workspace user (PR:L) - so it is not an unauthenticated internet-facing bug. Notably the vendor scored the impact as C:N/I:L, which understates the primary harm: the description explicitly states the crawler's HTTP response body is returned as imported document content, so an attacker can READ cloud instance-metadata (e.g. IMDS credentials) and internal HTTP services - that is a confidentiality impact (C:L), not merely integrity. I assess the impact axis differently: the practical risk is data exfiltration of internal/metadata content, which in cloud deployments backed by exposed IMDSv1 can escalate to credential theft. No EPSS, KEV, or public POC is provided, so per available signals this is 'no public exploit identified at time of analysis' and there is no evidence of active exploitation. Given PR:L gating, niche product footprint, and no fix yet available, this is a real-but-not-urgent priority for MaxKB operators rather than a widespread emergency.

A low-privileged but authenticated MaxKB workspace user creates a knowledge base and adds a web document whose URL points at an internal address such as http://169.254.169.254/latest/meta-data/ or an internal admin service. Because Fork.fork calls requests.get with verify=False and no scheme/loopback/private/link-local filtering, the MaxKB server fetches it and stores the response body as document content the attacker can then read back, exposing cloud metadata/credentials or internal service data. No public exploit code is identified at time of analysis, but the attack is trivial to reproduce via the normal document-import UI.