epa4all-client CVE-2026-44900
HIGHSeverity by source
AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Lifecycle Timeline
3Blast Radius
ecosystem impact- 1 maven packages depend on com.oviva.telematik:epa4all-client (1 direct, 0 indirect)
Ecosystem-wide dependent count for version 1.2.1.
DescriptionGitHub Advisory
Impact
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.
Patches
Patched in #34.
Workarounds
None.
Resources
Credits
Machine Spirits (contact@machinespirits.de)
- Dr. rer. nat. Simon Weber
- Dipl.-Inf. Volker Schönefeld
- Chiara Fliegner
AnalysisAI
ECDSA signature verification bypass in Oviva epa4all-client allows adjacent network attackers to impersonate trusted VAU endpoints without authentication. The SignedPublicKeysTrustValidatorImpl.isTrusted() method discards the boolean return value of Signature.verify() at line 45, accepting any structurally valid signature regardless of cryptographic validity. Vendor-released patch confirmed in version 1.2.1 (PR #34). No public exploit identified at time of analysis, but CVSS 8.1 with adjacent network vector (AV:A) and low complexity (AC:L) indicates straightforward exploitation once attacker is on the same network segment. EPSS data not available.
Technical ContextAI
This vulnerability affects the Virtual Access Use-case (VAU) cryptographic trust validation in epa4all-client, a Java library (maven package com.oviva.telematik:epa4all-client) used in German healthcare telematic infrastructure. The flaw resides in the ECDSA signature verification logic within SignedPublicKeysTrustValidatorImpl. While the code correctly configures the Signature object, initializes it with the public key, and calls verify(), it discards the boolean result. The method performs certificate chain validation, OCSP revocation checks, and signature algorithm setup, then unconditionally returns true regardless of whether the cryptographic signature matches. This is a CWE-295 (Improper Certificate Validation) implementation error where security-critical return values are ignored. The vulnerable code path handles signed public keys used to establish trust with VAU endpoints. The patch in PR #34 corrects line 42 from 'ecdsa.verify(signatureDer);' to 'return ecdsa.verify(signatureDer);' and removes the unconditional 'return true' at line 53, ensuring the actual cryptographic verification result controls trust decisions.
RemediationAI
Upgrade to epa4all-client version 1.2.1 or later, which contains the verified fix from PR #34 (https://github.com/oviva-ag/epa4all-client/pull/34). The patch modifies SignedPublicKeysTrustValidatorImpl to correctly return the boolean result of ecdsa.verify(signatureDer) instead of discarding it. No workarounds exist per vendor advisory - patching is the only remediation. Organizations unable to immediately upgrade should implement network segmentation to restrict adjacent network access to VAU communication channels, though this is a compensating control with limited effectiveness since it merely raises the bar rather than eliminating the vulnerability. Consider monitoring for anomalous VAU endpoint connections or signature validation patterns as a detection layer, but understand this provides visibility only and does not prevent exploitation. Review audit logs for any suspicious VAU trust decisions during the vulnerable period (versions ≤1.2.0).
Same weakness CWE-295 – Improper Certificate Validation
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-g8r3-5hwf-qp96