CVE-2026-44847: MaxKB Authentication Bypass Vulnerability

CVE-2026-44847 Overview

CVE-2026-44847 is an authentication bypass vulnerability [CWE-287] in MaxKB, an open-source AI assistant platform for enterprise. Versions prior to 2.9.0 expose the webhook trigger endpoint /api/trigger/v1/webhook/{trigger_id} without authentication enforcement. The WebhookAuth class unconditionally returns (None, {}), which Django REST Framework interprets as successful authentication. Combined with optional per-trigger token verification and no backend enforcement of token requirements, any unauthenticated attacker who knows a valid trigger ID can invoke webhook triggers. The vulnerability is fixed in MaxKB version 2.9.0.

Critical Impact

Unauthenticated remote attackers can invoke arbitrary webhook triggers and execute their bound tasks, compromising the integrity of MaxKB workflows.

Affected Products

• MaxKB versions prior to 2.9.0
• 1Panel-dev MaxKB open-source AI assistant
• Deployments exposing the /api/trigger/v1/webhook/ endpoint

Discovery Timeline

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

Technical Details for CVE-2026-44847

Vulnerability Analysis

The vulnerability resides in MaxKB's webhook authentication layer. The application defines a WebhookAuth class intended to authenticate requests to the webhook trigger endpoint. Instead of validating credentials, the class unconditionally returns the tuple (None, {}). Django REST Framework treats this return value as a valid authenticated context, meaning every request passes authentication regardless of headers or tokens supplied.

The webhook endpoint accepts a trigger_id path parameter that maps to a configured trigger task. Each trigger optionally supports a verification token, but the backend never enforces that a token is required. Triggers configured without a token expose their bound actions to any caller. Triggers configured with a token still rely on a flawed authentication path that does not block missing or invalid tokens consistently.

An attacker who learns or guesses a valid trigger_id can invoke the endpoint to execute the trigger's bound task. The impact depends on the task definition but can include knowledge base mutations, automated workflow execution, and downstream integrations.

Root Cause

The root cause is improper authentication [CWE-287]. The WebhookAuth.authenticate method returns a success tuple without performing any credential check. The application also lacks a server-side policy that requires every trigger to have a token. This combination removes both the global authentication boundary and the per-resource access control.

Attack Vector

An attacker sends an HTTP request to /api/trigger/v1/webhook/{trigger_id} over the network. No authentication header, session, or API key is required. If the trigger_id corresponds to a configured trigger without a strictly verified token, the server executes the bound task and returns the result. Attackers can enumerate trigger IDs or harvest them from logs, browser history, or integration configurations.

No verified exploit code is publicly available. Refer to the GitHub Security Advisory and the GitHub Issue Document for technical details.

Detection Methods for CVE-2026-44847

Indicators of Compromise

• HTTP requests to /api/trigger/v1/webhook/{trigger_id} from unexpected source IP addresses or user agents.
• Webhook trigger executions without a corresponding authenticated user session or API client identifier.
• Bursts of requests enumerating different trigger_id values, indicating ID brute forcing.
• Trigger task executions occurring outside of expected business hours or scheduled windows.

Detection Strategies

• Inspect MaxKB application logs for requests to the webhook trigger path and correlate with authenticated session data.
• Deploy WAF or reverse proxy rules that log all requests to /api/trigger/v1/webhook/ and flag anonymous calls.
• Hunt for repeated 200 responses against varied trigger_id values from a single source.

Monitoring Recommendations

• Forward MaxKB access logs to a centralized logging or SIEM platform for retention and correlation.
• Alert on any successful webhook trigger invocation that lacks a valid token header.
• Track baseline trigger execution counts and alert on statistical anomalies.

How to Mitigate CVE-2026-44847

Immediate Actions Required

• Upgrade MaxKB to version 2.9.0 or later, which contains the official fix.
• Restrict network access to the /api/trigger/v1/webhook/ endpoint using firewall or reverse proxy rules until the upgrade is complete.
• Audit all existing trigger configurations and rotate any trigger IDs that may have been exposed.
• Review historical access logs for unauthorized invocations and identify any tasks that executed without authorization.

Patch Information

The maintainers fixed CVE-2026-44847 in MaxKB version 2.9.0. The fix enforces authentication on the webhook trigger endpoint and validates trigger tokens on the backend. See the GitHub Security Advisory GHSA-r3j3-j58q-rjpp for full remediation details.

Workarounds

• Block external access to the /api/trigger/v1/webhook/ path at the reverse proxy or load balancer until the patch is applied.
• Require an authenticated proxy or VPN for any client invoking webhook triggers.
• Disable or delete unused triggers to reduce the attack surface.
• Rotate trigger IDs and assign strong, randomly generated tokens to every active trigger.

# Example nginx configuration to restrict webhook trigger endpoint to trusted IPs
location /api/trigger/v1/webhook/ {
    allow 10.0.0.0/8;
    allow 192.168.0.0/16;
    deny all;
    proxy_pass http://maxkb_backend;
}