MaxKB CVE-2026-44847

Exploitation requires (1) network reachability to the MaxKB /api/trigger/v1/webhook/{trigger_id} endpoint and (2) knowledge of a valid trigger_id created in the target instance; no credentials, user interaction, or non-default configuration are needed, and the bypass works even when a per-trigger token has been configured because the backend does not enforce it. The practical limiting factor is the trigger_id value itself - it is not user-enumerable through the public UI and behaves as a weak shared secret, so risk is highest where trigger_ids leak via logs, integration configs, referrers, or third-party systems, and lower where instances are only reachable from trusted networks. Impact is bounded by what tasks the deployment has actually bound to webhook triggers, since invocation only executes pre-configured actions.

The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N scores 7.5 and reflects a network-reachable, low-complexity, unauthenticated attack producing high integrity impact with no confidentiality or availability impact - consistent with an attacker invoking arbitrary bound tasks but not directly reading data or crashing the service. No EPSS score, KEV listing, or SSVC decision is provided in the input, so probability of exploitation cannot be quantified; status is no public exploit identified at time of analysis. The main practical limiter is knowledge of a valid trigger_id (a UUID-like identifier), which is not in the URL path of normal users but may be exposed via logs, referrers, integrations, or guessable patterns; this caveat should temper raw CVSS severity. Integrity impact depends entirely on what tasks operators have bound to webhooks - ranging from low-risk notifications to high-risk automation such as model retraining, file ingestion, or shell-adjacent actions - so real-world risk is deployment-specific and warrants prioritized patching for any MaxKB instance exposed beyond a trusted network.

An attacker who has obtained a valid trigger_id - for example by scraping a misconfigured log endpoint, a public integration repository, browser referrer headers, or a leaked screenshot - sends an unauthenticated HTTP POST to /api/trigger/v1/webhook/{trigger_id} on an internet-exposed MaxKB instance. Because WebhookAuth returns (None, {}), DRF treats the request as authenticated, the optional token is not enforced, and MaxKB executes whatever task the operator bound to that trigger, such as ingesting attacker-controlled documents into the knowledge base or invoking automation actions. No POC is referenced in the input, but the fix commit and advisory make the bypass mechanism transparent and trivial to reproduce.