CVE Watch19 ago 2026

CVE-2026-58085

After dispatching a decrypt operation to OCF and receiving the result, the wg(4) driver failed to check whether the MAC verification step su

CVSS

—

Sin CVSS

EPSS

0.2%

KEV

—

Exploit Today

0-100

Publicado: 19 ago 2026 · Última mod.: 19 ago 2026 · CWE-347

EPSS · 30d

Sin historial EPSS suficiente todavía.

Descripción técnica

After dispatching a decrypt operation to OCF and receiving the result, the wg(4) driver failed to check whether the MAC verification step succeeded. The driver thus silently accepted packets with an invalid Poly1305 authentication tag. A remote attacker who can send UDP packets to a WireGuard endpoint, and who can guess the bounds of the receiver's replay window, can inject forged or modified transport data packets into the tunnel. A remote attacker who can intercept WireGuard packets bound for a FreeBSD host can modify the ciphertext and authenticated data without detection by the receiver.

Referencias oficiales

security.freebsd.orghttps://security.freebsd.org/advisories/FreeBSD-SA-26:52.if_wg.asc

CVEs relacionados

CVECVSSEPSSKEVRExplotTítuloVis.

CVE-2026-762347.5 ALT

—

——0libcrux-ecdh and libcrux-ed25519 before 0.0.6, and libcrux-psq before 0.0.7, contain cryptographic implementation bugs. libcrux-ecdh did not properly check length and clamping during X25519 secret validation (and had a broken clamping check for imported X25519 secret keys); libcrux-ed25519 performed a duplicated clamping step during key generation; and libcrux-psq panicked instead of propagating an AEADError. These were fixed in the respective patched releases.1d CVE-2026-72889—

1.5%

——0Net::OAuth versions before 0.33 for Perl allow the sender to choose the signature algorithm in verify. verify resolves the signature method class from the signature_method parameter of the incoming message. signature_method is required on every request, so the algorithm used to check a signature is chosen by whoever sent it, and nothing lets the verifying party pin the method instead. When a message names HMAC-SHA1 or HMAC-SHA256, the key is derived from consumer_secret and token_secret rather than from the key the provider deployed. A provider deployed on RSA-SHA1 holds only the consumer public key, and RFC 5849 does not use consumer_secret for that method, so the required parameter is filled with a placeholder. A client that names HMAC-SHA1 instead has its signature checked against that placeholder, so a guessable one is enough to forge requests for any consumer key and token.19h CVE-2026-551654.8 MED

2.7%

——1Lemur manages TLS certificate creation. Prior to 1.9.2, the JWT verifier in lemur/auth/service.py:130-137 used fetch_token_header to read header_data["alg"] from an unverified token and passed that attacker-controlled value to decode_with_multiple_secrets. PyJWT 2.x rejects alg=none with the configured key, so the flaw is a defense-in-depth gap rather than a direct authentication bypass in the shipped configuration. The unpinned algorithm can become exploitable after an asymmetric-signing migration through algorithm confusion, and it weakens algorithm-based anomaly detection because the token chooses the recorded value. A separate disclosure of LEMUR_TOKEN_SECRET would also permit forged HS256 tokens, although that disclosure is an independent prerequisite. The fix introduces the server-controlled LEMUR_TOKEN_ALGORITHMS allowlist and defaults it to HS256. This issue is fixed in version 1.9.2.2d CVE-2025-92108.1 ALT

5.2%

——2Missing signature validation in JSON Web Tokens in Otalio Ship Property Management System versions before 2.22.0 allows authenticated attackers to escalate privileges via tampering with JWTs2d CVE-2026-749019.8 CRÍ

15.4%

——5openssl_encrypt versions before 1.4.0 contain an authentication bypass vulnerability in pqc.py where AES-GCM decryption failures trigger fallback to unauthenticated AES-CTR mode. Attackers can modify ciphertext in transit to bypass integrity verification and perform bit-flipping attacks without detection.3d CVE-2026-748769.8 CRÍ

10.4%

——3openssl_encrypt versions before 1.4.0 contain a vulnerability in PublicKeyBundle.from_dict() that creates key bundles from untrusted data without verifying signatures. Attackers can call from_dict() followed by to_identity() without signature verification to encrypt data using attacker-controlled public keys, leaking secrets.3d