Bug 2537761 (CVE-2026-93402)
| Summary: | CVE-2026-93402 rsyslog: rsyslog: imdtls permitted-peer authorization bypass | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | OSIDB Bzimport <bzimport> |
| Component: | vulnerability | Assignee: | Product Security <prodsec-ir-bot> |
| Status: | NEW --- | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | rhel-process-autobot, security-response-team, watson-tool-maintainers |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: |
A flaw was found in rsyslog. When using the imdtls input module configured for name or fingerprint authentication, permitted-peer identity checks are not enforced after a successful DTLS handshake. A remote attacker possessing a valid certificate signed by the listener's trusted Certificate Authority could bypass peer restrictions and inject unauthorized syslog records into the input stream.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Deadline: | 2026-09-22 | ||
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.