CVE-2026-64855: soapbar: verify_envelope_bsp accepts an unauthenticated embedded certificate (signature forgery / authentication bypass)
soapbar is a SOAP library for Python — client, server, and WSDL handling. Prior to version 0.13.0, verifyenvelopebsp() derived its trust anchor from the message it was verifying. It read the X.509 certificate out of the caller-untrusted wsse:BinarySecurityToken, validated only that certificate's not-before / not-after dates, and then verified the signature against that same certificate. There was no CA-chain validation, no issuer/subject allowlist, and no pinning. A successful verifyenvelopebsp() therefore proved only that the envelope was signed by whoever supplied the embedded certificate — never that it was signed by a trusted party. An attacker who mints their own certificate, signs a forged envelope, and embeds that certificate in the token passes verification. Any consumer that treats a successful BSP verification as authentication can be impersonated (signature forgery / authentication bypass). verifyenvelope() (which pins a caller-supplied x509cert) was not affected — the flaw was specific to the BSP variant whose trust anchor came from the message. This issue has been patched in version 0.13.0.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
soapbarto a version that resolves this vulnerability.Fixed in 0.13.0
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using soapbar before version 0.13.0 are exposed if they use verify_envelope_bsp() and treat successful verification as proof that a SOAP sender is authenticated. Uses of verify_envelope() with a caller-supplied pinned x509_cert are not affected.
What does an attacker need to exploit it?
An attacker can mint their own currently valid X.509 certificate, sign a forged SOAP envelope, and place that certificate in the untrusted wsse:BinarySecurityToken. No trusted CA-issued certificate or existing signing credential is required.
Are certificate validity dates or signature checks sufficient mitigation?
No. The vulnerable function checks the embedded certificate's not-before and not-after dates and verifies the signature against that same attacker-supplied certificate, but it does not validate a CA chain, apply an issuer or subject allowlist, or pin a certificate.
What should be done if an immediate upgrade is not possible?
Do not use verify_envelope_bsp() as an authentication control. Use verify_envelope() with a caller-supplied pinned x509_cert instead, or otherwise enforce trust using a certificate or issuer allowlist outside the vulnerable verification path.
How can I determine whether my application is affected?
Review the soapbar version and code paths that validate inbound SOAP signatures. Applications below 0.13.0 that call verify_envelope_bsp() are affected; calls to verify_envelope() that supply a pinned x509_cert are not.