Description

ePA 3.x Integration implements the authorization workflow and writes Medical Information Objects to Germany's electronic patient record. Prior to 1.3.0, ePA 3.x Integration performs VAU server certificate validation in app/vau/VAUProtokoll.py without anchoring the signed_vau_server_pub_keys and AUT_VAU_CertData certificate path to independent trusted material. A network-positioned attacker between the DiGA backend and the ePA system can intercept the VAU handshake, supply attacker-controlled certificate and key material, and satisfy the circular trust relationship. Because TLS certificate verification is also disabled in affected versions, no independent server-authentication layer prevents the attack. The attacker can impersonate the VAU server, control the negotiated session keys, and read or modify all encrypted VAU traffic. This issue is fixed in version 1.3.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-08-18T17:16:59.200Z",
  "pubdate": "2026-08-18T17:16:59.200Z",
  "executiveSummary": "The ePA 3.x Integration product prior to version 1.3.0 suffers from a critical certificate validation vulnerability in its authorization workflow and Medical Information Object writing processes. The root cause stems from the improper anchoring of the signed_vau_server_pub_keys and AUT_VAU_CertData certificate path to independent trusted material within the vulnerable app/vau/VAUProtokoll.py component, coupled with disabled TLS certificate verification. An unauthenticated network-positioned attacker situated between the DiGA backend and the ePA system can exploit this flaw by intercepting the VAU handshake and supplying attacker-controlled certificate and key material that satisfies the circular trust relationship. The resulting impact allows the adversary to successfully impersonate the VAU server, control the negotiated session keys, and perform full read and write operations on all encrypted VAU traffic passing between the systems. This severe exposure compromises the confidentiality and integrity of sensitive electronic patient records. Remediation requires updating the affected product to version 1.3.0 or later, where the improper trust anchoring and verification issues are fully resolved.",
  "technicalDetails": "The vulnerability resides in the VAU server certificate validation logic implemented within app/vau/VAUProtokoll.py of the ePA 3.x Integration product, affecting all versions prior to 1.3.0. During the establishment of the VAU protocol handshake, the application is responsible for securely validating cryptographic credentials and establishing a trusted channel for writing Medical Information Objects to Germany's electronic patient record infrastructure. The core technical defect is that the implementation fails to anchor the signed_vau_server_pub_keys and the AUT_VAU_CertData certificate path to an independent, pre-configured root of trust or externally verified trust material. Instead, the verification logic permits a circular trust relationship where presented keys and certificates can be accepted without validating them against a secure, independent baseline. Furthermore, standard TLS certificate verification is disabled within the affected versions, eliminating any secondary server-authentication layer that might otherwise detect or prevent anomalous certificate presentations. Because no authentication or elevated privileges are required to initiate network communications, an adversary positioned on the network path between the DiGA backend and the ePA system can execute a man-in-the-middle attack. The exploitation flow proceeds as follows: First, the network-positioned attacker intercepts the initial VAU handshake requests traversing the network. Second, the attacker supplies their own attacker-controlled certificate and cryptographic key material in place of the legitimate server credentials. Third, because app/vau/VAUProtokoll.py evaluates the supplied material against the flawed, unanchored circular trust logic and TLS verification is disabled, the system incorrectly accepts the fraudulent credentials as valid. Fourth, the handshake completes successfully with the malicious entity rather than the legitimate VAU server. Finally, the attacker achieves full control over the negotiated session keys, enabling them to transparently intercept, decrypt, read, modify, and forge all encrypted VAU traffic exchanged between the DiGA backend and the ePA system, leading to complete compromise of the transmitted medical data."
}