CVE-2023-5422

What it actually does

The POP3, IMAP, and SMTP email functions invoke OpenSSL for TLS but omit SSL_get_verify_result(), causing every certificate to be accepted regardless of validity, expiration, or hostname mismatch.

Why it matters to the business

Email content and credentials exchanged with mail servers can be read or altered by an attacker positioned on the network path, exposing customer and internal communications.

How an attack unfolds

An attacker places a rogue mail server presenting an invalid or self-signed certificate on the network; when OTRS initiates an unauthenticated TLS connection for sending or fetching mail the missing verification allows the handshake to succeed, enabling interception or injection of messages.

How to fix it

Upgrade OTRS to 7.0.47 or newer, 8.0.37 or newer; Community Edition users should migrate to a supported release that performs proper certificate validation.

How to confirm the fix worked

Confirm the installed version is at or above the fixed releases; test by configuring a mail server with an invalid certificate and verifying the connection is rejected.

Typical attack path

1. Deploy a MITM or rogue mail server reachable by the OTRS instance
2. Present an expired, self-signed, or name-mismatched TLS certificate
3. Trigger or wait for OTRS to perform POP3/IMAP/SMTP operations
4. Decrypt or modify email traffic in transit

How to detect it

Review application and mail logs for connections to unexpected mail servers or repeated TLS handshakes that would have been rejected under normal validation.

What your security team should do

• Apply the listed version upgrades within the next maintenance window
• Audit all mail server connection profiles for the use of TLS
• Enable certificate pinning or strict hostname verification where supported