CVE-2023-6740 is a high severity (CVSS 8.8) privilege escalation in the jar_signature agent plugin of Checkmk, fixed in 2.2.0p18, 2.1.0p38 and 2.0.0p39. A malicious oracle user could get root. Deploy the new plugin or disable it. Hosts without that plugin are not in scope.
What's affected
The vendor advisory (Werk 16163) lists the affected versions as 2.2.0, 2.1.0 and 2.0.0 (end of life) and older, and the fixed releases as 2.2.0p18, 2.1.0p38, 2.0.0p39 and 2.3.0b1 builds. The plugin is configured by the bakery rule named Signatures of certificates in JAR files, so only hosts that use that rule are in scope.
The vendor classifies the change as Major and incompatible for users of the plugin, and says to deploy the new plugin version or disable it to avoid risk.
How to check if you're exposed
Look for the plugin on hosts that run Oracle monitoring.
ls /usr/lib/check_mk_agent/plugins/ | grep -i jar_signature
In the Checkmk interface, review the agent bakery rules and see whether the Signatures of certificates in JAR files rule is assigned to any host. Then compare your Checkmk version to the fixed releases.
What to do now
- Update Checkmk to 2.2.0p18, 2.1.0p38, 2.0.0p39 or newer.
- Rebake and redeploy agents so hosts receive the corrected jar_signature plugin.
- If you cannot update, disable the jar_signature plugin, as the vendor advises.
- Review who can write to JAVA_HOME directories on Oracle hosts.
Why it matters
According to the vendor, the plugin ran as root but invoked the jarsigner binary from a directory the oracle user controlled. A malicious oracle user could replace jarsigner with their own script in the JAVA_HOME directory, and root would run it. The fix runs jarsigner as the oracle user instead.
The record tags CWE-427, uncontrolled search path element, and CWE-269. The pattern is simple and common: a privileged process executes something from a place a less privileged user can write to. The same shape shows up in installers, cron jobs and backup agents.
Desktop and agent software is easy to miss because it sits outside the usual server patch cycle. Build a list of where it runs, push the update through your software deployment tool, and confirm the installed version afterward rather than trusting the job status.
Weakness class in the record: CWE-427 (Uncontrolled Search Path Element) CWE-269 (Improper Privilege Management).
Quick check
What if we do not use the JAR signature rule?
Then the plugin is not deployed by the bakery on those hosts and the specific path in the advisory does not apply. Updating to a fixed release is still sensible.
How do I confirm the fix landed?
Check the version on a sample of hosts after rollout and keep the output as evidence. Deployment tools can report success while some hosts miss the update.
Sources
Last reviewed: 19 October 2026.
