AI analysis
Apache Karaf shipped the jdbc shell command scope without an org.apache.karaf.command.acl.jdbc.cfg file, and its command guard allows any command that has no matching ACL rule. Any authenticated shell session, including one limited to the viewer role, can therefore run every jdbc:* command. jdbc:ds-create writes an attacker-controlled JDBC URL into a pax-jdbc-config factory configuration that becomes a live DataSource, and some JDBC drivers execute code or SQL from URL parameters at connection time, producing arbitrary code execution that bypasses the admin-role gate on shell:exec. The same missing authorization applies to jms:* shell commands. No public proof-of-concept is known, the issue is not in CISA KEV, and CVSS has not yet been scored.
What to do: Install the Apache Karaf release that ships command ACL files for the jdbc and jms scopes as soon as Apache publishes it. Until then, limit shell access to trusted administrators and add explicit ACL rules so jdbc:* and jms:* require the admin role. Review pax-jdbc and JMS configurations for DataSources or connection factories created from low-privilege shell sessions.
Estimated exposure
—No basis for an estimate.
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
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.