https://seclists.org/oss-sec/2026/q3/874: rsyslog imdtls permitted-peer authorization bypass
Affected Software
Frequently Asked Questions
Which deployments are exposed?
Exposure requires an rsyslog build containing the optional imdtls module, with that module explicitly loaded, and a reachable imdtls listener configured with tls.authmode="name" or tls.authmode="fingerprint". The listener must also use tls.permittedpeer.
What must an attacker have to send unauthorized records?
The attacker needs a certificate accepted by the listener's configured CA. Their certificate name or fingerprint does not need to be listed in tls.permittedpeer because a failed permitted-peer check leaves the DTLS session active.
How can administrators identify attempted or successful bypasses?
imdtls logs a warning when the permitted-peer identity check fails. Such warnings are significant because the module continues reading the DTLS session and passes received records to the configured ruleset.
What is the security impact of a successful attack?
An unauthorized CA-authenticated remote peer can inject chosen syslog records into the configured input stream. The issue does not provide access to stored logs, alteration or deletion of existing records, confidentiality loss, memory corruption, or code execution.