CVE-2026-91048 in Karaf
Summary
by MITRE • 09/29/2026
The jdbc shell command scope shipped no org.apache.karaf.command.acl.jdbc.cfg. Karaf's command guard (SecuredSessionFactoryImpl) treats a command with no matching ACL rule as allowed, so any authenticated shell session (including one holding only the viewer role) could run every jdbc:* command. jdbc:ds-create stores a fully attacker-controlled JDBC URL into a pax-jdbc-config factory Configuration with no validation. pax-jdbc-config reactively turns that into a live DataSource. Several JDBC drivers run code or SQL at connection time based on URL parameters (e.g. H2 INIT=RUNSCRIPT), so a viewer-level shell user could reach arbitrary code execution, bypassing the admin-role gate that already protects shell:exec. This is a privilege-escalation-to-RCE chain, not merely an "admin misconfiguration".
The same applies to jms:* shell commands.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/29/2026
This vulnerability represents a critical privilege escalation path within Apache Karaf environments that leverage JDBC and JMS shell extensions for database or message queue management. The core issue stems from the interaction between Karaf's command guard mechanism, specifically SecuredSessionFactoryImpl, and its Access Control List (ACL) configuration handling. When specific ACL rules are missing for certain commands, such as those in the jdbc:* namespace, the security framework defaults to an allow-all policy rather than a deny-by-default stance. This design flaw means that any authenticated user with shell access, even one restricted to the viewer role which is typically intended for read-only operations, can execute every command within these namespaces without restriction. The absence of explicit configuration files like org.apache.karaf.command.acl.jdbc.cfg effectively leaves these administrative interfaces wide open to lower-privileged users who should not have such capabilities.
The technical exploitation vector relies heavily on the behavior of pax-jdbc-config and its reactive processing of factory Configuration objects. When a user executes commands like jdbc:ds-create, they can supply fully attacker-controlled JDBC URLs as parameters. The system accepts these inputs without performing any validation or sanitization checks before storing them in the configuration store. Once stored, pax-jdbc-config automatically processes this new configuration and instantiates a live DataSource object based on the provided URL. This automatic instantiation is where the severity of the vulnerability escalates from simple unauthorized access to remote code execution. Many JDBC drivers are designed to execute initialization scripts or SQL statements defined within connection parameters when establishing a link, allowing an attacker to inject malicious payloads directly into the application context through standard configuration fields.
The operational impact is severe because it bypasses existing security controls that protect more obvious attack surfaces like shell:exec. While Karaf may restrict direct command execution for lower-privileged users via admin-role gates, attackers can circumvent these restrictions by abusing legitimate administrative commands related to data source creation. For instance, using the H2 database driver as an example, an attacker could include parameters such as INIT=RUNSCRIPT in the JDBC URL to trigger the loading and execution of arbitrary SQL scripts or Java code during connection initialization. This chain effectively transforms a low-privilege shell session into one with full remote code execution capabilities within the Karaf container's JVM process. The same logic applies to JMS commands, where similar misconfigurations could allow unauthorized users to manipulate message broker connections in ways that compromise system integrity.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management and CWE-78 OS Command Injection via JDBC URL parameters. It also maps to MITRE ATT&CK techniques involving privilege escalation and command execution through application components. The root cause is not merely an administrative oversight but a fundamental flaw in how the security framework handles missing ACL rules, treating them as permissive rather than restrictive. This behavior contradicts standard secure coding practices which advocate for deny-by-default policies in access control systems.
Mitigation strategies must address both the configuration gaps and the underlying architectural assumptions. Administrators should immediately ensure that comprehensive ACL configurations are defined for all shell command namespaces, explicitly denying execution rights to viewer roles unless absolutely necessary. It is crucial to review org.apache.karaf.command.acl.jdbc.cfg and similar files to enforce strict role-based access control. Additionally, input validation must be implemented at the application level to sanitize JDBC URLs before they are processed by pax-jdbc-config. Limiting the types of drivers that can be instantiated or restricting specific dangerous parameters within connection strings would further reduce the attack surface. Organizations should also consider upgrading to versions where these ACL handling behaviors have been corrected, ensuring that missing rules result in denied access rather than granted permissions. Regular audits of shell command permissions and continuous monitoring for unauthorized configuration changes are essential steps in maintaining a secure Karaf environment against such privilege escalation threats.