The vulnerability resides in the way ePA 3.x Integration performs VAU server certificate validation; it fails to anchor the signed_vau_server_pub_keys and AUT_VAU_CertData certificate path to independently trusted material. Because TLS certificate verification is disabled, a malicious entity positioned between the DiGA backend and the ePA system can intercept the VAU handshake, supply its own certificate and key, satisfy the circular trust relationship, and thereby bypass authentication. This allows the attacker to impersonate the VAU server, control the negotiated TLS session keys, and read or modify all encrypted VAU traffic, exposing sensitive medical information and enabling data tampering.

The issue affects the fbeta-GmbH ePA3-Service-OpenSource integration, specifically all releases prior to version 1.3.0. Versions 1.3.0 and later include the fix that restores proper certificate validation and re‑enables TLS verification.

With a CVSS score of 9.1, this flaw poses a high severity risk. The EPSS metric is not available, but the lack of independent server‑authentication and the requirement for a network‑positioned attacker between the DiGA backend and the ePA system suggest a relatively high likelihood of exploitation in environments where such a position is attainable. The vulnerability is not yet listed in CISA’s KEV catalog, but its impact warrants urgent attention.