CVE-2021-35478

What it actually does

Nagios Log Server versions before 2.1.9 are vulnerable to reflected cross-site scripting in the alert history and audit log filtering dropdown functionality. Filter parameters are not safely encoded before being reflected into the HTML response, allowing an attacker to inject JavaScript into a crafted URL or third-party page. Exploitation requires a logged-in user to open the malicious link or page, after which the injected script executes in that user’s browser under the Nagios Log Server origin. Because the script runs in an authenticated user context, it may read page content, capture anti-CSRF tokens where accessible, perform actions available to the victim, modify viewed settings, or exfiltrate session-related data depending on browser and cookie protections.

Why it matters to the business

Successful exploitation can let an attacker abuse the trust of a Nagios Log Server user session to access or manipulate monitoring and logging workflows. This can undermine visibility into operational events, audit activity, and alert history, potentially delaying incident response or enabling misleading changes through a victim’s browser. The CVSS score is moderate, but the EPSS score is high and public exploit availability is reported, so internet-accessible or broadly used administrative interfaces should be treated as a priority even though this is not currently listed in CISA KEV and is not known to be associated with ransomware campaigns.

How an attack unfolds

An attacker first identifies a Nagios Log Server instance running a version earlier than 2.1.9. The attacker then crafts a URL to the alert history or audit log filter interface with JavaScript embedded in one or more filtering parameters, commonly using encoded script tags, event handlers, or JavaScript URI payloads. The attacker delivers the link through phishing, chat, ticket comments, documentation, or a web page that causes the victim’s browser to request the crafted URL. When an authenticated Nagios Log Server user opens it, the server reflects the malicious parameter into the response without proper output encoding. The browser executes the injected script in the Nagios Log Server security context, allowing the attacker to perform actions as the user or collect information visible to that user. Because the payload is reflected rather than stored, the most durable evidence is usually in HTTP access logs, reverse proxy logs, browser history, endpoint telemetry, and any resulting suspicious application actions shortly after the malicious request.

How to fix it

Upgrade Nagios Log Server to version 2.1.9 or later. If a direct upgrade is not immediately possible, reduce exposure by restricting access to the Nagios Log Server web interface to trusted networks or VPNs, requiring strong authentication, and limiting administrative access to users who need it. Add or tune web application firewall rules to block common XSS payloads in query parameters on alert history and audit log pages, including script tags, JavaScript URIs, and HTML event-handler attributes. Ensure session cookies are configured with HttpOnly, Secure, and SameSite attributes where supported to reduce token theft risk. Educate administrators not to open unsolicited Nagios Log Server links and avoid embedding untrusted links in operational workflows until patched.

How to confirm the fix worked

Confirm the installed Nagios Log Server version is 2.1.9 or later through the product UI, package manager, or appliance/version metadata. Review release notes or package inventory to ensure all active Nagios Log Server nodes have been upgraded, including standby, test, and disaster recovery systems. Attempt a safe validation using a benign reflected payload such as an encoded string in alert history and audit log filter parameters and verify it is rendered as text or safely encoded rather than interpreted as HTML or JavaScript. Validate that unauthenticated internet access to the web interface is not possible and that administrative access is restricted. Check reverse proxy or WAF logs to ensure rules do not break legitimate filtering but do block obvious XSS payloads.

Typical attack path

1. Identify or assume a target organization uses Nagios Log Server before version 2.1.9.
2. Create a malicious link to the alert history or audit log filtering page with JavaScript embedded in filter parameters.
3. Encode or obfuscate the payload to bypass simple filters and make the URL less obvious.
4. Deliver the link to a logged-in Nagios Log Server user through phishing, messaging, a ticketing system, or a third-party web page.
5. Victim opens the crafted URL while authenticated to Nagios Log Server.
6. Nagios Log Server reflects the unsanitized filter value into the page response.
7. The victim’s browser executes attacker-controlled JavaScript in the Nagios Log Server origin.
8. The script reads accessible page data, captures tokens where possible, issues same-origin requests, or performs actions permitted to the victim account.
9. Attacker uses the captured data or induced actions to support follow-on access, monitoring disruption, or reconnaissance.

How to detect it

Look for evidence in HTTP access logs from Nagios Log Server, reverse proxies, load balancers, WAFs, secure web gateways, browser history, and endpoint telemetry from administrator workstations. Focus on requests to alert history and audit log pages with unusual filter parameters containing HTML tags, URL-encoded angle brackets, JavaScript schemes, event-handler attributes, or DOM-manipulation functions. Because this is reflected XSS, a successful payload may not create persistent server-side artifacts; correlate suspicious requests with the victim user’s session, source IP, user-agent, referrer, and subsequent Nagios Log Server actions. Review application audit records for unexpected configuration changes, alert changes, account changes, API usage, or administrative operations shortly after suspicious GET requests. Inspect WAF blocks and allows for encoded payloads that may have bypassed controls. On endpoints, review browser history and cached URLs for crafted Nagios Log Server links, and investigate any outbound connections immediately after the page load to unfamiliar domains that could indicate data exfiltration from injected JavaScript.

• <script
• %3Cscript
• %253Cscript
• </script>
• %3C%2Fscript%3E
• javascript:
• javascript%3A
• onerror=
• onload=
• onclick=
• onmouseover=
• alert(
• document.cookie
• document.domain
• localStorage
• sessionStorage
• eval(
• String.fromCharCode
• fetch(
• XMLHttpRequest
• new Image(
• img src=x onerror
• svg/onload
• %3Csvg%2Fonload
• %3Cimg%20src%3Dx%20onerror
• /nagioslogserver/index.php/alerts
• /nagioslogserver/index.php/alert
• /nagioslogserver/index.php/audit
• /nagioslogserver/index.php/admin/audit

What your security team should do

• Patch all Nagios Log Server deployments to version 2.1.9 or later as a priority because public exploitation is available and EPSS indicates elevated likelihood of exploitation.
• Restrict access to the Nagios Log Server web interface to trusted administrative networks, VPNs, or zero-trust access controls.
• Search historical web, proxy, and application logs for suspicious requests to alert history and audit log filtering endpoints containing encoded HTML, script tags, event handlers, or JavaScript URIs.
• Review Nagios Log Server user activity following suspicious requests, focusing on configuration changes, alert modifications, audit log access, new users, changed credentials, and unexpected administrative actions.
• Force reauthentication or rotate sessions for users who clicked suspicious links or whose browsers requested suspicious Nagios Log Server URLs.
• Deploy or tune WAF/SIEM detections for reflected XSS patterns in query parameters targeting Nagios Log Server paths.
• Verify browser and cookie hardening controls such as HttpOnly, Secure, and SameSite are enabled where supported.
• Provide targeted awareness to administrators and monitoring staff about malicious links to internal monitoring tools.