VAU Server Authentication Bypass

Description

public byte[] receiveMessage2(byte[] message2) {
    return vauStateMachine.receiveMessage2(message2);
}

VauPublicKeys transferredSignedServerPublicKeyList = signedPublicVauKeys.extractVauKeys();
checkCertificateExpired(transferredSignedServerPublicKeyList.getExp());

Impact

• A network-positioned attacker between epa4all and the ePA Aktensystem intercepts the VAU handshake, returns self-signed VAU public keys with a self-signed certificate, and the client accepts both. The attacker derives the same K2 session keys as the client and owns the resulting encrypted channel.
• In the production deployment model the attacker model fits the LAN. epa4all ships as an on-premise Docker container (servicehealtherxgmbh/epa4all) intended to sit in a doctor's practice; the container is reachable from the local network and connects outbound to the ePA backend.
• A MITM holding the session keys can read and modify all inner HTTP traffic on the VAU channel: patient consent decisions, medication data, document uploads, authorization tokens, and entitlement queries. During testing, a single relay read one patient's consent decisions, swapped insurant IDs and decision values on a second response, and injected a third patient's record entirely, all from a self-signed certificate with no CA chain.

Mitigation

Update to a build dated 2026-05-20 or later. The vendor's fix adds certificate and hostname checks for lib-vau and a keystore based on the Telematik TSL, so the ES256 signature on SignedPublicVauKeys is verified against a trusted certificate from the TI PKI. No workaround exists for affected builds; transport-layer pinning alone does not authenticate the VAU server, and the parallel med-united: TLS Certificate Verification Disabled means there is no transport-layer pinning to lean on in the first place. Both fixes are required.

Defender's Checklist

• Update to the 2026-05-20 build or later.

  All 1.0.0-SNAPSHOT builds before that date are affected. The fix adds the Telematik-TSL keystore and wires up the SignedPublicVauKeys signature check on the client side.

• Verify the TI PKI root anchors actually load at runtime.

  The standard JVM/system trust store does not contain TI PKI roots. Confirm your deployment sources them from gemSpec_PKI's TI Root CA bundle and that the keystore is loaded before the first VAU handshake.

• Pair this fix with the TLS verification fix.

  Even with VAU server authentication added, TLS verification across outbound connections must be re-enabled in the same build. The two fixes are independent and both required; see med-united: TLS Certificate Verification Disabled.

• Test with a self-signed peer.

  Stand up a local VAU peer that responds to Message 2 with attacker-controlled public keys, a self-signed cert, and arbitrary signatureEs256 bytes. The client must refuse the handshake. If it does not, the validator is not wired in.

Severity Reasoning

References

• GHSA-vvh7-x6c7-46gh (med-united)
• med-united epa4all Repository
• gematik lib-vau (reference, vendored)
• gemSpec_Krypt A_24624-01 (Client verification of server's signed public keys)
• Related: TLS Certificate Verification Disabled
• Related upstream: VAU Handshake Performs Only 2 of 6 Required Server-Key Checks
• Related: ePA-VAU Client Security overview

How We Can Help

• MDR Penetration Testing