CVE-2026-50577 in ePA3-Service-OpenSource
Summary
by MITRE • 08/18/2026
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 leaves request_counter unchanged in app/vau/VAUProtokoll.py while constructing VAU messages. The frozen client request counter causes the server side to reuse AES-GCM nonce and key combinations across responses. A network attacker who collects repeated ciphertexts can recover the XOR of plaintexts and use predictable inner HTTP headers and JSON fields to recover sensitive data, including patient health records. Repeated nonces can also enable recovery of the GHASH authentication key through the Joux forbidden attack, allowing forged AES-GCM messages and injection of malicious responses. The response-counter check also fails to maintain last_response_counter, weakening replay and ordering validation. This issue is fixed in version 1.3.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability resides within the ePA 3.x Integration software used for managing Germany's electronic patient record system. Specifically, it affects versions prior to 1.3.0 where the application fails to properly manage cryptographic state during the construction of VAU messages. The core technical flaw is a failure in incrementing the request counter located in the app/vau/VAUProtokoll.py module. This oversight results in the client sending multiple requests with an identical, frozen nonce value when communicating with the server. In secure communication protocols utilizing AES-GCM encryption, each message must be encrypted with a unique nonce combined with the same key to maintain confidentiality and integrity. By reusing the same nonce-key pair across multiple responses, the system violates fundamental cryptographic principles required for authenticated encryption.
The operational impact of this flaw is severe, as it exposes sensitive patient health records to potential compromise by network attackers who can intercept traffic between the client and server. Because AES-GCM relies on XOR operations during its encryption process, reusing a nonce allows an attacker to perform a known-plaintext attack or ciphertext-only analysis if they possess partial knowledge of the message structure. By collecting repeated ciphertexts encrypted with the same key and nonce, an adversary can recover the XOR of the plaintexts. Given that HTTP headers and JSON fields often contain predictable patterns or static values, this predictability enables the attacker to isolate and extract sensitive data from the remaining unknown portions of the messages. This directly compromises patient privacy and violates regulatory requirements for protecting electronic health information.
Beyond confidentiality breaches, the vulnerability introduces critical integrity risks through the Joux forbidden attack vector. When AES-GCM nonces are reused, an attacker can exploit mathematical properties of the GHASH function to recover the authentication key used for generating message authentication codes. Once this key is derived, the attacker gains the ability to forge valid AES-GCM messages without detection by the receiving party. This capability allows for the injection of malicious responses into the communication stream, potentially altering medical records or injecting fraudulent data that could lead to incorrect clinical decisions. Furthermore, the implementation fails to maintain a last_response_counter, which weakens replay protection and message ordering validation. Without proper sequence tracking, attackers can also reorder or duplicate messages, further undermining the reliability and trustworthiness of the electronic patient record system.
To mitigate this vulnerability, organizations must upgrade ePA 3.x Integration to version 1.3.0 or later, where the request counter logic has been corrected to ensure unique nonces are generated for each cryptographic operation. In environments where immediate patching is not feasible, network-level controls such as TLS inspection with strict certificate validation can help detect anomalies in encrypted traffic patterns, although this does not fully address the application-layer flaw. Security teams should also audit logging mechanisms to monitor for unusual repetition of request identifiers or response sequences that might indicate exploitation attempts. This issue aligns with CWE-328, which describes the use of a single nonce for multiple messages under AES-GCM, and is relevant to MITRE ATT&CK techniques involving cryptographic failures and data injection attacks. Ensuring strict adherence to cryptographic best practices in healthcare software development is essential to maintaining the integrity and confidentiality of sensitive medical data.