usd-2020-0004 | Nagios NRPE v.3.2.1

Advisory ID: usd-2020-0004
Affected Product: Nagios NRPE
Affected Version: v.3.2.1
Vulnerability Type: Logic Error
Security Risk: None
Vendor URL:
Vendor Status: Fixed in v.4.0.0 (not verified)


If NRPE is compiled with command line parameter support and if the corresponding option is enabled inside of the NRPE configuration file,
NRPE are allowed to contain additional parameters that are passed as command line parameters to the configured monitoring scripts.

To check if a packet contains command line parameters, NRPE uses the validate_request function. This function contains the following code:

    if (packet_ver == NRPE_PACKET_VERSION_3) {
int32_t   l = ntohs(v3pkt->buffer_length);
v3pkt->buffer[l - 1] = '\x0';
buff = v3pkt->buffer;
} else {
v2pkt->buffer[MAX_PACKETBUFFER_LENGTH - 1] = '\x0';
buff = v2pkt->buffer;


/* make sure the request doesn't contain arguments */
if (strchr(v2pkt->buffer, '!')) {
if (allow_arguments == FALSE) {
logit(LOG_ERR, "Error: Request contained command arguments, but argument option is not enabled!");
return ERROR;

As on can see, this code should block requests if the ENABLE_COMMAND_ARGUMENTS flag was set during compilation, but the allow_arguments
option (dont_blame_nrpe) is not enabled in the configuration file. NRPE packets that contain command line arguments have to contain a !
sign in their buffer and therefore the above mentioned code should trigger and block the request.

However, as one can see, the code uses the v2pkt->buffer instead of the previously declared generic buff variable. Incoming v3 packets
will never trigger the condition strchr(v2pkt->buffer, ‚!‘), and will pass this check even if they contain command line arguments.

While this sounds like a serious security issue, it has only minimal impact, since the NRPE source code does only parse command line arguments
if the allow_arguments (dont_blame_nrpe) option was set:

/* get command arguments */
if (allow_arguments == TRUE) {
// Process Command Line Args

Therefore, even if a v3 packet passes the first check, its arguments will just be ignored in the proceeding code.
Nonetheless, this is obviously a logical flaw inside the NRPE source code and should be fixed.

Proof of Concept (PoC) / Steps to Reproduce

0. NRPE has to be compiled with command line parameter support. Additionally, dont_blame_nrpe option inside the NRPE configuration file has to be enabled.

1. Send a v2 packet that contains command line arguments (Packet is rejected).

2. Send a v3 packet that contains command line arguments. (Packet is processed, like a packet without any arguments)


Checking for ! signs should be done on the generic buffer buff, which applies for v2 and v3 packets.



This security vulnerability was discovered by Tobias Neitzel of usd AG.


In order to protect businesses against hackers and criminals, we always have to keep our skills and knowledge up to date. Thus, security research is just as important for our work as is building up a security community to promote the exchange of knowledge. After all, more security can only be achieved if many individuals take on the task.

Our CST Academy and our usd HeroLab are essential parts of our security mission. We share the knowledge we gain in our practical work and our research through training courses and publications. In this context, the usd HeroLab publishes a series of papers on new vulnerabilities and current security issues.

Always for the sake of our mission: „more security.“

to usd AG

In accordance with usd AG’s Responsible Disclosure Policy, all vendors have been notified of the existence of these vulnerabilities.


The information provided in this security advisory is provided „as is“ and without warranty of any kind. Details of this security advisory may be updated in order to provide as accurate information as possible.