Is there a patch available for CVE-2026-7511?

Yes, a patch is available for CVE-2026-7511. Update the affected software to the latest version immediately.

wolfSSL CVE-2026-7511

Q: What is the CVSS score of CVE-2026-7511?

CVE-2026-7511 has a CVSS 4.0 base score of 5.9 (Medium). CVSS vector: CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.1%.

EUVD-2026-39581 MEDIUM

Improper Verification of Cryptographic Signature (CWE-347)

2026-06-25 wolfSSL

GHSA-69q5-vhm6-656f

Jwt Attack Information Disclosure Wolfssl

5.9

CVSS 4.0 · Vendor: wolfSSL

Severity by source

Vendor (wolfSSL) PRIMARY

5.9 MEDIUM

CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

4.8 MEDIUM

Adjacent vector per CVSS 4.0 source; AC:H for required cert bundle crafting; PR:N but passive application interaction needed; integrity-only impact from signer trust confusion.

3.1 AV:A/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N

4.0 AV:A/AC:H/AT:P/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (wolfSSL).

CVSS VectorVendor: wolfSSL

Attack Vector

Adjacent

Attack Complexity

High

Privileges Required

None

User Interaction

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jun 25, 2026 - 22:31 vuln.today

Analysis Generated

Jun 25, 2026 - 22:31 vuln.today

DescriptionCVE.org

PKCS7_verify signer confusion allows forged signatures, where the signer associated with a signature is not correctly bound, permitting a forged signature to be accepted.

AnalysisAI

Signer confusion in wolfSSL's PKCS7_verify implementation allows a crafted PKCS#7 message to report a trusted certificate as the signer even when an attacker-controlled certificate produced the actual signature. Any application using wolfSSL for PKCS#7 signature verification - including JWT workflows flagged in the CVE tags - may incorrectly authorize operations as if from a trusted party. No public exploit has been identified at time of analysis, but the upstream fix is available as GitHub PR #10203 and the vulnerability is straightforwardly reproducible by anyone familiar with PKCS#7 certificate bundle structure.

Technical ContextAI

The vulnerability resides in wolfSSL_PKCS7_get0_signers() within src/ssl_p7p12.c of the wolfSSL embedded TLS/crypto library (CPE: cpe:2.3:a:wolfssl:wolfssl:*:*:*:*:*:*:*:*). PKCS#7 (RFC 2315) is a cryptographic message syntax used for digital signatures, S/MIME, and certificate packaging. The root cause is CWE-347 (Improper Verification of Cryptographic Signature): the function previously always returned singleCert (cert[0], the first certificate in the bundle) as the reported signer, regardless of which certificate actually verified the signature. Because PKCS#7 allows bundling multiple certificates, an attacker can place a trusted CA or end-entity certificate first in the bundle and their own attacker-controlled certificate second; wolfSSL's verification engine uses the attacker cert to validate the signature (which passes), but the identity-reporting function returns the trusted cert as the signer. The fix, visible in PR #10203, introduces a preference for p7->pkcs7.verifyCert (the cert that actually validated the signature) over p7->pkcs7.singleCert. The PR also addresses a related heap-OOB read risk where passing the address of a struct field pointer directly to wolfSSL_d2i_X509 would corrupt the field by advancing the pointer beyond the DER boundary.

RemediationAI

The upstream fix is available as GitHub PR #10203 (https://github.com/wolfSSL/wolfssl/pull/10203); however, a specific tagged release version containing this fix has not been independently confirmed from available data - only the PR reference is present, not a versioned release artifact. Users should monitor https://www.wolfssl.com/docs/security-vulnerabilities/ for a patched release version and upgrade as soon as one is published. As a compensating control prior to patching, applications using PKCS7_verify should independently validate signer identity by cross-checking the certificate returned by wolfSSL_PKCS7_get0_signers() against a locally maintained trusted certificate store, rather than trusting the returned identity at face value; this adds a second verification layer with no functional trade-off for well-designed applications. If PKCS#7 signature verification is not required by the application, disabling the HAVE_PKCS7 compile-time feature flag eliminates the attack surface entirely, with the trade-off of removing all PKCS#7 functionality from the build.