CVE-2026-79916 in MaxKB
Summary
by MITRE • 09/22/2026
MaxKB is an open-source AI assistant for enterprise. Prior to 2.10.5-lts, authenticated workspace members can inject control characters into AWS Bedrock access_key_id and secret_access_key fields that _update_aws_credentials writes to /root/.aws/credentials without safe parsing. An attacker can append a new AWS profile containing credential_process, then select that profile during a later model-validation request so botocore executes an attacker-controlled command as root. This vulnerability is fixed in 2.10.5-lts.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in MaxKB prior to version 2.10.5-lts represents a critical server-side security flaw rooted in improper input validation and unsafe file handling practices within the application's AWS credential management module. As an open-source AI assistant designed for enterprise environments, MaxKB requires integration with cloud services such as Amazon Web Services Bedrock to function effectively. To facilitate this, authenticated workspace members are permitted to configure access keys via specific fields that trigger a write operation to the /root/.aws/credentials file on the host system. The core technical flaw lies in the _update_aws_credentials method, which fails to sanitize or validate control characters and special symbols before writing user-supplied data directly into this configuration file without safe parsing mechanisms. This lack of input validation allows an authenticated attacker to inject arbitrary content that deviates from standard AWS credential formatting expectations.
By exploiting this weakness, an attacker can craft a malicious payload containing newlines and other control characters to append a completely new AWS profile section to the credentials file. Crucially, this injected profile includes a command_process directive pointing to an executable script or binary controlled by the attacker. The severity of this vulnerability is significantly amplified because the application writes these files with root privileges. Consequently, when a subsequent operation triggers botocore, the underlying Python library responsible for AWS SDK interactions, it reads the compromised credentials file and executes the malicious command_process entry as the root user. This results in arbitrary code execution with the highest level of system privilege available on the host machine, effectively granting full control over the server infrastructure to any authenticated workspace member who can manipulate these specific configuration fields.
From a classification perspective, this vulnerability aligns closely with CWE-94, which describes Improper Control of Generation of Code (Code Injection), specifically through unsafe file writes and command execution via configuration files. Furthermore, it maps directly to MITRE ATT&CK technique T1059, Command and Scripting Interpreter, as the attacker leverages the application's own functionality to execute system commands. The attack vector is classified under Remote Code Execution with Privilege Escalation, where initial access is gained through valid authentication credentials, but the impact escalates due to the elevated execution context of the vulnerable component. This scenario highlights a dangerous pattern often seen in applications that handle sensitive configuration data without implementing strict schema validation or using secure serialization methods for file I/O operations involving system-level paths.
The operational impact of this vulnerability is severe, as it allows any authenticated user within an enterprise workspace to compromise the integrity and confidentiality of the entire server hosting MaxKB. Once root access is achieved through the botocore execution context, attackers can exfiltrate sensitive data installed on the host, install persistent backdoors, pivot to other internal network segments, or disrupt service availability by modifying system configurations. Given that AWS credentials are often tied to broader cloud infrastructure permissions, there is also a risk of lateral movement into associated cloud resources if the compromised root account has access keys with elevated IAM policies. The vulnerability persists until users upgrade to version 2.10.5-lts or later, where the developers have implemented proper input sanitization and secure parsing logic for credential fields.
To mitigate this issue immediately in environments that cannot yet be upgraded, administrators should restrict file system permissions on /root/.aws/credentials to prevent unauthorized writes by application processes if possible, although this may break functionality. More effectively, organizations should enforce strict network segmentation to limit the exposure of MaxKB instances and ensure that service accounts running the application operate with minimal privileges wherever feasible. Long-term remediation requires upgrading to the patched version 2.10.5-lts or newer, which addresses the root cause by ensuring that all user inputs destined for configuration files are validated against a strict whitelist of allowed characters and structures. Additionally, security teams should audit other areas of the application where external input is written to system paths without adequate sanitization to prevent similar injection vulnerabilities in future updates.