CVE-2026-52723: ePA 3.x Integration Auth Bypass Flaw

CVE-2026-52723 Overview

CVE-2026-52723 is an improper certificate validation flaw [CWE-295] in the ePA 3.x Integration service, which handles authorization workflows and writes Medical Information Objects to Germany's electronic patient record system. Versions prior to 1.3.0 fail to anchor the Vertrauenswürdige Ausführungsumgebung (VAU) server certificate chain to independent trusted material inside app/vau/VAUProtokoll.py. TLS certificate verification is also disabled in affected versions. A network-positioned attacker between the Digitale Gesundheitsanwendung (DiGA) backend and the ePA system can intercept the VAU handshake and impersonate the VAU server. The issue is fixed in version 1.3.0.

Critical Impact
An attacker performing a man-in-the-middle attack can control VAU session keys and read or modify all encrypted traffic containing protected patient health data.

Affected Products

fbeta-GmbH ePA3-Service-OpenSource versions prior to 1.3.0
ePA 3.x Integration component app/vau/VAUProtokoll.py
Deployments processing Medical Information Objects for Germany's electronic patient record

Discovery Timeline

2026-08-18 - CVE-2026-52723 published to NVD
2026-08-18 - Last updated in NVD database

Technical Details for CVE-2026-52723

Vulnerability Analysis

The ePA 3.x Integration service implements the VAU protocol to communicate securely with Germany's electronic patient record backend. The VAU handshake exchanges a signed server public key bundle (signed_vau_server_pub_keys) and authentication certificate data (AUT_VAU_CertData) to establish session keys.

In versions before 1.3.0, the certificate validation logic inside app/vau/VAUProtokoll.py verifies the signed_vau_server_pub_keys and AUT_VAU_CertData against material transported within the same handshake. This produces a circular trust relationship where attacker-supplied certificates validate against attacker-supplied signing material. TLS certificate verification is additionally disabled, removing the transport-layer server authentication check that would otherwise catch the substitution.

Root Cause

The root cause is missing anchoring of the VAU certificate path to an independent, out-of-band trust store, combined with disabled TLS verification. Neither the application-layer VAU handshake nor the transport-layer TLS connection performs authenticated server identity validation using pre-established trusted certificate authorities.

Attack Vector

A network-positioned attacker between the DiGA backend and the ePA system intercepts the VAU handshake. The attacker supplies a full set of attacker-controlled certificates and keys that satisfy the internal consistency checks. Because the service does not compare these against a trusted root, the handshake completes successfully. The attacker then negotiates session keys and can decrypt, modify, or replay all VAU traffic containing patient medical data.

python

# Security patch excerpt - app/runtime_config/constants.py
# Source: https://github.com/fbeta-GmbH/ePA3-Service-OpenSource/commit/197c8c7fc41675f19c7f448696a2bc63fab9db5b

KONNEKTOR_CA_BUNDLE = kon_ts.build_ca_bundle()

if KONNEKTOR_CA_BUNDLE and KONNEKTOR_JWS_URL:
    logger.info("Konnektor identity verification is ENABLED.")
elif KONNEKTOR_CA_BUNDLE:
    logger.warning(
        f"Konnektor identity verification is ENABLED using existing certificate bundle at {KONNEKTOR_CA_BUNDLE}, "
        "but KONNEKTOR_JWS_URL is not set, so automatic refresh of the bundle is not available."
    )
else:
    logger.error(
        "Konnektor identity verification is DISABLED - the service cannot confirm it is talking to the real Konnektor. "
        "This is NOT recommended for production use."
    )

TI_PKI_ROOTS_DIR = ti_ts.get_root_ca_path()

The patch introduces an independent trust anchor via TI_PKI_ROOTS_DIR and enforces Konnektor identity verification through an external CA bundle rather than material supplied during the handshake.

Detection Methods for CVE-2026-52723

Indicators of Compromise

Unexpected VAU handshake completions with certificates not chaining to the official Telematikinfrastruktur (TI) PKI roots
TLS connections to VAU endpoints where certificate verification was skipped or logs show verify=False
Anomalous DNS resolution or routing changes for VAU server hostnames on paths between DiGA backends and the ePA system
Presence of the vulnerable app/vau/VAUProtokoll.py from ePA3-Service-OpenSource versions prior to 1.3.0

Detection Strategies

Inventory all deployments of the fbeta-GmbH ePA3-Service and confirm the running version against release 1.3.0
Inspect application configuration for disabled TLS verification flags and log outputs indicating disabled Konnektor identity verification
Compare observed VAU server certificates against the expected TI PKI trust anchors and alert on mismatches

Monitoring Recommendations

Capture and retain full network flow metadata between DiGA backends and ePA endpoints for retrospective analysis
Alert on TLS sessions to VAU hosts that present certificates issued by unexpected CAs
Log every invocation of the VAU handshake with the certificate fingerprints used, and forward these logs to a centralized SIEM for correlation

How to Mitigate CVE-2026-52723

Immediate Actions Required

Upgrade ePA3-Service-OpenSource to version 1.3.0 or later, available at the GitHub Release 1.3.0 page
Configure KONNEKTOR_JWS_URL and provision the Konnektor CA bundle so that identity verification runs in ENABLED state
Restrict network paths between the DiGA backend and the ePA system to trusted infrastructure and enforce mutual TLS where feasible
Rotate any keys or credentials that may have transited a vulnerable VAU session

Patch Information

The fix is available in ePA3-Service-OpenSource release 1.3.0. Technical details are documented in the GitHub Security Advisory GHSA-q2jw-6c4w-86jc, the GitHub Pull Request #12, and the remediation commit 197c8c7. Additional context is available in the Machine Spirits Advisory.

Workarounds

If immediate upgrade is not possible, place the ePA integration on an isolated network segment with no untrusted intermediaries between the DiGA backend and the ePA endpoints
Terminate service traffic and disable the ePA 3.x Integration until version 1.3.0 can be deployed, since no runtime configuration in affected versions restores independent certificate validation

bash

# Configuration example for the patched version
# Set required environment variables in .env before starting the service
KONNEKTOR_JWS_URL="https://<trusted-jws-endpoint>"
KONNEKTOR_CA_BUNDLE_PATH="/etc/epa3/konnektor-ca-bundle.pem"
TI_PKI_ROOTS_DIR="/etc/epa3/ti-pki-roots"

# Verify Konnektor identity verification is ENABLED in service logs
grep "Konnektor identity verification is ENABLED" /var/log/epa3-service.log