Bug 2537761 (CVE-2026-93402) - CVE-2026-93402 rsyslog: rsyslog: imdtls permitted-peer authorization bypass
Summary: CVE-2026-93402 rsyslog: rsyslog: imdtls permitted-peer authorization bypass
Keywords:
Status: NEW
Alias: CVE-2026-93402
Deadline: 2026-09-22
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-09-22 08:31 UTC by OSIDB Bzimport
Modified: 2026-09-28 13:58 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-09-22 08:31:25 UTC
The optional rsyslog imdtls input module does not enforce
tls.permittedpeer after a successful CA-authenticated DTLS handshake
when configured with tls.authmode="name" or
tls.authmode="fingerprint".

After SSL_accept() succeeds, imdtls performs the permitted-peer
identity check. When that check fails, the module logs a warning but
leaves the DTLS session active. The session is subsequently read and
received records are passed to the configured ruleset.

Impact
======

A remote peer whose certificate is accepted by the listener's
configured CA, but whose name or fingerprint is not listed in
tls.permittedpeer, can inject chosen syslog records into the
configured input stream.

This is an integrity issue for that input stream. It does not provide
access to stored logs, modification or deletion of existing records,
confidentiality loss, memory corruption, or code execution.

Affected configurations and prerequisites
=========================================

The issue affects only deployments where all of the following apply:

- rsyslog was built with the optional imdtls module and the module is
explicitly loaded;
- a reachable imdtls listener is configured with tls.authmode="name"
or tls.authmode="fingerprint" together with tls.permittedpeer; and
- the attacker possesses the private key for a client certificate
accepted by the listener's configured CA.

Normal DTLS certificate-chain verification remains effective.
Arbitrary remote clients, including clients using self-signed or
otherwise untrusted certificates, cannot exploit this issue.
tls.authmode="certvalid" is not affected.

Affected upstream versions
==========================

v8.2402.0 and later.

Fix
===

Apply the following change to plugins/imdtls/imdtls.c in
DTLSAcceptSession(), after imdtls_verify_callback() returns failure:

    if (status == 0) {
        LogMsg(0, RS_RET_NO_ERRCODE, LOG_WARNING,
               "imdtls: Cert Verify FAILED for DTLS client idx (%d)", idx);
        DTLScleanupSession(inst, idx);
    }

This immediately removes a session that failed post-handshake
permitted-peer verification, preventing it from reaching message
processing.

The fix has been rebased on current upstream main and tested with
OpenSSL-enabled imdtls/omdtls. Regression coverage verifies rejection
of CA-signed but non-permitted clients for both name- and
fingerprint-based permitted-peer authorization, while retaining the
permitted-peer positive control.


Note You need to log in before you can comment on or make changes to this bug.