Checkmk EUVD-2026-107474

Exploitation requires ALL of: (1) local access to the monitored host as a low-privileged user; (2) a Checkmk agent with the 'mk-oracle' plugin explicitly enabled; and (3) attacker write permission to the Oracle client library directory of an Oracle home listed in the 'oratab' file, OR write permission to the 'oratab' file itself. Limiting factors: the plugin is not enabled by default in all deployments, the vulnerable path must be attacker-writable (a configuration/permission precondition reflected in CVSS AT:P and AC:H), and the attacker must already possess a local foothold (PR:L). These combined prerequisites make opportunistic or remote exploitation infeasible.

This is a genuine but constrained local privilege escalation, not a drop-everything priority. The CVSS 4.0 vector (AV:L/AC:H/AT:P/PR:L/UI:N) and the 5.2 Medium score are internally consistent with the description: exploitation is local, already requires low-privilege access, and carries both high attack complexity (AC:H) and a present attack requirement (AT:P) - namely that an agent has the 'mk-oracle' plugin enabled and that the attacker already holds write access to a privileged Oracle path. No EPSS score was provided, there is no CISA KEV listing, and no public POC is referenced, so all three exploitation-likelihood signals are either absent or negative; the only signal of active interest is that the vendor (Checkmk) self-reported it. The impact side is serious where applicable - code execution as root (reflected as SC:H/SI:H/SA:H, a scope/subsequent-system compromise) - but the chain of preconditions (local foothold + write access to the Oracle client library dir or oratab + plugin enabled) sharply limits real-world exploitability. Net: a legitimately dangerous outcome gated behind demanding prerequisites, best treated as a standard-priority patch rather than an emergency.

On a Checkmk-monitored host running the 'mk-oracle' plugin as root, a low-privileged local user who can write to the Oracle client library directory (or to the oratab file that points to it) plants a malicious shared library or Oracle home entry. When the root-run plugin next executes and loads the attacker-controlled library via its untrusted search path, the attacker's code runs as root. No public exploit code is identified at time of analysis.