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 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-08-18T17:16:58.790Z",
  "pubdate": "2026-08-18T17:16:58.790Z",
  "executiveSummary": "The ePA 3.x Integration module contains a critical cryptographic vulnerability involving the reuse of AES-GCM nonce and key combinations due to a static request counter. This flaw impacts ePA 3.x Integration versions prior to 1.3.0.\nThe root cause stems from the application leaving request_counter unchanged within app/vau/VAUProtokoll.py during the construction of VAU messages. Consequently, the server-side component reuses the same AES-GCM nonce and encryption key across multiple responses.\nA network-positioned attacker who collects repeated ciphertexts can perform cryptographic analysis to recover the XOR of plaintexts. By leveraging predictable inner HTTP headers and JSON fields, the adversary can extract highly sensitive data, including patient health records.\nFurthermore, the repetition of nonces allows attackers to execute the Joux forbidden attack to recover the GHASH authentication key. This cryptographic compromise enables the forging of arbitrary AES-GCM messages and the injection of malicious server responses.\nAdditionally, a failing response-counter check weakens replay protection and message ordering validation. Exploitation requires network access to intercept and collect repeated ciphertexts without requiring prior authentication or elevated privileges.",
  "technicalDetails": "The vulnerability resides in the VAU message construction logic implemented in the vulnerable file app/vau/VAUProtokoll.py of the ePA 3.x Integration product, specifically in versions prior to 1.3.0.\nThe primary root cause is the failure to increment or update the request_counter variable during VAU message generation. In authenticated encryption modes like AES-GCM, the uniqueness of the nonce combined with the secret key is an absolute security requirement. Reusing a nonce with the same key completely breaks the confidentiality and integrity guarantees of AES-GCM.\nFrom an exploitation perspective, the attack flow proceeds through several distinct phases. First, a network attacker passively intercepts network traffic to collect multiple ciphertexts generated under the same AES-GCM key and reused nonce combinations.\nSecond, because AES-GCM operates as a stream cipher when generating ciphertexts via XOR with the keystream, reusing the nonce yields identical keystreams for different plaintexts. An attacker can compute the XOR of two ciphertexts, which mathematically equals the XOR of the two underlying plaintexts (C1 XOR C2 = P1 XOR P2).\nThird, utilizing the predictable nature of inner HTTP headers and structured JSON fields within the ePA data exchange, the attacker can systematically peel away the XOR mask to recover sensitive plaintext data, ultimately exposing confidential patient health records.\nFourth, the repeated use of identical nonces enables the application of the Joux forbidden attack against the GHASH function utilized in AES-GCM authentication tags. Successful execution of this attack permits the recovery of the GHASH authentication key.\nOnce the GHASH key is compromised, the attacker transitions from a passive eavesdropper to an active adversary, gaining the capability to forge valid authentication tags for arbitrary ciphertexts. This allows the attacker to inject malicious responses and spoof server communications.\nFinally, the concurrent failure of the response-counter check to correctly maintain last_response_counter exacerbates the cryptographic weaknesses by undermining replay prevention and message sequence validation.\nThe affected component is exposed at the network layer during authorization workflows and Medical Information Object transmission. Exploitation can be executed by any network attacker capable of intercepting traffic, and no pre-existing authentication or specific user privileges are required."
}