CVE-2026-50576 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 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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The ePA 3.x Integration component serves as a critical bridge for implementing authorization workflows and writing Medical Information Objects to Germany's electronic patient record system. In versions prior to 1.3.0, the software contains a significant input validation flaw within its HTTP request construction logic. Specifically, the application fails to neutralize Carriage Return Line Feed (CRLF) characters in user-controlled values before they are used to construct inner HTTP requests for VAU protocols. This vulnerability arises because the build_inner_header function interpolates various inputs such as URI, host, accept type, content type, content length, USER_AGENT, and insurant_id directly into request lines and headers without adequate sanitization of control characters.
The technical nature of this flaw is a classic CRLF injection or HTTP response splitting vulnerability that extends to header injection in server-to-server communications. By injecting newline sequences, an attacker can terminate the current header line prematurely and introduce new, arbitrary HTTP headers into the inner request sent by the integration component. This bypasses standard parsing boundaries because the underlying HTTP library interprets the injected characters as structural delimiters rather than literal data values. The vulnerability affects multiple fields including x-useragent and x-insurantid, allowing for precise manipulation of the outbound traffic generated by the application.
The operational impact of this vulnerability is severe due to its potential to compromise patient privacy and system integrity. An authenticated attacker who controls any of the vulnerable input parameters can inject additional headers into the inner request. If an attacker injects a custom x-insurantid header, they may trick the backend ePA server into returning medical records belonging to a different patient, leading to unauthorized access to sensitive health information. Furthermore, injecting Authorization headers allows the attacker to bypass intended authentication or authorization contexts entirely, potentially granting elevated privileges or access to restricted resources without valid credentials. Additionally, session-derived USER_AGENT input can be poisoned, causing malicious requests to persist across the user's entire session and affecting subsequent interactions with downstream services.
This vulnerability aligns with CWE-74 Improper Neutralization of Special Elements in Output Used by a Command, Program, or Interpreter, specifically regarding HTTP header injection. It also maps to MITRE ATT&CK techniques related to Injection attacks where an adversary manipulates input data to alter the execution flow or access control decisions of the target system. The exploitation path typically involves identifying parameters that are reflected into HTTP headers and crafting payloads containing CRLF sequences followed by the desired malicious headers such as Authorization, X-Insurant-ID, or other custom fields that influence server-side behavior.
To mitigate this vulnerability, organizations must upgrade to version 1.3.0 of ePA 3.x Integration where the issue has been resolved through proper input validation and encoding mechanisms. For systems unable to immediately patch, defensive measures include implementing strict allow-listing for header values, ensuring all user inputs are encoded or escaped before being concatenated into HTTP headers, and deploying Web Application Firewalls configured to detect CRLF injection patterns in request payloads. Regular security audits focusing on data flow analysis can help identify similar interpolation flaws in other components of the integration suite that handle external input within internal service communications.