Open Redirect and XSS in Checkmk GmbH Checkmk Setup Search

Improper validation of the reset_url parameter of the Setup in-page search in Checkmk <2.5.0p15, <2.4.0p38, <2.3.0p51 and 2.2.0 (EOL) allows an attacker to execute arbitrary script in the session of an authenticated user with Setup access, or to redirect that user to an arbitrary external site, by tricking the user into opening a crafted URL and clicking the Reset button or submitting an empty search.

Checkmk GmbH Checkmk is affected in all editions on pages that use the PageMenuSearch in-page search; exploitation requires the victim to have Setup access.

• 2.5.0 branch: affected when <2.5.0p15; the vendor lists 2.5.0p15 as fixed.
• 2.4.0 branch: affected when <2.4.0p38; the vendor lists 2.4.0p38 as fixed.
• 2.3.0 branch: affected when <2.3.0p51; the vendor lists 2.3.0p51 as fixed.
• 2.2.0: affected and end of life; the supplied record and advisory do not list a fix for this branch.

The vendor Werk also lists 3.0.0b1 as not yet released in its fix table. The supplied record does not establish the status of other stable or parallel branches, so they should not be assumed to be unaffected.

The Setup in-page search uses the reset_url parameter to construct the target URL for the Reset button and for the empty-search form submission path. Those paths did not validate the scheme or origin of the attacker-controlled value.

1. An attacker creates a Setup URL containing a malicious reset_url and tricks a user into opening it.
2. A javascript: value can execute arbitrary script in the victim's session when the victim clicks Reset or submits an empty search.
3. An absolute URL for another origin can redirect the user to an arbitrary external site.

The victim must be authenticated and have Setup access. Checkmk states that the fix restricts reset_url to same-origin relative URLs. The public advisory does not specify the exact endpoint or other URL-parser implementation details.

The issue is remotely reachable through a crafted URL and requires active user interaction. The victim must have an authenticated session with Setup access, then click Reset or submit an empty search; Checkmk describes the action as one click.

The supplied assessment identifies no authentication requirement for the attacker. The record does not identify a public exploit, campaign, victim, or specific exploitation activity; Checkmk says the issue was found during internal review.

• When a victim activates a javascript: value in a Setup session, arbitrary script can run with that session's privileges.
• The practical outcome depends on the victim's permissions and accessible data; possible consequences include reading or changing data, performing permitted administrative actions, or affecting Checkmk configuration.
• An absolute URL pointing to another origin creates an open redirect that could lead users to external content and support phishing.
• The vulnerability does not by itself establish that unauthorized access, configuration changes, or service disruption occurred; those outcomes depend on the victim's session and what the script does.

• Script execution in a Setup user's session could perform actions permitted to that session, potentially affecting accessible data or configuration.
• An open redirect can send users to an external origin, creating phishing or trust-abuse risk through links that appear to originate from Checkmk.
• Because exploitation requires Setup access, accounts with that access and instances using in-page search should receive priority during review.
• The 2.2.0 branch is end of life and remains affected, increasing operational risk where migration to a supported branch is not possible.

1. Update the 2.5.0 branch to the vendor-listed 2.5.0p15, the 2.4.0 branch to 2.4.0p38, or the 2.3.0 branch to 2.3.0p51.
2. For systems running 2.2.0, plan migration away from the end-of-life branch to a supported branch and apply its corresponding fix. No separate fix for 2.2.0 is identified in the available evidence.
3. If immediate updating is not possible, temporarily reduce the number of accounts with Setup access and treat that restriction only as defense in depth, not as a vendor-confirmed fix.
4. After updating, verify the deployed version and review access logs for suspicious reset_url values. The vendor describes the fix as restricting reset_url to same-origin relative URLs.

• Inventory all Checkmk instances and compare each instance with the affected branches and exact fixed releases.
• Identify pages that use the PageMenuSearch in-page search component and require Setup access.
• Inspect web server access logs for requests with suspicious reset_url values, especially a javascript: scheme or an external host. This is a vendor-described potential signal, not proof of successful exploitation.
• Review activity by Setup users associated with suspicious requests, especially after Reset actions or empty-search submissions.
• Verify the deployed version after updating on a per-branch basis. Do not treat the absence of suspicious log evidence as proof of safety.