The epa4all-client Java component fails to properly verify the cryptographic signature of the discovery document presented by the identity provider. An attacker who can perform a Man‑in‑the‑Middle on the TLS link between the client and the IDP may substitute a forged discovery document that redirects critical URIs to attacker‑controlled endpoints. The client then encrypts the signed challenge response with the attacker’s key and posts it to an external endpoint, thereby exfiltrating the signed authentication material. This allows the attacker to obtain the client’s authentication credentials and potentially impersonate the client within the ePA infrastructure.

Vulnerable versions are all installations of epa4all-client prior to 1.2.2 distributed by com.oviva.telematik and oviva‑ag. The issue exists in the Java client that implements the ePA 3.0 protocol within the Tele‑matics Infrastruktur. Versions 1.2.2 and later incorporate the necessary signature verification and are not affected.

The CVSS base score of 7.4 indicates a severe impact, but the exploit requires control over TLS traffic to the IdP inside the TI network, which limits the attack surface to entities that already have internal network access. Because the EPSS score is not available and the vulnerability is not in the CISA KEV catalog, the likelihood of widespread exploitation is lower than a typical internet‑exposed flaw. Nonetheless, organizations that use the affected client should treat the flaw as a serious threat and apply the vendor‑issued update promptly. The attack path relies on an active MITM and the redirection of uris via the discovery document, so preventing internal TLS interception and enforcing strict endpoint validation will reduce the exploitation probability.