CVE-2026-54342: epa4all Information Disclosure Vulnerability

CVE-2026-54342 Overview

CVE-2026-54342 is an improper certificate validation flaw [CWE-295] in epa4all, a client used to interact with the German electronic patient record (ePA) infrastructure. Versions prior to 2026-05-20 fail to verify TLS certificates presented by backend services, including the ePA Aktensystem, Konnektor, Identity Provider (IDP), and Trusted Service Status (TSS) endpoints. An attacker positioned on the adjacent network can present a self-signed certificate and intercept traffic. The intercepted channels carry smartcard operations and OpenID Connect (OIDC) authentication exchanges.

Critical Impact
An adjacent-network attacker can read and modify healthcare traffic, including smartcard operations and OIDC exchanges, and enable the VAU MITM chain documented in GHSA-vvh7-x6c7-46gh.

Affected Products

epa4all versions prior to 2026-05-20
Deployments connecting to ePA Aktensystem, Konnektor, IDP, and TSS backends
Environments relying on epa4all for OIDC authentication and smartcard flows

Discovery Timeline

2026-07-24 - CVE-2026-54342 published to the National Vulnerability Database (NVD)
2026-07-30 - Last updated in NVD database
2026-05-20 - Fixed release 2026-05-20 published on GitHub

Technical Details for CVE-2026-54342

Vulnerability Analysis

The vulnerability stems from disabled TLS certificate verification in the epa4all client. When epa4all establishes outbound TLS connections to backend services, it accepts any certificate presented, including self-signed certificates that do not chain to a trusted root. This design defect enables an attacker on the network path to complete a TLS handshake as an impersonated backend.

For non-VAU connections such as the Konnektor and IDP, the attacker gains direct read and write access to the inner protocol traffic. This includes smartcard operation payloads and OIDC authentication exchanges used to authorize access to patient records. For the ePA Aktensystem backend, the missing TLS verification acts as the transport-layer prerequisite for the Vertrauenswürdige Ausführungsumgebung (VAU) MITM attack described in GHSA-vvh7-x6c7-46gh.

Root Cause

The epa4all HTTPS client did not enforce hostname or trust-chain validation on backend TLS sessions. This is a classic CWE-295 failure where certificate validation is skipped or misconfigured, breaking the trust anchor that TLS depends on.

Attack Vector

Exploitation requires network-adjacent positioning between the epa4all deployment and any backend service. Techniques include ARP spoofing, rogue DHCP, malicious upstream routing, or compromise of an intermediate network device. The attacker presents a self-signed certificate for the target backend hostname. Because epa4all does not validate the certificate, the client establishes the TLS session with the attacker and forwards sensitive traffic through the attacker-controlled proxy.

No verified public exploit code is available. Technical details are documented in the GitHub Security Advisory GHSA-296w-v8f6-3rf7 and the related GHSA-vvh7-x6c7-46gh advisory.

Detection Methods for CVE-2026-54342

Indicators of Compromise

Unexpected self-signed or untrusted certificates observed on TLS sessions from epa4all hosts to ePA, Konnektor, IDP, or TSS endpoints.
ARP table anomalies or gateway MAC address changes on network segments running epa4all.
Unusual TLS session resumption failures or certificate fingerprint mismatches in outbound connections from epa4all.

Detection Strategies

Passively capture TLS handshakes from epa4all hosts and alert on certificates that do not match known-good backend fingerprints.
Inspect outbound connections for certificate issuers outside the approved gematik TSL (Trust Service Status List) chain.
Correlate epa4all process network activity with unexpected destination IPs or non-standard TCP paths.

Monitoring Recommendations

Instrument network sensors on segments hosting epa4all to log TLS certificate metadata for every backend session.
Establish a baseline of legitimate backend certificate fingerprints and alert on deviation.
Monitor for Layer 2 anomalies including ARP spoofing and duplicate IP events on healthcare network segments.

How to Mitigate CVE-2026-54342

Immediate Actions Required

Upgrade epa4all to version 2026-05-20 or later, available from the GitHub Release 2026-05-20.
Inventory all epa4all deployments and confirm patch status against the fixed release tag.
Rotate credentials, smartcard PINs, and OIDC session tokens that may have transited unverified TLS sessions.

Patch Information

The issue is fixed in epa4all release 2026-05-20. The patch restores TLS certificate verification for all backend connections. See the Machine Spirits Security Advisory and the GitHub Security Advisory GHSA-296w-v8f6-3rf7 for vendor-provided details.

Workarounds

Restrict epa4all egress to explicit backend IP addresses through firewall allowlists until the patch is applied.
Enforce network segmentation to remove untrusted hosts from the adjacent broadcast domain of epa4all systems.
Deploy static ARP entries for gateways and backend hosts to reduce Layer 2 spoofing opportunities.

bash

# Configuration example: verify installed epa4all version and upgrade
git -C /opt/epa4all describe --tags
git -C /opt/epa4all fetch --tags
git -C /opt/epa4all checkout 2026-05-20