Werk #22135: REST API: updating a service's discovery phase now requires service management permissions
| Component | REST API | ||||||||
| Title | REST API: updating a service's discovery phase now requires service management permissions | ||||||||
| Date | Sep 15, 2026 | ||||||||
| Level | Trivial Change | ||||||||
| Class | Security Fix | ||||||||
| Compatibility | Incompatible - Manual interaction might be required | ||||||||
| Checkmk versions & editions |
|
The REST API endpoint that updates the discovery phase of a single service
(PUT .../objects/host/{host_name}/actions/update_discovery_phase/invoke)
checked only the four "Service discovery: move to ..." permissions, together
with read access to the host.
Every other endpoint in the service discovery family, including the read-only ones, additionally requires "Make changes, perform actions" and "Manage services". The service discovery page in the GUI likewise refuses the very same single-service move without "Manage services", and offers no controls for it.
As a result, a role that kept the four discovery-target permissions could still
move, disable or remove services through this endpoint after "Manage services"
-- or even "Make changes, perform actions", the permission that is meant to stop
a role from making any changes at all -- had been taken away from it. Each such
request rewrote the host's autochecks, added a "Disabled services" rule when the
target phase was ignored, and recorded the matching pending changes for the
next activation.
The endpoint now requires "Make changes, perform actions" and "Manage services"
in addition to the four discovery-target permissions. A request from a role that
lacks either of them is answered with 403 Forbidden and changes nothing.
If an API client used this endpoint while running as a role without these permissions, grant the role "Make changes, perform actions" and "Manage services", or switch it to a role that already has them.
This issue was found during internal review.
Who's Affected:
All editions are affected, but only in combination with custom roles. The built-in roles are not: "Administrator" and "Normal monitoring user" hold all of these permissions anyway, and "Guest user" holds none of the four discovery-target ones -- all four of which the endpoint demands, so requests from such a role were already refused. A site is affected if it has a role that keeps the four "Service discovery: move to ..." permissions while "Make changes, perform actions" or "Manage services" has been removed from it, and a user of that role can read at least one host (through their contact groups or through "Read access to all hosts and folders").
Affected Versions:
- 2.5.0
- 2.4.0
- 2.3.0
- 2.2.0 (EOL)
Mitigations:
If updating is not possible, remove the four "Service discovery: move to ..." permissions from every role that does not also hold "Make changes, perform actions" and "Manage services". The endpoint demands all four, so a role missing any one of them cannot use it. Note that this also removes the corresponding buttons from the service discovery page in the GUI for those roles.
Indicators of Compromise:
Every such request left a change behind in the audit log (Setup > Audit log): a
set-autochecks entry "Saved check configuration of host '...' with N services"
on the affected host, and, for moves to the ignored phase, additionally a
new-rule entry for the "Disabled services" ruleset. The audit log records the
acting user for each change, so look for these entries attributed to users whose
role does not hold "Make changes, perform actions" and "Manage services".
Vulnerability Management:
We have rated the issue with a CVSS Score of 2.3 Low
(CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N) and assigned
CVE-2026-92004.