Rex 1.16.1 Hardcodes SSH to Disable Host Key Checks, Risking Man-in-the-Middle Attacks

Rex, a popular Perl-based automation framework, contains a configuration flaw that weakens SSH security during remote file transfers. The issue affects all versions through 1.16.1 and stems from hardcoded settings that bypass standard host key verification.

What happened

The CPAN Security Group posted an advisory on October 21 detailing CVE-2026-94140 in the Rex framework. According to the oss-security mailing list, the vulnerability exists because the sync module hardcodes the SSH option StrictHostKeyChecking to no. This configuration forces the SSH client to accept any host key presented by the remote server, regardless of whether it is known or trusted.

Robert Rothenberg authored the advisory distributed via the oss-security list. The report identifies that this behavior is inherent in the code for Rex versions up to and including 1.16.1. Users of these versions who perform remote rsync transfers via Rex are exposed to this insecure default setting. The framework accepts unknown SSH host keys for remote rsync transfers because of this hardcoded value.

Why it matters

Disabling strict host key checking removes a primary defense against man-in-the-middle attacks on SSH connections. Without this verification, an attacker positioned on the network path can intercept the rsync session by presenting a fraudulent host key. The Rex framework will accept this key automatically because the underlying SSH command is forced to ignore unknown keys.

Environments using Rex for automated deployments or configuration management are particularly exposed. These systems often run unattended transfers between servers, making manual verification of host keys impractical. The hardcoded nature of the flaw means that even security-conscious administrators who rely on Rex defaults may be unknowingly transmitting data over unverified channels. The source material states that the flaw allows the acceptance of unknown host keys.

Our take on the response

• Monitor network traffic for unexpected SSH connections to unauthorized IP addresses.
• Review Rex configuration files for any workarounds or custom scripts that might mask the flaw.
• Isolate systems running affected Rex versions from untrusted networks until a fix is available.
• Audit recent rsync logs for anomalies in host key acceptance or transfer failures.

What defenders should look for

Teams usually detect this type of activity by reviewing SSH server logs for connections that bypass standard host key verification. Defenders should check whether any rsync sessions originated from systems running known vulnerable automation frameworks. Look for unusual patterns in file transfers, such as connections from unexpected source IPs or transfers occurring outside normal maintenance windows. Containment moves often involve isolating the affected automation controller and verifying the integrity of transferred files.

What to do and how to stay safe: Rex

• Identify all servers and workstations running Rex versions through 1.16.1 in your environment.
• Inspect SSH server logs for connections that accepted host keys without prior verification.
• Monitor network traffic for rsync sessions that deviate from established baselines or trusted sources.
• Plan to upgrade to a patched version once the vendor confirms a fix is available.

Step-by-step guide: Vulnerability Management Myths That Waste Your Time and Budget

General security guidance from the NetSec Tribune newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which versions of Rex are affected by CVE-2026-94140?

All versions of Rex through 1.16.1 are affected by this vulnerability.

What is the specific technical cause of this flaw?

The sync module in Rex hardcodes the SSH option StrictHostKeyChecking to no.

Has a patch been released for this issue?

No patch or updated version has been confirmed by the vendor yet.