CVE-2026-47672: epa4all-client Auth Bypass Vulnerability

CVE-2026-47672 Overview

CVE-2026-47672 is a missing authentication vulnerability [CWE-306] in epa4all-client, the Java client for epa4all / ePA 3.0 in the German Telematik Infrastruktur. Versions 1.2.4 and earlier expose document write operations without requiring caller authentication. Any network-reachable attacker can write arbitrary documents to any patient's electronic health record accessible via the institution's SMC-B card. In deployments that follow the production Docker example in the project README, the service is reachable from the local network without credentials, making exploitation straightforward.

Critical Impact
Adjacent-network attackers can inject arbitrary documents into patient electronic health records without authentication, compromising the integrity of protected health data.

Affected Products

epa4all-client versions 1.2.4 and earlier
Deployments following the production Docker example from the project README
Integrations using epa4all / ePA 3.0 with an institutional SMC-B card

Discovery Timeline

2026-05-26 - CVE-2026-47672 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-47672

Vulnerability Analysis

The epa4all-client exposes endpoints that perform document write operations against patient electronic health records (ePA 3.0). These endpoints rely on the institution's SMC-B card to authenticate to the Telematik Infrastruktur backend, but they do not authenticate the caller invoking the client itself.

Any actor able to reach the client over the network can submit document upload requests. The client then signs and forwards those requests using the institutional credentials, granting the attacker the same write privileges as the operating institution. The attack is limited to integrity impact, as the flaw enables writes rather than reads or service disruption.

Root Cause

The root cause is missing authentication for a critical function [CWE-306]. The document write API lacks any caller authentication or authorization layer. The design assumes the client runs in a trusted, isolated context, but the README's production Docker example binds the service in a way that makes it reachable from the local network.

Attack Vector

The attack vector is adjacent network: an attacker on the same local network segment as the deployed client can send crafted HTTP requests to the document write endpoint. No credentials, tokens, or user interaction are required. The client then uses the SMC-B-backed session to write attacker-supplied documents to any patient record the institution can access. Technical details are documented in the GitHub Security Advisory GHSA-c82x-f4xr-qv33 and the remediation pull request.

Detection Methods for CVE-2026-47672

Indicators of Compromise

Unexpected document upload requests to the epa4all-client HTTP listener originating from hosts other than the intended backend application.
Document write events in the ePA 3.0 backend correlated to patient records the institution did not intentionally update.
Network connections to the client's exposed port from unmanaged or unexpected local network segments.

Detection Strategies

Inspect access logs of the epa4all-client process for write endpoint invocations and compare source IPs against the approved internal caller allowlist.
Audit ePA 3.0 document submission records signed with the institution's SMC-B card and reconcile them against the institution's own workflow logs.
Monitor for new listening sockets bound to non-loopback interfaces on hosts running the client container.

Monitoring Recommendations

Alert on any inbound traffic to the client's TCP port from outside the trusted application subnet.
Track anomalous spikes in document upload volume or off-hours write activity associated with the SMC-B card.
Capture and retain full request bodies for the document write endpoint to support post-incident forensics.

How to Mitigate CVE-2026-47672

Immediate Actions Required

Upgrade epa4all-client to a version newer than 1.2.4 that includes the fix from the upstream pull request #43.
Restrict network exposure of the client so only the intended backend application can reach it, using host firewall rules or container network policies.
Review ePA 3.0 audit logs for unauthorized document writes since the client was first deployed.

Patch Information

The maintainers addressed the issue in the oviva-ag/epa4all-client repository. Operators should update to the patched release and rebuild any container images derived from the vulnerable README example. Refer to GHSA-c82x-f4xr-qv33 for the official advisory.

Workarounds

Bind the client's listener to 127.0.0.1 instead of 0.0.0.0 so it is not reachable from the local network.
Place the client behind an authenticating reverse proxy that enforces mutual TLS or token-based access control.
Segment the host running the client into a dedicated network with strict ingress filtering from approved application hosts only.

bash

# Configuration example: restrict Docker port binding to loopback
docker run -d \
  --name epa4all-client \
  -p 127.0.0.1:8080:8080 \
  oviva-ag/epa4all-client:patched