CVE WatchJul 25, 2026

CVE-2026-48021

In epa4all, prior to version 2026-05-20, an attacker who can intercept the TLS connection between epa4all and the ePA backend can complete t

CVSS

9.1

Critical

EPSS

—

KEV

—

Exploit Today

0-100

Published: Jul 24, 2026 · Last modified: Jul 25, 2026 · CWE-295 · CWE-347

EPSS · 30d

Not enough EPSS history yet.

Technical description

In epa4all, prior to version 2026-05-20, an attacker who can intercept the TLS connection between epa4all and the ePA backend can complete the VAU handshake with attacker-controlled keys and obtain the session encryption keys. All inner HTTP traffic (patient consent decisions, medication data, document operations, authorization tokens, and entitlement queries) becomes readable and modifiable. The attacker can also inject arbitrary requests through the hijacked channel. This issue has been patched in version 2026-05-20.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-543428.1 HIG

—

——0In epa4all, prior to version 2026-05-20, an attacker on the network path between epa4all and any backend (ePA Aktensystem, Konnektor, IDP, TSS) can present a self-signed TLS certificate and intercept the connection. For non-VAU connections (Konnektor, IDP), this allows direct read and modification of the inner traffic, including smartcard operations and OIDC authentication exchanges. For the ePA backend, the disabled TLS verification is the transport-level enabler for the VAU MITM described in GHSA-vvh7-x6c7-46gh. This issue has been patched in version 2026-05-20.19h CVE-2026-526887.5 HIG

2.7%

——1RRSIGs with too few labels can lead to bypass of DNSSEC wildcard validation2d CVE-2026-526863.7 LOW

1.7%

——1The issue is a DNSSEC validation bypass where wildcard expansion proofs (NSEC/NSEC3 records) are accepted without signature validation when the wildcard answer is a CNAME or DNAME record.2d CVE-2026-13089—

5.4%

——2OIDC::Lite versions through 0.12.1 for Perl allow ID Token signature verification bypass via a token-controlled algorithm allowlist in verify. When the caller does not pin an algorithm, OIDC::Lite::Model::IDToken::verify sets $self->alg($self->header->{alg}) from the token's own header and then calls decode_jwt(token, key, 1, [$self->alg]), handing JSON::WebToken an accepted-algorithm allowlist taken from the untrusted token. A token with alg=none yields ['none'], so decode_jwt returns the claims with no signature check, and a token with alg=HS256 is verified with the RP's RSA public key as the HMAC secret (RS to HS confusion). The ID Token is the OpenID Connect authentication assertion delivered to the Relying Party. Any caller that verifies an ID Token through the unpinned load(token)->verify path, or load(token, key) with only the key pinned, accepts a forged token carrying attacker-chosen claims such as sub and is authenticated as any user. Passing an explicit algorithm so $self->alg is already set bypasses the header-derived allowlist and is not affected. Note that the latest version uploaded to CPAN is 0.10. Later versions are available in the git repository.2d CVE-2026-107236.8 MED

18.3%

——5BIND may accept incorrect child-zone NSEC3 records as valid, which could allow an attacker to forge authenticated NXDOMAIN responses. This issue affects BIND 9 versions 9.18.0 through 9.18.50, 9.20.0 through 9.20.24, 9.21.0 through 9.21.23, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.24-S1.3d CVE-2026-568207.4 HIG

8.2%

——2Netty is a network application framework for development of protocol servers and clients. In versions 4.2.0.Final through 4.2.15.Final and prior to 4.1.135.Final, `OcspClient` does not validate that the `CertificateID` in an OCSP response matches the requested `CertificateID`, which can lead to replay attack. `OcspClient.validateResponse` accepts a legitimately signed `GOOD` status response for an unrelated certificate issued by the same CA, allowing bypass of revocation checks for another certificate. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.17h