CVE-2021-25299

What it actually does

CVE-2021-25299 is a reflected cross-site scripting vulnerability in Nagios XI 5.7.5 in /usr/local/nagiosxi/html/admin/sshterm.php. The vulnerable page does not properly sanitize user-controlled input before rendering it in an administrator-facing response. An unauthenticated attacker can craft a URL containing JavaScript that executes in the browser of a logged-in Nagios XI administrator who clicks the link. Successful execution can disclose session cookies or perform administrator actions in the user’s session context. The vendor description also notes it can be chained with other Nagios XI issues to achieve one-click remote command execution on the Nagios XI server.

Why it matters to the business

Nagios XI is commonly used to monitor critical infrastructure, applications, and network services, so compromise of an administrator session can give attackers visibility into sensitive operational data and a path to tamper with monitoring, suppress alerts, or pivot further into the environment. Although exploitation requires an administrator to click a malicious link, the vulnerability is network-reachable, low-complexity, and has a very high EPSS score with weaponized exploit maturity, making remediation important even though it is not currently listed in CISA KEV and is not known here as ransomware-used.

How an attack unfolds

An attacker identifies an exposed or reachable Nagios XI instance running the affected 5.7.5 code path and prepares a malicious URL targeting /usr/local/nagiosxi/html/admin/sshterm.php with script content embedded in a vulnerable parameter. The attacker then delivers the URL to a Nagios XI administrator through phishing, chat, ticket comments, documentation links, or another trusted communication channel. If the administrator is authenticated to Nagios XI and opens the link, the injected JavaScript executes in the administrator’s browser under the Nagios XI origin. The script may steal session cookies if accessible, harvest page content or CSRF tokens, or issue authenticated requests as the administrator. In more serious scenarios, the XSS is chained with other Nagios XI weaknesses or administrative functionality to execute commands on the Nagios XI server with minimal additional interaction.

How to fix it

Upgrade Nagios XI to a vendor-supported release that fixes the vulnerable sshterm.php XSS issue; because no exact fixed version was provided in the input, use the latest available Nagios XI release from Nagios and verify vendor release notes for the fix for CVE-2021-25299. If immediate upgrade is not possible, restrict access to Nagios XI administrative interfaces to trusted networks or VPNs, require MFA for administrators, limit who can access /admin/sshterm.php, and consider disabling or removing SSH terminal functionality if not required. Apply defense-in-depth controls such as HTTP-only and SameSite session cookies where supported, strong content security policy, administrative session timeout, and phishing-resistant access controls. Treat XSS mitigation as incomplete unless the affected application code is updated or patched.

How to confirm the fix worked

Confirm the installed Nagios XI version is not 5.7.5 or another vulnerable build by checking the Nagios XI web UI, package metadata, or installation files. Verify that /usr/local/nagiosxi/html/admin/sshterm.php has been updated according to vendor guidance. In a controlled test environment, attempt a benign reflected XSS proof-of-concept against the affected sshterm.php parameter and confirm that input is encoded or rejected rather than executed. Validate that administrative access is restricted to approved networks and that session cookies are protected with Secure, HttpOnly, and SameSite attributes where supported. Review vulnerability scanner results and web application tests to ensure the sshterm.php issue is no longer reported.

Typical attack path

1. Reconnaissance: identify Nagios XI deployments and determine whether the target appears to be running an affected version around 5.7.5.
2. Payload preparation: craft a URL to /usr/local/nagiosxi/html/admin/sshterm.php containing JavaScript in a vulnerable user-controlled parameter.
3. Delivery: send the malicious link to a Nagios XI administrator through phishing, messaging, ticketing systems, or another channel likely to be trusted.
4. User interaction: wait for the administrator to open the link while authenticated to Nagios XI.
5. Browser execution: run attacker-controlled JavaScript in the administrator’s Nagios XI session context.
6. Session or action abuse: steal session material where possible, collect tokens, or perform authenticated administrative actions through the victim’s browser.
7. Optional chaining: combine the XSS with other vulnerabilities or administrative capabilities to run commands on the Nagios XI server or gain deeper access.
8. Post-exploitation: maintain access, alter monitoring configuration, suppress alerts, exfiltrate operational data, or pivot to monitored systems.

How to detect it

To assess prior exploitation, review Nagios XI web server access logs, reverse proxy logs, WAF logs, EDR browser telemetry, and SIEM web events for requests to /admin/sshterm.php or /usr/local/nagiosxi/html/admin/sshterm.php containing encoded JavaScript, script tags, event-handler attributes, or suspicious external domains. Focus on requests followed by unusual administrator actions, new or modified users, changes to monitoring commands/checks, notification suppression, or unexpected SSH terminal activity. Look for evidence that an administrator clicked a crafted link from email, chat, ticketing, or documentation platforms. Correlate suspicious requests with outbound network connections from administrator workstations to attacker-controlled domains and with Nagios XI session activity from unusual IP addresses or user agents. If the XSS was chained to command execution, examine Nagios XI server process execution, shell history, cron entries, web-accessible files, modified plugins, and unexpected child processes spawned by the web server or Nagios XI components.

• /admin/sshterm.php
• /usr/local/nagiosxi/html/admin/sshterm.php
• sshterm.php?
• <script
• %3Cscript
• javascript:
• %6A%61%76%61%73%63%72%69%70%74%3A
• onerror=
• onload=
• onclick=
• %3Conerror
• %20onerror%3D
• document.cookie
• %64%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65
• fetch(
• XMLHttpRequest
• eval(
• atob(
• new Image(
• img src=x onerror=
• </script>
• %3C%2Fscript%3E

What your security team should do

• Prioritize upgrade or patching of Nagios XI instances because the vulnerability has weaponized exploit maturity and a very high EPSS score, despite not being listed in CISA KEV.
• Inventory all Nagios XI deployments, including internal-only monitoring servers, and identify any systems running version 5.7.5 or other unpatched releases from the same timeframe.
• Restrict Nagios XI administrative access to trusted networks, VPN, or zero-trust access controls; do not expose administrative interfaces directly to the internet.
• Require MFA for Nagios XI administrators and review administrator account permissions for least privilege.
• Search web, proxy, and Nagios XI access logs for suspicious requests to /admin/sshterm.php containing encoded script tags, JavaScript event handlers, or external callback URLs.
• Force logout or rotate sessions for Nagios XI administrators if exploitation is suspected, and reset credentials for accounts that may have been exposed.
• Review Nagios XI audit/configuration changes after suspicious activity, especially changes to commands, checks, notification settings, users, and SSH terminal usage.
• Add user-awareness messaging for administrators warning against opening unsolicited Nagios XI links, especially links involving /admin/sshterm.php.
• If compromise is suspected, preserve web logs, application logs, browser artifacts from affected admin workstations, and network telemetry before containment actions overwrite evidence.