Filtered by vendor Oviva-ag Subscriptions
Filtered by product Epa4all-client Subscriptions

Search

Switch to Advanced Search (Beta)
Total 4 CVE
CVE Vendors Products Updated CVSS v3.1
CVE-2026-47672 1 Oviva-ag 1 Epa4all-client 2026-05-27 6.5 Medium
epa4all-client is the Java Client for epa4all / ePA 3.0 in the Telematik Infrastruktur. In 1.2.4 and earlier, any network-reachable caller can write arbitrary documents to any patient's electronic health record accessible by the institution's SMC-B card. In a misconfigured deployment (e.g., following the production Docker example in the README), this is exploitable from the local network without credentials.
CVE-2026-45575 2 Com.oviva.telematik, Oviva-ag 2 Epa4all-client, Epa4all-client 2026-05-27 7.4 High
epa4all-client is the Java Client for epa4all / ePA 3.0 in the Telematik Infrastruktur. Prior to 1.2.2, an attacker who can MITM the TLS connection between the client and the IDP (within the TI network) can substitute a forged discovery document. The forged document redirects uri_puk_idp_enc and uri_puk_idp_sig to attacker-controlled URLs. The client then encrypts the SMC-B-signed challenge response to the attacker's encryption key and POSTs it to the attacker's auth endpoint. This captures the signed authentication material. This vulnerability is fixed in 1.2.2.
CVE-2026-45574 2 Com.oviva.telematik, Oviva-ag 2 Epa4all-client, Epa4all-client 2026-05-27 8.1 High
epa4all-client is the Java Client for epa4all / ePA 3.0 in the Telematik Infrastruktur. Prior to 1.2.2, an attacker on the network path between the ePA service and the Konnektor can present any TLS certificate (self-signed, expired, wrong CN) and intercept all SOAP traffic. This includes patient identifiers (KVNR), SMC-B card operations (authentication, signing), document content, and credential exchanges. This vulnerability is fixed in 1.2.2.
CVE-2026-44900 2 Com.oviva.telematik, Oviva-ag 2 Epa4all-client, Epa4all-client 2026-05-27 8.1 High
epa4all-client is the Java Client for epa4all / ePA 3.0 in the Telematik Infrastruktur. Prior to 1.2.1, in SignedPublicKeysTrustValidatorImpl.isTrusted(), the ECDSA signature verification at line 45 discards the boolean return value of Signature.verify(). The method performs certificate chain validation, OCSP check, and signature algorithm setup, but never checks whether the signature actually matches. For any structurally valid signature, it returns true. This vulnerability is fixed in 1.2.1.