CVE-2026-47672
Description
epa4all-client is the Java Client for epa4all / ePA 3.0 in the Telematik Infrastruktur. In 1.2.4 and earlier, any network-reachable caller can write arbitrary documents to any patient's electronic health record accessible by the institution's SMC-B card. In a misconfigured deployment (e.g., following the production Docker example in the README), this is exploitable from the local network without credentials.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
An unauthenticated REST API in epa4all-client 1.2.4 and earlier allows any network-reachable caller to write arbitrary documents to any patient's electronic health record accessible via the institution's SMC-B card.
Vulnerability
The epa4all-client is the Java Client for epa4all / ePA 3.0 in the Telematik Infrastruktur. In versions 1.2.4 and earlier, the REST API does not enforce authentication, allowing any network-reachable caller to write arbitrary documents to any patient's electronic health record accessible by the institution's SMC-B card [1]. The vulnerability is particularly exploitable in misconfigured deployments that follow the production Docker example in the README [2].
Exploitation
An attacker needs only network reachability to the service. If the deployment follows the production Docker example, the service may be exposed on the local network without any authentication, making exploitation possible from any host on that network without credentials [1][2]. The attacker can send crafted API requests to write arbitrary documents to any patient's electronic health record that the institution's SMC-B card can access.
Impact
Successful exploitation allows an attacker to write arbitrary documents to patients' electronic health records. This compromises the integrity and availability of health data, potentially leading to incorrect medical information being stored. The confidentiality of patient records may also be impacted if the attacker can read or modify sensitive data. The compromise happens at the level of the SMC-B card's access scope, meaning all patients accessible by the institution are at risk [1][2].
Mitigation
A fix is available via pull request #43 [1], but no official patched version has been released as of the publication date. The workaround involves using network policies or proxies to enforce service-to-service authentication, for example via mTLS. Additionally, running the service in an isolated network namespace (e.g., as a Kubernetes sidecar) or using a service mesh with corresponding policies can mitigate exposure [2].
AI Insight generated on May 26, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2(expand)+ 1 more
- (no CPE)
- (no CPE)range: <=1.2.4
Patches
14746f1dbab91EPA-275: Updated Docs (#43)
2 files changed · +8 −1
epa4all-rest-service/README.md+5 −1 modified@@ -2,6 +2,10 @@ Small wrapper around the epa4all client library. +> [!CAUTION] +> The rest adapter does not support any authentication nor authorization. It must be used in a trusted environment, e.g. +> as a Kubernetes side-car or with a reverse proxy. + ### API Specification **[openapi.yaml](./src/main/resources/META-INF/openapi/openapi.yaml)** @@ -25,7 +29,7 @@ curl -X 'POST' \ #### PU with jumphost > [!WARNING] -> This is the example for PRODUCTION. Handle with care ;) +> This is the example for PRODUCTION. This is assumed to run in a trusted environment. ```shell docker run --rm \ -e 'EPA4ALL_KONNEKTOR_URI=https://10.156.120.103:443' \
README.md+3 −0 modified@@ -48,6 +48,9 @@ docker run --rm \ ghcr.io/oviva-ag/epa4all-rest-service:latest ``` +> [!CAUTION] +> The rest adapter does not support any authentication nor authorization. It must be used in a trusted environment, e.g. as a Kubernetes side-car or with a reverse proxy. + ## docker-compose with userspace wireguard This would be an example on how to run the epa4all-rest-service with a VPN connection to the Konnektor. The VPN connection is established via a userspace wireguard implementation. The service uses the network stack of the VPN container. To achieve this, not setting the `EPA4ALL_PROXY_ADDRESS` is enough.
Vulnerability mechanics
Synthesis attempt was rejected by the grounding validator. Re-run pending.
References
2News mentions
0No linked articles in our index yet.