CVE-2026-45413: MaxKB Information Disclosure Vulnerability

CVE-2026-45413 Overview

CVE-2026-45413 affects MaxKB, an open-source AI assistant for enterprise environments. Versions prior to 2.9.1 store user passwords using unsalted MD5 hashes. This weak cryptographic storage mechanism allows attackers with access to the password database to recover plaintext credentials through rainbow table lookups or GPU-accelerated brute force tools such as hashcat. The flaw is categorized as a use of a broken or risky cryptographic algorithm [CWE-328]. The MaxKB maintainers have addressed the issue in version 2.9.1.

Critical Impact

Attackers who obtain the MaxKB user database can recover plaintext passwords in minutes, enabling account takeover and credential reuse attacks against other services.

Affected Products

• MaxKB versions prior to 2.9.1
• 1Panel-dev MaxKB open-source AI assistant
• Enterprise deployments using MaxKB authentication

Discovery Timeline

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

Technical Details for CVE-2026-45413

Vulnerability Analysis

MaxKB stores user authentication credentials as MD5 hashes without applying a per-user salt. MD5 is a fast, broken hash function unsuitable for password storage. Modern GPUs compute billions of MD5 hashes per second, allowing attackers to exhaust common password dictionaries quickly. The absence of a salt enables precomputed rainbow tables to map hashes back to plaintext without per-hash computation.

This weakness becomes exploitable whenever the user table is exposed through a secondary vulnerability such as SQL injection, backup theft, insider access, or server compromise. The local attack vector reflects that adversaries need access to the stored hash material before exploitation begins.

Root Cause

The root cause is the selection of an unsalted MD5 hash for credential storage. Secure password storage requires an adaptive, salted key derivation function such as bcrypt, scrypt, or argon2id. MD5 lacks computational cost tuning, and the missing salt removes any protection against precomputed attacks across the user base.

Attack Vector

An attacker who gains read access to the MaxKB authentication store extracts the MD5 hash column. The attacker then runs a tool such as hashcat -m 0 against the hashes, using wordlists, masks, or rainbow tables. Recovered passwords enable direct authentication to MaxKB and credential stuffing against connected enterprise systems. The vulnerability does not require network exploitation of MaxKB itself, but it amplifies the impact of any prior database disclosure.

No public exploit code is required because the attack uses standard password cracking tooling. See the GitHub Security Advisory for additional technical context.

Detection Methods for CVE-2026-45413

Indicators of Compromise

• Unexpected successful logins to MaxKB accounts from new geolocations or IP ranges
• Bulk authentication attempts against MaxKB user accounts following a database exposure event
• Presence of 32-character hexadecimal hash values in MaxKB database backups copied to external locations
• Evidence of hashcat, john, or rainbow table artifacts on systems with access to MaxKB data

Detection Strategies

• Audit MaxKB authentication logs for password reuse patterns and rapid successful logins across multiple accounts
• Inspect the MaxKB user table to confirm the hashing algorithm in use after upgrade
• Correlate MaxKB login events with credential leak feeds to identify reused exposed passwords
• Monitor file system access to MaxKB database files and backups for unauthorized read operations

Monitoring Recommendations

• Enable verbose authentication logging in MaxKB and forward logs to a centralized SIEM
• Alert on administrative database export commands targeting the MaxKB schema
• Track failed-to-successful login transitions on MaxKB accounts as a credential-cracking signal
• Review service accounts and API tokens issued by MaxKB for unexpected activity following the disclosure date

How to Mitigate CVE-2026-45413

Immediate Actions Required

• Upgrade MaxKB to version 2.9.1 or later without delay
• Force a password reset for every MaxKB user account after upgrading
• Rotate any API keys, session tokens, or integration credentials managed within MaxKB
• Audit recent database exports, backups, and administrative access to determine whether hashes have been exposed

Patch Information

The vulnerability is fixed in MaxKB version 2.9.1. The patch replaces the unsalted MD5 hashing scheme with a secure password storage mechanism. Administrators must apply the upgrade and trigger a credential reset, because the upgrade alone cannot recover the original plaintext to rehash. Refer to the GitHub Security Advisory GHSA-2m4c-mcq5-q8xq for release details.

Workarounds

• Restrict network access to MaxKB administration interfaces using firewall rules or reverse proxy controls
• Limit database-level access to MaxKB tables to the minimum service accounts required
• Enforce strong, unique passwords and multi-factor authentication for all MaxKB users until the patch is applied
• Encrypt MaxKB database backups at rest and tightly control access to backup storage

# Configuration example: upgrade MaxKB via Docker and force credential rotation
docker pull 1panel/maxkb:v2.9.1
docker stop maxkb && docker rm maxkb
docker run -d --name=maxkb -p 8080:8080 \
  -v ~/.maxkb:/var/lib/postgresql/data \
  1panel/maxkb:v2.9.1
# After upgrade, log in as administrator and reset all user passwords