Live › vulnerability › CVE-2026-105031
When the OpenSSL TLS backend is used, the trusted CA APIs added certificates to the system trust anchors instead of replacing them. An attacker holding a certificate signed by any system-trusted authority may be accepted as a TLS peer.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-29 11:24 UTC. All times on this page are UTC.
Applications built on Apache Qpid Proton C with the OpenSSL TLS backend that rely on the custom trusted CA APIs to restrict which peer certificates are accepted. Windows builds using SChannel are not affected, per the sources. Teams that do not call the trusted CA setters or do not use OpenSSL TLS can skip it.
No product ranges from the sources yet.
0.40.0 and earlier.pn_ssl_domain_set_trusted_ca_db() or pn_tls_config_set_trusted_certs().0.41.1.SSL_CERT_FILE/dev/nullEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
When using the OpenSSL TLS implementation, both the pn_ssl_domain_set_trusted_ca_db() & pn_tls_config_set_trusted_certs() APIs added to rather than replaced the default system trust anchors. Leading to potentially trusting unexpected peer certificates.
This can be worked around by setting the SSL_CERT_FILE environment variable for the application to /dev/null.
This issue does not affect the Win32 SChannel TLS implementation.
This issue affects Apache Qpid Proton C: through 0.40.0.
Users are recommended to upgrade to version 0.41.1, which fixes the issue.
This page as .md · .json · in your agent: get_signal("CVE-2026-105031")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.