Apache Qpid Proton C CVE-2026-105031

Applies only to applications using the OpenSSL TLS backend of Qpid Proton C through 0.40.0 that call pn_ssl_domain_set_trusted_ca_db() or pn_tls_config_set_trusted_certs() expecting those calls to replace, not augment, the default trust anchors; applications not restricting trust gain no new exposure. To abuse the residual system trust, an attacker needs a man-in-the-middle/network interception position against the TLS connection and a certificate that validly chains to a CA already in the host's system trust store for the targeted peer identity. Limiting factors: the Win32 SChannel implementation is not affected; the issue is neutralized by setting SSL_CERT_FILE to /dev/null or by upgrading to 0.41.1; and exploitation yields trust-scope bypass only, not code execution.

No CVSS vector, EPSS score, or KEV entry is provided, and the vuln.today Decision label is 'awaiting_data', so quantitative exploitation signals are absent rather than low - priority cannot be derived from a score and must rest on the mechanism. The flaw is a certificate-trust-scoping weakness: on the OpenSSL backend, pn_ssl_domain_set_trusted_ca_db() and pn_tls_config_set_trusted_certs() add the supplied CA(s) to the system default trust anchors instead of replacing them, so an application that deliberately pinned a restricted/private CA still silently trusts every CA in the system store. Real-world risk is conditional, not universal: it only bites applications that call these APIs intending to narrow trust, and exploitation further requires a man-in-the-middle position plus a certificate that chains to some system-trusted CA for the target identity. This is therefore a meaningful MITM-enabling defect for security-sensitive AMQP deployments that rely on CA pinning, but it is not a remote code execution or default-configuration break, and the absence of any PoC or active-exploitation signal (no public exploit identified at time of analysis) argues against treating it as an emergency. The vendor rates it 'important'; with no CVSS supplied, that severity and the clear fix path (0.41.1) are the strongest available signals.

An AMQP application built on Qpid Proton C with the OpenSSL backend calls pn_ssl_domain_set_trusted_ca_db() to pin a single private CA for its broker, expecting all other issuers to be rejected. Because the system trust store is still honored, an attacker in a man-in-the-middle position who presents a server certificate issued by any publicly/system-trusted CA for the broker's name is accepted, allowing interception or modification of the messaging traffic. No public exploit identified at time of analysis.