Port 5666 – Nagios NRPE (Nagios Remote Plugin Executor)

Port 5666 is the default port for NRPE (Nagios Remote Plugin Executor), the agent that runs monitoring checks on remote hosts so a central Nagios or Icinga server can read their CPU, memory, disk, and service health. The nrpe daemon listens on 5666/TCP, waits for a query, runs one of a fixed set of local check plugins named in nrpe.cfg, and returns the status and performance data. It’s one of the most common ways Linux fleets are monitored — and because it exists specifically to run commands on the host, an exposed port 5666 is worth a very close look.

Why It’s Open

Wherever there’s a Nagios, Icinga, or Naemon monitoring server, there are usually dozens or hundreds of hosts running the NRPE agent so that server can poll them. NRPE ships with the standard Nagios plugins (check_load, check_disk, check_users, check_procs, and friends) and is the default answer for “how do I monitor a remote Linux box without giving the monitoring server SSH access to it.” You’ll find it on application servers, database hosts, hypervisors, appliances, and anything else that got wired into a monitoring stack. The daemon is normally launched by xinetd/systemd or run standalone, and it’s supposed to be reachable only from the monitoring server — but on flat networks, in cloud security groups left too wide, or on internet-facing boxes, 5666 frequently ends up exposed far beyond that. Where NRPE is monitoring a database or app tier, its neighbors on the same host are often worth checking too — PostgreSQL on 5432, MySQL on 3306, and SNMP on 161 all commonly sit behind the same monitoring agent.

Common Risks

