Database/Control plane, storage & DevOps

Apache Qpid Proton C: setting trusted CAs adds to rather than replaces the system trust anchors

CVSS 9.1CVE-2026-105031Control plane, storage & DevOpscurated

Impact

Both APIs that an application uses to pin its own trust anchors instead appended them to the default system trust store when built against OpenSSL. An application that believed it only trusted a private CA will in fact accept any certificate signed by any public CA in the host trust store, so an attacker able to obtain or mis-issue such a certificate and intercept the connection can impersonate the AMQP peer and read or alter messages. Qpid Proton C is the AMQP client library under messaging-driven control-plane and job-dispatch paths, so the exposed traffic can be scheduling, telemetry or orchestration messages between datacenter components rather than end-user data. The flaw is in trust configuration, not in the handshake, so nothing in normal operation signals it. The Win32 SChannel backend is unaffected.

Who can reach it

A network attacker in position to intercept an AMQP/TLS connection who holds a certificate for the target name from any CA in the host system trust store. No authentication to the application is required.

What to do

Upgrade Apache Qpid Proton C to 0.41.1 and restart the applications linked against it - a daemon restart per affected service, no node maintenance. Where an upgrade is not yet possible, the advisory's workaround is to set SSL_CERT_FILE=/dev/null for the application so the system trust store is empty, leaving only the explicitly configured CAs.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-105031 https://lists.apache.org/thread.html/lc10nrjt2dwcjjhrsgoyy5tqkntsnor4 http://www.openwall.com/lists/oss-security/2026/10/28/22

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.