What is the CVSS score of CVE-2026-44847?

CVE-2026-44847 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N. EPSS exploitation probability: 0.1%.

Which versions of MaxKB are affected by CVE-2026-44847?

MaxKB (1Panel-dev) versions prior to 2.9.0 contain an authentication bypass in webhook triggers that exposes all orchestrated tasks to remote unauthenticated execution.. A patch is available.

How to fix or mitigate CVE-2026-44847?

24 hours: Locate all MaxKB deployments and apply immediate network controls-restrict webhook endpoint access via firewall IP whitelisting, and disable webhooks if not actively in use. 7 days: Establish staging environment for version 2.9.0 upgrade; monitor MaxKB project for official release. 30 days: Deploy MaxKB version 2.9.0 or later to all production instances; post-deployment, verify webhook authentication is enforced.

MaxKB CVE-2026-44847

EUVD-2026-31987 HIGH

Improper Authentication (CWE-287)

2026-05-26 GitHub_M

Python Authentication Bypass

7.5

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

High

Availability

None

Lifecycle Timeline

Patch available

May 26, 2026 - 22:02 EUVD

Analysis Generated

May 26, 2026 - 21:02 vuln.today

DescriptionGitHub Advisory

MaxKB is an open-source AI assistant for enterprise. Prior to 2.9.0, MaxKB's webhook trigger endpoint (/api/trigger/v1/webhook/{trigger_id}) is accessible without authentication. 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 to execute their bound tasks. This vulnerability is fixed in 2.9.0.

AnalysisAI

Authentication bypass in MaxKB (1Panel-dev) versions prior to 2.9.0 allows remote unauthenticated attackers to invoke webhook trigger endpoints and execute their bound tasks. The flaw stems from the WebhookAuth class unconditionally returning a successful authentication tuple, which Django REST Framework interprets as a valid identity, combined with no backend enforcement of per-trigger token requirements. No public exploit identified at time of analysis, but the trivial nature of the bypass and open-source visibility of the patch make exploitation straightforward for any attacker who can enumerate or guess trigger IDs.

Technical ContextAI

MaxKB is an open-source AI assistant platform built on Python/Django that exposes a REST API via Django REST Framework (DRF). DRF authentication classes are expected to return either None (anonymous) or a (user, auth) tuple representing an authenticated principal; the WebhookAuth class incorrectly returns (None, {}), which DRF treats as successful authentication of an anonymous user, satisfying any IsAuthenticated-style permission gate downstream. The trigger framework supports an optional per-trigger token, but token verification is not enforced server-side, so even triggers configured with tokens accept unauthenticated requests. This maps to CWE-287 (Improper Authentication) - the root cause is a faulty authentication primitive rather than missing authorization checks. The affected product is identified by CPE cpe:2.3:a:1panel-dev:maxkb:*:*:*:*:*:*:*:* covering all versions prior to the 2.9.0 fix.

RemediationAI

Vendor-released patch: upgrade MaxKB to version 2.9.0 or later, which fixes the WebhookAuth class and enforces per-trigger token verification on the backend (see GHSA-r3j3-j58q-rjpp at https://github.com/1Panel-dev/MaxKB/security/advisories/GHSA-r3j3-j58q-rjpp and issue https://github.com/1Panel-dev/MaxKB/issues/5213). Until the upgrade can be applied, restrict access to the /api/trigger/v1/webhook/{trigger_id} path at a reverse proxy or WAF by allowlisting only known integration source IPs, which will break any external SaaS that calls webhooks from dynamic IPs. Rotate all existing trigger IDs after patching so any IDs already harvested from logs, browser referrers, or third-party systems become invalid, and audit recently invoked triggers for unexpected calls; treat any task bound to a webhook (especially data ingestion or model actions) as potentially having been triggered by an unauthenticated party.