CVE-2025-27809

What it actually does

TLS client implementations using affected Mbed TLS versions accept server certificates trusted for arbitrary hostnames when the application does not explicitly invoke mbedtls_ssl_set_hostname, bypassing hostname verification during the handshake.

Why it matters to the business

Organizations relying on affected libraries face elevated risk of man-in-the-middle interception or unauthorized server connections in client applications, potentially exposing sensitive data flows; the issue affects widely used cryptographic components with downstream dependents in multiple packages.

How an attack unfolds

An attacker positions a malicious server presenting a certificate issued by a trusted CA but bound to a different hostname; if the connecting client application omits the hostname-setting call, the library completes the TLS handshake without verifying the presented name against the intended destination, allowing the attacker to decrypt or modify traffic.

How to fix it

Upgrade Mbed TLS to 2.28.10 or 3.6.3 (commit 2fc8413bfcb51354c8e679141b17b3f1a5942561) and PaddlePaddle to 2.6.0; ensure all client code explicitly calls mbedtls_ssl_set_hostname with the expected server name before initiating connections; recompile and redeploy dependent applications after the library update.

How to confirm the fix worked

Confirm library versions match or exceed the fixed releases; review source for presence of mbedtls_ssl_set_hostname calls prior to TLS handshakes; perform test connections to a server presenting a mismatched but CA-trusted certificate and verify the connection is rejected.

Typical attack path

1. Identify client applications built against vulnerable Mbed TLS that do not call mbedtls_ssl_set_hostname before connecting.
2. Obtain or generate a certificate trusted by the client's root store but issued for a hostname other than the target.
3. Intercept or redirect the client's connection attempt to the attacker's server.
4. Complete the TLS handshake; the library accepts the certificate due to missing hostname enforcement.
5. Decrypt, inspect, or inject into the subsequent encrypted session.

How to detect it

Search application and TLS library logs for handshake events lacking hostname verification context; review process execution and network flows for unexpected certificate subjects during client connections; examine dependency manifests for pre-fix Mbed TLS or PaddlePaddle versions.

What your security team should do

• Prioritize upgrades for any products using armmbed/mbedtls or paddlepaddle packages to the stated fixed versions.
• Audit client-side TLS initialization code across the environment to enforce explicit hostname setting.
• Monitor EPSS and exploit maturity indicators for any upward trend given the 582-day publication window.
• Incorporate static analysis rules that flag missing hostname configuration in TLS client flows.