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 does not neutralize CRLF characters in values used by app/vau/VAUProtokoll.py to construct VAU inner HTTP requests. The build_inner_header function interpolates the uri, host, accept_type, content_type, content_length, USER_AGENT, and insurant_id values into request lines and headers, including x-useragent and x-insurantid. An authenticated attacker who controls a value can inject additional headers into the inner request. Depending on ePA server handling, an injected x-insurantid header can expose another patient's records, and injected Authorization headers can bypass the intended authentication or authorization context. Session-derived USER_AGENT input can also poison requests across the session. This issue is fixed in version 1.3.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.8",
  "pubDate": "2026-08-18T17:16:58.633Z",
  "pubdate": "2026-08-18T17:16:58.633Z",
  "executiveSummary": "An improper neutralization of CRLF sequences vulnerability exists in ePA 3.x Integration prior to version 1.3.0 within the VAU inner HTTP request construction mechanism. The vulnerability enables authenticated attackers who control specific input values to inject arbitrary HTTP headers into inner requests processed by the application.\nSuccessful exploitation can lead to severe security implications, including the exposure of unauthorized patient medical records via manipulated x-insurantid headers and the bypass of intended authentication or authorization contexts through injected Authorization headers. Additionally, session-derived USER_AGENT inputs can cause cross-session request poisoning.\nThe affected product is ePA 3.x Integration prior to version 1.3.0. The attack vector requires authentication, and exploitation capabilities depend on ePA server handling of injected header fields. Mitigation requires updating to version 1.3.0 or later to ensure proper sanitization of CRLF characters.",
  "technicalDetails": "The vulnerability resides in the app/vau/VAUProtokoll.py file within the ePA 3.x Integration codebase, specifically inside the build_inner_header function. The root cause is the direct string interpolation of untrusted variables into HTTP request lines and header fields without prior sanitization or neutralization of Carriage Return and Line Feed (CRLF) characters.\nThe vulnerable function processes multiple input parameters, including uri, host, accept_type, content_type, content_length, USER_AGENT, and insurant_id. These values are incorporated directly into request lines and custom headers, such as x-useragent and x-insurantid.\nAn authenticated attacker capable of supplying or controlling any of these input values can inject arbitrary CRLF sequences (\\r\\n) followed by malicious HTTP header fields. Because the underlying protocol constructs inner HTTP requests using unsanitized data, the injected headers are interpreted by the receiving parser as distinct, legitimate headers.\nThe attack flow proceeds as follows: First, the authenticated attacker crafts a malicious payload containing CRLF sequences and targeted HTTP header directives (such as an alternative Authorization header or a modified x-insurantid value). Second, the attacker submits this input through the application workflow where it is processed by build_inner_header in VAUProtokoll.py. Third, the resulting VAU inner request is generated with the injected headers intact. Fourth, depending on how the ePA server processes the request, the injected x-insurantid header forces the retrieval and exposure of another patient's records, while an injected Authorization header bypasses the intended authentication or authorization context.\nFurthermore, session-derived USER_AGENT input can introduce cross-session request poisoning, affecting subsequent operations within the same session context. The vulnerability affects ePA 3.x Integration versions prior to 1.3.0 and requires valid authentication alongside control over applicable input parameters."
}