---
id: "CVE-2026-94140"
kind: "vulnerability"
aliases: ["CVE-2026-94140"]
title: "Rex for Perl: rsync transfers accept unknown SSH host keys, enabling interception"
severity: "unknown"
cvss: null
epss: 0.00252
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["package", "perl", "rex", "self-hosted", "ssh"]
not_affected_if: ["key-auth-trusted-network", "no-remote-sync"]
published_at: "2026-10-21T22:16:50+00:00"
first_seen_at: "2026-10-23T21:57:29+00:00"
updated_at: "2026-10-25T05:02:01+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94140", "first_seen_at": "2026-10-23T21:57:29+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-94140", "first_seen_at": "2026-10-24T13:15:54+00:00"}]
---

# Rex for Perl: rsync transfers accept unknown SSH host keys, enabling interception

Rex through version 1.16.1 runs rsync over SSH with StrictHostKeyChecking=no hardcoded, so it accepts any host key for remote sync transfers. An attacker who can redirect the connection can capture the password sent under password authentication and read or write the transferred files.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the installed Rex version with `perl -MRex -e 'print $Rex::VERSION'` or `cpanm --info Rex`
- Search the project for `sync` calls to remote hosts and for `set_openssh_opt`, since the option does not reach the rsync transport

## Fix

- Move Rex to a version newer than `1.16.1` once a fixed release is published (unknown from the sources)
- Until then, avoid remote `sync` over untrusted networks and do not use password authentication for it

## Timeline

- 2026-10-23T21:57:29+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-94140
- 2026-10-24T13:15:54+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-94140

## From the sources

Rex versions through 1.16.1 for Perl accept an unknown SSH host key for remote rsync transfers because sync hardcodes StrictHostKeyChecking=no.

Every remote branch of sync builds its ssh command with that option, for password authentication, for private-key authentication and for the fallback. The ssh options a caller sets through set_openssh_opt reach the OpenSSH transport but not this command, so there is no configuration that restores host key checking for the transfer.

An attacker who can redirect the connection before the real host key is known presents their own and the transfer proceeds: under password authentication sync sends the connection password to that server, an upload writes the selected local files to it, and a download writes what it returns to the local destination.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_