The vulnerability arises because the jdbc shell command scope is shipped without an ACL configuration file. The command guard interprets a command with no ACL rule as allowed, so any authenticated shell session—including one that only has the viewer role—can execute every jdbc:* command. Using the jdbc:ds-create command, an attacker can store a fully attacker‑controlled JDBC URL in a pax-jdbc-config factory configuration without any validation. When that configuration is activated, the driver may execute code or SQL during connection establishment based on URL parameters (for example, H2’s INIT=RUNSCRIPT). This chain allows a viewer‑role user to achieve arbitrary code execution, effectively bypassing the admin‑role restriction that protects the shell:exec command. This is a classic privilege‑escalation‑to‑RCE scenario and not an accidental misconfiguration, because the base system allows a low‑privileged user to perform a privileged action through missing authorization. The flaw results from improper configuration handling in the command guard and a lack of input validation for JDBC URLs within the pax-jdbc-config component. It can lead to total compromise of the affected Karaf instance.

The issue affects the Apache Karaf product from the Apache Software Foundation. There is no explicit version range listed in the CNA data, so all releases that use the default unsecured jdbc shell command scope are potentially impacted.

The vulnerability is encoded in an authenticated shell session, so an attacker needs to authenticate as a viewer or higher role. The CVSS score is 9.8, indicating a high severity impact. The EPSS score is below 1 %, indicating that exploitation is currently rare, and the vulnerability is not listed in CISA’s KEV catalog. However, because the exploitation path requires only a shell session and does not involve complex zero‑day vectors, the likelihood of discovery and exploitation remains non‑negligible. The most probable attack vector is via a legitimate remote Karaf shell session obtained either through normal authentication or an existing compromised account. Once authenticated, the attacker can run jdbc:ds-create with a malicious JDBC URL and trigger arbitrary code execution. Overall, the combination of privilege escalation, lack of ACL enforcement, and driver‑level code execution means this flaw poses a significant risk to affected deployments.