Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessControl or MITM the TLS peer a client connects to
-
ExploitPresent a non-RFC9525-compliant wildcard certificate
-
ExecutionTrigger stack buffer over-read in hostname verification
-
ImpactCrash or destabilize the Qpid Proton C client
Vulnerability Assessment
| Exploitation Conditions | Exploitation requires a Qpid Proton C client at or below version 0.40.0 to perform TLS peer hostname verification against a certificate whose wildcard entry does not conform to RFC9525; the attacker must control the TLS peer (a malicious server, or a MITM position injecting the crafted certificate) that the victim establishes a connection to. Limiting factors: only non-compliant wildcard certificates trigger the over-read (certificates that comply with RFC9525 are unaffected, and the fix simply rejects non-compliant ones); the victim client must initiate or accept the TLS connection to the attacker-controlled endpoint with hostname verification active; and only versions through 0.40.0 are vulnerable, so any deployment on 0.41.1 or later is not exploitable. |
| Impact | This is a genuinely low-priority issue, and the available signals are consistent on that point rather than conflicting. No source supplies a CVSS score or vector (NVD, Apache, and oss-security all show N/A), so attack vector, complexity, and privilege requirements are not vendor-confirmed and must be inferred from the description. There is no EPSS score, no CISA KEV listing, and no PoC or exploit reference in any of the provided links - the references are purely informational advisories (oss-security post, Apache JIRA PROTON-2974, project homepage). The vuln.today decision label is 'awaiting_data', reinforcing that no urgency signal (KEV/EPSS/SSVC) is present. Apache itself rated this 'low'. The flaw is a stack buffer over-read triggered only when a Qpid Proton C client verifies a peer TLS certificate bearing a wildcard entry that does not comply with RFC9525, which means the attacker must control or impersonate the TLS peer the victim connects to, and the realistic worst case is a client-side crash (denial of service) rather than code execution or data theft. Because no CVSS vector is provided, authentication requirements are not confirmed from available data; this is best described as exploitable by remote attackers who control a malicious or misconfigured TLS endpoint. Bottom line: a real but low-impact, condition-dependent bug - patch during normal maintenance, not an emergency. |
| Exploit ScenarioDerived | An attacker who operates (or man-in-the-middles into) an AMQP/TLS server endpoint presents a certificate containing a wildcard SAN or CN that violates RFC9525. When a Qpid Proton C client at or below version 0.40.0 performs its home-grown peer hostname verification, the verification routine reads past the bounds of a stack buffer, most plausibly crashing the client process. No public exploit code is identified at time of analysis; the only references are vendor and oss-security advisories. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 28, 2026
Apache Qpid Proton C through 0.40.0 performs TLS peer hostname verification with its own hand-rolled logic, and a certificate carrying a wildcard entry that does not conform to RFC9525 causes a stack buffer over-read during that check. A malicious TLS peer - or an attacker in a man-in-the-middle position injecting a crafted certificate - can therefore disrupt the connecting client; the assessed impact is availability-only (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L), with the user-interaction requirement reflecting that the victim client must actually connect to the attacker-controlled endpoint with verification enabled. Certificates that comply with RFC9525 never trigger the flaw, and the issue is fixed in 0.41.1; no public exploit code was identified at time of analysis and the issue is not in CISA KEV, which is consistent with the low-priority, awaiting-data decision signal.
RemediationAI
Vendor-released patch: upgrade Apache Qpid Proton C to 0.41.1, the fix version recorded in PROTON-2974, which resolves the issue by rejecting certificates whose wildcard names do not conform to RFC9525 and by delegating verification to OpenSSL (with a corresponding minimum OpenSSL base version) and simplified SChannel checks. Note the side effect of that fix: peers presenting non-compliant or misconfigured wildcard certificates will now fail hostname verification where they previously - unsafely - succeeded, so certificates in test or internal deployments that use non-RFC9525 wildcards should be corrected before or alongside the upgrade. Deployments on 0.41.1 or later are not exposed. The only affected builds are those through 0.40.0, and the vendor's stated guidance is simply to upgrade; no separate configuration workaround is documented in the available sources, and disabling peer hostname verification would remove the very check involved and is not recommended. Advisory and tracker links: https://seclists.org/oss-sec/2026/q4/432 and https://issues.apache.org/jira/browse/PROTON-2974.
Affected ProductsAI
Apache Qpid Proton C (the proton-c component) through version 0.40.0 is affected; the reporter's tracker entry lists no specific affected-version field, but the advisory and PROTON-2974 both place the fix in proton-c-0.41.1, and the upstream description states the issue affects Proton C through 0.40.0 and that 0.41.1 fixes it. No CPE identifiers were provided in the available data, so matching must be done on the Proton C library version rather than on a CPE string. Any application, client library binding, or container that embeds a vulnerable proton-c (for example AMQP clients and Qpid components linking the C toolkit) inherits the behaviour. Vendor and tracker references: https://seclists.org/oss-sec/2026/q4/432, https://issues.apache.org/jira/browse/PROTON-2974, and the project site https://qpid.apache.org/.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Proton C's TLS peer hostname verification was home-grown rather than delegated to the TLS library, and upstream issue PROTON-2974 states plainly that this implementation was not in accordance with modern standards, which are in fact stricter and simpler than what was written. The fix replaces that logic with OpenSSL's built-in hostname verification (raising the minimum required OpenSSL base version) and with simplified custom checks in the SChannel Win32 code path, so the component affected is proton-c and the corrected behaviour is to accept only certificates whose wildcard names comply with RFC9525. The flaw surfaces when a certificate presents a misconfigured wildcard entry - the vulnerable code parses it in a way that reads past a stack buffer; the exact parsing path, the specific malformed wildcard forms accepted, and whether the over-read is bounded are not described in the available sources. No CWE was supplied. Because the trigger is certificate validation rather than message processing, exposure depends on the client connecting to a hostile or impersonated AMQP peer while hostname verification is active; only builds through 0.40.0 contain the defective verifier, and 0.41.1 removes it entirely rather than patching around it.
Know when OpenSSL gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N and PR:N because the attacker needs no local access or credentials, only a malicious TLS peer; UI:R because the victim client must connect to that peer; impact is limited to a likely client crash, so A:L with C:N/I:N.
Description PRE-NVD
Articles & Coverage 2
Executive ViewAI
Apache Qpid Proton C versions up to 0.40.0 contain a high-severity vulnerability that can be triggered by a malicious TLS peer presenting a non-RFC9525-compliant wildcard certificate, leading to a stack buffer over-read and potential client disruption. The flaw primarily affects availability, requiring user interaction to connect to a malicious endpoint, and could impact applications relying on Proton C for secure messaging. Leadership should prioritize remediation to prevent service interruptions and maintain trust in TLS communications.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
In order to decrypt SM2 encrypted data an application is expected to call the API function EVP_PKEY_decrypt(). Rated cri
The dtls1_reassemble_fragment function in d1_both.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to se
The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k
In addition to the c_rehash shell command injection identified in CVE-2022-1292, further circumstances where the c_rehas
The TLS protocol 1.2 and earlier, when a DHE_EXPORT ciphersuite is enabled on a server but not on a client, does not pro
The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which mak
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
The X509_verify_cert function in crypto/x509/x509_vfy.c in OpenSSL 1.0.1n, 1.0.1o, 1.0.2b, and 1.0.2c does not properly
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Rated hig
CVE.org
GitHub PoC
Exploit-DB