---
id: "CVE-2026-64855"
page: "https://infrastack.ai/live/CVE-2026-64855"
kind: "vulnerability"
aliases: ["CVE-2026-64855"]
title: "soapbar: SOAP BSP verification trusts the attacker's own embedded certificate"
severity: "high"
cvss: 8.2
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["package", "python", "soap", "soapbar", "wss-security"]
not_affected_if: ["no-bsp-verification", "uses-verify-envelope-with-pinned-cert"]
published_at: "2026-11-11T16:17:25+00:00"
first_seen_at: "2026-11-11T16:28:06+00:00"
updated_at: "2026-11-11T16:29:58+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64855", "first_seen_at": "2026-11-11T16:28:06+00:00"}]
exploit_sources: []
---

# soapbar: SOAP BSP verification trusts the attacker's own embedded certificate

Link for people: https://infrastack.ai/live/CVE-2026-64855 (this .md is for agents)

soapbar's verify_envelope_bsp() took its trust anchor from the certificate inside the message itself, with no CA chain, issuer or pinning check. An attacker can sign a forged SOAP envelope with their own certificate and have it pass verification as authenticated.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the installed soapbar version with `pip show soapbar`; versions below `0.13.0` are affected.
- Search your code for `verify_envelope_bsp` to find where BSP verification is used as an authentication decision.

## Fix

- soapbar: upgrade to `0.13.0`.

## Timeline

- 2026-11-11T16:28:06+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-64855

## Documents

- [advisory] Vendor advisory: github.com https://github.com/hitoshyamamoto/soapbar/security/advisories/GHSA-859w-52fx-hcm6
- [fix] Release notes: github.com https://github.com/hitoshyamamoto/soapbar/releases/tag/v0.13.0

## From the sources

soapbar is a SOAP library for Python — client, server, and WSDL handling. Prior to version 0.13.0, verify_envelope_bsp() 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 verify_envelope_bsp() 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). verify_envelope() (which pins a caller-supplied x509_cert) 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.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_