CVE-2026-113461 is a reminder that a monitoring plugin's local inputs are part of its security boundary. Checkmk 2.5.0p14 added loading of individual Oracle home libraries for instances listed in oratab. The implementation did not properly validate the permissions of those libraries, allowing a local user with write access to execute code as root when the mk-oracle plugin was enabled.
The vendor fixed the issue in Checkmk 2.5.0p15. The fixed release loads a library only as the user who owns the file or rejects it. The CVE is rated 5.2 Medium under CVSS 4.0 and is associated with CWE-426 and CWE-829. CISA ADP enrichment records exploitation as none and automatable as no.
What the public evidence supports
The official Checkmk Werk identifies exactly one affected release, 2.5.0p14, and the fixed release, 2.5.0p15. It names the relevant plugin and describes the write-access requirement for the library or oratab. It also says permissions_check must be set to yes for validation behavior to be enabled.
The public record does not describe an unauthenticated remote exploit, a public proof of concept or confirmed in-the-wild activity. Claims beyond local privilege escalation would need additional evidence. The narrow scope does not remove the risk, especially on multi-user Oracle hosts where a low-privileged account may have an unexpected write path.
Why the bug occurred
oratab tells mk-oracle where Oracle instances and their home directories are located. The vulnerable implementation trusted the libraries found there without adequately checking whether another user could modify them. When the agent loaded those libraries, the code inherited the agent's privilege level.
The fix changes the trust decision at the point of loading. Ownership now matters, and a library that fails the rule is not used. This approach addresses the specific path by which a writable library could become privileged code.
Residual risk after upgrading
An upgrade removes the vulnerable loading behavior, but it does not automatically fix file permissions or configuration drift. Systems can still have an unsafe Oracle home layout, a disabled permission check or an unused plugin that expands the attack surface.
Check the effective mk-oracle configuration after the update. Confirm that permissions_check is enabled where Oracle monitoring is required. Review the owner and permissions of every library named by oratab, including parent directories that an ordinary user could rename or replace.
Investigate any library rejection in the agent output. A rejection may indicate a legitimate ownership problem that needs correction, or it may reveal an unauthorized file change. The security response should preserve evidence before the path is repaired.
Closure criteria
A host can be considered remediated when the agent runs 2.5.0p15 or later, the plugin configuration is understood and approved, only trusted administrators can modify the libraries and oratab, and a controlled test shows that an unsafe library is rejected. A version report alone is insufficient.
Fleet closure adds two checks. The inventory should include temporary, test and disaster-recovery agents, and the review should cover shared accounts and ACL inheritance. The monitoring team should retain the evidence long enough to compare later configuration changes against the post-patch baseline.
External exposure
ZoomEye's title="Checkmk" Search returned 2,429 matches, while vul.cve="CVE-2026-113461" returned 0. The first number identifies a Checkmk-related web fingerprint population. It does not confirm vulnerable agents or local write access. The second is a separate CVE-indexed observation and does not prove that no vulnerable endpoint exists.
External measurement is useful for finding assets and business units that may be missing from an inventory. Closure still depends on local release, plugin and permission evidence.
Final assessment
The issue is a constrained but meaningful local privilege escalation. Its severity is medium because the attacker needs local access and a specific writable path. Its consequence is significant because successful execution can reach root. The fixed release and a clean file-permission model address both the software defect and the condition that made it dangerous.