CVE-2026-34155
RAUC controls the update process on embedded Linux systems. Prior to version 1.15.2, RAUC bundles using the 'plain' format exceeding a paylo
CVSS
5.3
Medio
EPSS
0.1%
p4
KEV
—
Exploit Today
1
0-100
Publicado: 31 mar 2026 · Última mod.: 24 jul 2026 · CWE-196 · CWE-347
0.1%EPSS · 30 días0.1%
2026-06-302026-07-26
RAUC controls the update process on embedded Linux systems. Prior to version 1.15.2, RAUC bundles using the 'plain' format exceeding a payload size of 2 GiB cause an integer overflow which results in a signature which covers only the first few bytes of the payload. Given such a bundle with a legitimate signature, an attacker can modify the part of the payload which is not covered by the signature. This issue has been patched in version 1.15.2.
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-148377.8 ALT—
——0Multiple Lenze products are affected by an improper signature verification vulnerability in the SSH enablement mechanism. A low-privileged local attacker can bypass verification of the SSH enable file signature and enable SSH access on the device. Successful exploitation may result in unauthorized administrative access and complete system compromise.3hCVE-2026-480219.1 CRÍ2.5%
——1In 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.3dCVE-2026-526863.7 BAJ1.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.4dCVE-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.4dCVE-2026-107236.8 MED18.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.5dCVE-2026-646238.6 ALT10.0%
——3Network-AI before 5.13.4 contains an improper cryptographic signature verification vulnerability in APSAdapter where the default local verifier accepts any non-empty string as valid. Unauthenticated attackers can submit forged APS delegation payloads with arbitrary scopes to bypass signature verification and obtain signed permission-grant tokens for sensitive resources including SHELL_EXEC.4d