• Command / argument injection → remote code execution. This is NRPE’s signature risk. If the daemon is built and configured with dont_blame_nrpe=1 (command argument processing enabled), a client can smuggle shell metacharacters into a check’s arguments and have them executed by the shell. Historically, NRPE tried to blacklist characters like ` and $(), but a raw newline (0x0A) slipped straight through — appending a second command that bash ran as the NRPE user.
• Runs as a real OS account. Injected commands execute as whatever user the daemon runs as — usually nagios, but sometimes root on lazily configured hosts. That turns a monitoring agent into a foothold or a straight privilege escalation.
• Unauthenticated by design. NRPE has no user login. The only access control is allowed_hosts, an IP-based list that is trivially spoofable on the local segment and useless once the port is internet-reachable. Anyone who can reach 5666 from an accepted address can query it.
• Weak or optional “encryption.” Older NRPE only offered an anonymous Diffie-Hellman handshake with a fixed 512-bit key and no certificate — that’s obfuscation, not authentication, and it’s vulnerable to a straightforward man-in-the-middle. If TLS with real certificates isn’t enforced, monitoring data (and injected commands) can be read or altered on the wire.
• Information disclosure. Querying the daemon reveals the NRPE version and the list of configured checks, which leaks the host’s role, installed software, load, process counts, and logged-in users — useful reconnaissance before an attack.
• Abusable custom checks. Even with argument processing off, an admin-written command[...] in nrpe.cfg that wraps a shell script or passes input to sh -c can hand an attacker command execution through the “safe” path.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and grab the version

nmap -sV -p 5666 <target>

Enumerate the configured checks with the NSE script

nmap -p 5666 --script nrpe-enum <target>

The nrpe-enum script runs the daemon’s stock commands and returns load averages, process and user counts, and other host detail — a quick read of what the monitoring agent exposes.

Connect with the native client

check_nrpe -H <target>

Run a specific configured check

check_nrpe -H <target> -c check_load

Test whether command argument processing is enabled

check_nrpe -H <target> -c check_users -a "arg"

If the daemon accepts and acts on the argument, dont_blame_nrpe is on and the host is a candidate for argument injection.

Argument-injection proof of concept (CVE-2014-2913)

check_nrpe -H <target> -c check_users \
  -a "$(echo -e '\x0a touch /tmp/nrpe_poc')" ""

Metasploit — arbitrary command execution

msfconsole -q
use exploit/linux/misc/nagios_nrpe_arguments
set RHOSTS <target>
set RPORT 5666
run

Log every exposed NRPE instance, the configured checks it leaks, and any successful command execution so it lands in the final pentest report instead of a scratch file.

What to Look For

Known CVEs and Exploits

• CVE-2013-1362 — Incomplete blacklist in nrpe.c in NRPE before 2.14. $() shell metacharacters in a check argument are processed by bash, letting a remote attacker run arbitrary shell commands as the NRPE user. CVSS v2 7.5. This is the flaw Metasploit’s exploit/linux/misc/nagios_nrpe_arguments targets; it requires command argument processing to be enabled.
• CVE-2014-2913 — Incomplete blacklist in NRPE 2.15 and earlier. A newline character (0x0A) in the -a argument to check_nrpe slips past the metacharacter filter and appends a second command → arbitrary command execution. CVSS v2 7.5, and available as Exploit-DB 32925. NVD flags this as DISPUTED: the vendor treats it as expected behavior when the operator explicitly enables dont_blame_nrpe against the config file’s own warning — so it’s real but strictly config-dependent.
• CVE-2020-6581 — Insufficient filtering in NRPE 3.2.1: the nasty_metachars routine mishandles \n, treating it as the characters \ and n rather than a newline, which can lead to command injection. Scored CVSS v3.1 7.3 but with a local vector (AV:L/PR:L/UI:R), so the practical bar is higher than the older remote bugs.
• CVE-2020-6582 — Heap-based buffer overflow in NRPE 3.2.1, where a small negative length is interpreted as a large positive value during a bzero call. CVSS v3.1 7.5 (AV:N, availability impact) — a network-reachable denial-of-service against the daemon.

Mitigation

• Don’t expose 5666 to the internet or untrusted networks. Firewall it so only the Nagios/Icinga monitoring server can reach the daemon. This single control neutralizes almost every risk on this page.
• Keep dont_blame_nrpe=0. Leave command argument processing disabled unless you have a hard requirement for it; with it off, the argument-injection class largely goes away. If you must parameterize checks, do it with fixed, server-side command definitions instead.
• Run NRPE as a least-privilege account. Use the dedicated nagios/nrpe user, never root, so a worst-case injection is contained to a low-privilege context.
• Use modern, authenticated transport. Run a current NRPE (3.x/4.x) with real TLS certificates rather than the legacy anonymous-DH/512-bit default, or move to a push-based / authenticated model (NSCA, NRDP) or an agent behind proper authentication.
• Patch NRPE. Anything ≤ 2.15 carries the metacharacter/newline injection bugs; keep the daemon and its plugins current.
• Restrict allowed_hosts, but don’t rely on it alone. It’s an IP-based, spoofable check — pair it with network ACLs and host firewalls.
• Audit custom checks. Review every command[...] in nrpe.cfg for anything that passes input to a shell, wraps a shell script, or calls sh -c.

Real-World Example

In April 2014, researcher Jan Kadlec published a remote command injection in NRPE 2.15 and earlier (CVE-2014-2913). NRPE already tried to block command substitution like `id` and $(id), but nobody had filtered the raw newline character. By encoding a 0x0A into a check argument, an attacker on an allowed host could append a second shell command that bash happily executed as the nagios user — a single check_nrpe call turning a read-only monitoring probe into code execution. A Metasploit module (nagios_nrpe_arguments) and an Exploit-DB entry followed within days, and exposed monitoring hosts running with dont_blame_nrpe=1 were compromisable outright. The honest caveat is that it only bites when argument processing is enabled — but that option is routinely switched on so generic checks like check_disk and check_load can be parameterized, which is exactly why the bug mattered in practice and why an old, argument-enabled NRPE is still a finding worth chasing.

FAQ

What is port 5666 used for?

Port 5666/TCP is the default port for NRPE, the Nagios Remote Plugin Executor. A Nagios or Icinga monitoring server connects to the NRPE agent on a remote host to run local check plugins — CPU, memory, disk, services — and read back their status. It exists so the central server can monitor a host without needing SSH or a login on it.

Can NRPE on port 5666 be exploited?

Yes, most notably through command/argument injection. If NRPE is built and configured with dont_blame_nrpe=1, an attacker who can reach the port from an accepted source can inject shell metacharacters into check arguments and execute commands as the NRPE user (CVE-2013-1362, CVE-2014-2913). Older versions and misconfigured custom checks widen the surface further.

What is dont_blame_nrpe and why does it matter?

dont_blame_nrpe is an NRPE configuration flag. Set to 0 (the default), the daemon ignores client-supplied arguments; set to 1, it passes them into check commands — which is what makes argument injection possible. The name is the developers’ own warning: enabling it puts the security burden on you. Keep it at 0 unless you genuinely need parameterized checks.

Is NRPE traffic encrypted and authenticated?

Not reliably. NRPE has no user authentication — access is gated only by the IP-based allowed_hosts list, which is spoofable. Older builds encrypt with an anonymous Diffie-Hellman handshake and a fixed 512-bit key and no certificate, which provides confidentiality against a passive sniffer but no authentication and no protection against an active man-in-the-middle. Modern NRPE supports proper TLS with certificates; use it, or a push-based transport.

How do I secure or close port 5666?

Firewall 5666 so only the monitoring server can reach it, keep dont_blame_nrpe=0, run the daemon as a non-root user, patch to a current release, and enforce TLS with real certificates. If a host doesn’t need NRPE, stop the daemon and confirm the port is closed with a rescan.

TL;DR

• Service: NRPE (Nagios Remote Plugin Executor) for remote monitoring checks
• Default port: 5666/TCP
• Biggest risk: command/argument injection → RCE as the NRPE user when dont_blame_nrpe=1; unauthenticated, weakly-encrypted, IP-ACL-only exposure
• Mitigation: firewall to the monitoring server, keep dont_blame_nrpe=0, run non-root, patch NRPE, and enforce real TLS