CVE-2026-44900 Overview
CVE-2026-44900 is a certificate validation flaw [CWE-295] in the epa4all-client Java library, which serves as the client for epa4all / ePA 3.0 in the German Telematik Infrastruktur. Versions prior to 1.2.1 contain a broken Elliptic Curve Digital Signature Algorithm (ECDSA) verification routine in SignedPublicKeysTrustValidatorImpl.isTrusted(). The implementation calls Signature.verify() but discards the boolean return value, causing the method to accept any structurally valid signature as trusted. Attackers on an adjacent network can forge signed public keys and bypass trust validation against the electronic patient record infrastructure.
Critical Impact
Any structurally valid ECDSA signature is accepted as trusted, enabling impersonation and tampering with signed public keys in ePA 3.0 client communications.
Affected Products
- epa4all-client Java client library versions prior to 1.2.1
- Applications integrating epa4all / ePA 3.0 trust validation via Oviva AG's client
- Telematik Infrastruktur consumers relying on SignedPublicKeysTrustValidatorImpl
Discovery Timeline
- 2026-05-26 - CVE-2026-44900 published to NVD
- 2026-05-27 - Last updated in NVD database
Technical Details for CVE-2026-44900
Vulnerability Analysis
The flaw resides in SignedPublicKeysTrustValidatorImpl.isTrusted(), the method responsible for confirming whether a signed public key originates from a trusted authority. The implementation performs several supporting checks: certificate chain validation, Online Certificate Status Protocol (OCSP) revocation lookup, and signature algorithm initialization. At line 45, the routine invokes Signature.verify() but ignores the returned boolean. Because Java's Signature.verify() does not throw on cryptographic mismatch and instead returns false, dropping the result short-circuits the cryptographic decision. The method then returns true for any input that survives the surrounding structural checks.
The consequence is a complete loss of integrity guarantees on signed public keys consumed by the client. An attacker positioned on an adjacent network can present a forged signature paired with a structurally valid certificate chain and have it accepted as authentic.
Root Cause
The root cause is improper certificate validation [CWE-295] caused by discarding the cryptographic verification result. The code treats Signature.verify() as a side-effecting call rather than a predicate, removing the only check that binds the signature to the signed data.
Attack Vector
Exploitation requires adjacent network access to inject or modify messages exchanged between the client and ePA 3.0 endpoints. No authentication or user interaction is required. An attacker substitutes a forged signed public key payload; the client accepts it, enabling key substitution that can lead to interception or manipulation of subsequent encrypted exchanges. Technical details are available in the GitHub Security Advisory GHSA-g8r3-5hwf-qp96 and the remediation pull request.
Detection Methods for CVE-2026-44900
Indicators of Compromise
- Unexpected signed public key payloads accepted by clients running epa4all-client versions earlier than 1.2.1.
- Anomalous ePA 3.0 session establishment from hosts on the local or adjacent network segment.
- Application logs showing successful isTrusted() outcomes for payloads whose signing certificates differ from previously observed trust anchors.
Detection Strategies
- Inventory Java dependencies and flag any artifact matching epa4all-client below version 1.2.1 using software composition analysis tooling.
- Inspect runtime behavior of SignedPublicKeysTrustValidatorImpl and alert when verification completes without a corresponding cryptographic match log entry.
- Correlate ePA 3.0 client traffic with expected signer certificate fingerprints and raise alerts on deviations.
Monitoring Recommendations
- Capture and retain TLS and application-layer metadata for ePA 3.0 sessions for retrospective analysis.
- Monitor adjacent network segments hosting epa4all clients for ARP, DHCP, or routing anomalies indicative of man-in-the-middle positioning.
- Track dependency updates in CI pipelines to confirm rollout of epa4all-client 1.2.1 across all consuming services.
How to Mitigate CVE-2026-44900
Immediate Actions Required
- Upgrade epa4all-client to version 1.2.1 or later in all build manifests and redeploy affected services.
- Audit code paths that depend on SignedPublicKeysTrustValidatorImpl.isTrusted() to confirm no local forks reintroduce the discarded return value.
- Rotate any keys whose trust decisions were made by vulnerable client versions in untrusted network environments.
Patch Information
The maintainers fixed the issue in epa4all-client 1.2.1 by capturing the boolean returned from Signature.verify() and failing trust evaluation when the signature does not match. Review the corrective change in GitHub Pull Request #34.
Workarounds
- Restrict epa4all client deployments to network segments where adjacent attacker positioning is infeasible until patching completes.
- Enforce mutual TLS and strict certificate pinning at the transport layer to reduce reliance on the broken application-layer signature check.
- Disable or sandbox features that depend on signed public key trust evaluation until version 1.2.1 is deployed.
# Maven dependency update to the fixed version
mvn versions:use-dep-version -Dincludes=com.oviva.epa:epa4all-client -DdepVersion=1.2.1 -DforceVersion=true
# Gradle equivalent (build.gradle)
# implementation 'com.oviva.epa:epa4all-client:1.2.1'
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
