Search Results (3015 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-35568 2 Lfprojects, Modelcontextprotocol 2 Mcp Java Sdk, Java-sdk 2026-04-15 5.7 Medium
MCP Java SDK is the official Java SDK for Model Context Protocol servers and clients. Prior to 1.0.0, the java-sdk contains a DNS rebinding vulnerability. This vulnerability allows an attacker to access a locally or network-private java-sdk MCP server via a victims browser that is either local, or network adjacent. This allows an attacker to make any tool call to the server as if they were a locally running MCP connected AI agent. This vulnerability is fixed in 1.0.0.
CVE-2026-5894 4 Apple, Google, Linux and 1 more 4 Macos, Chrome, Linux Kernel and 1 more 2026-04-15 4.3 Medium
Inappropriate implementation in PDF in Google Chrome prior to 147.0.7727.55 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Low)
CVE-2026-3446 1 Python 1 Cpython 2026-04-15 5.3 Medium
When calling base64.b64decode() or related functions the decoding process would stop after encountering the first padded quad regardless of whether there was more information to be processed. This can lead to data being accepted which may be processed differently by other implementations. Use "validate=True" to enable stricter processing of base64 data.
CVE-2026-39395 1 Sigstore 1 Cosign 2026-04-15 4.3 Medium
Cosign provides code signing and transparency for containers and binaries. Prior to 3.0.6 and 2.6.3, cosign verify-blob-attestation may erroneously report a "Verified OK" result for attestations with malformed payloads or mismatched predicate types. For old-format bundles and detached signatures, this was due to a logic flaw in the error handling of the predicate type validation. For new-format bundles, the predicate type validation was bypassed completely. This vulnerability is fixed in 3.0.6 and 2.6.3.
CVE-2026-32614 1 Emmansun 1 Gmsm 2026-04-15 7.5 High
Go ShangMi (Commercial Cryptography) Library (GMSM) is a cryptographic library that covers the Chinese commercial cryptographic public algorithms SM2/SM3/SM4/SM9/ZUC. Prior to 0.41.1, the current SM9 decryption implementation contains an infinity-point ciphertext forgery vulnerability. The root cause is that, during decryption, the elliptic-curve point C1 in the ciphertext is only deserialized and checked to be on the curve, but the implementation does not explicitly reject the point at infinity. In the current implementation, an attacker can construct C1 as the point at infinity, causing the bilinear pairing result to degenerate into the identity element in the GT group. As a result, a critical part of the key derivation input becomes a predictable constant. An attacker who only knows the target user's UID can derive the decryption key material and then forge a ciphertext that passes the integrity check. This vulnerability is fixed in 0.41.1.
CVE-2025-11411 1 Nlnetlabs 1 Unbound 2026-04-15 6.9 Medium
NLnet Labs Unbound up to and including version 1.24.1 is vulnerable to possible domain hijack attacks. Promiscuous NS RRSets that complement positive DNS replies in the authority section can be used to trick resolvers to update their delegation information for the zone. Usually these RRSets are used to update the resolver's knowledge of the zone's name servers. A malicious actor can exploit the possible poisonous effect by injecting NS RRSets (and possibly their respective address records) in a reply. This could be done for example by trying to spoof a packet or fragmentation attacks. Unbound would then proceed to update the NS RRSet data it already has since the new data has enough trust for it, i.e., in-zone data for the delegation point. Unbound 1.24.1 includes a fix that scrubs unsolicited NS RRSets (and their respective address records) from replies mitigating the possible poison effect. Unbound 1.24.2 includes an additional fix that scrubs unsolicited NS RRSets (and their respective address records) from YXDOMAIN and non-referral nodata replies, further mitigating the possible poison effect.
CVE-2025-32060 1 Bosch 1 Infotainment System Ecu 2026-04-15 6.7 Medium
The system suffers from the absence of a kernel module signature verification. If an attacker can execute commands on behalf of root user (due to additional vulnerabilities), then he/she is also able to load custom kernel modules to the kernel space and execute code in the kernel context. Such a flaw can lead to taking control over the entire system. First identified on Nissan Leaf ZE1 manufactured in 2020.
CVE-2025-31335 2026-04-15 4 Medium
The OpenSAML C++ library before 3.3.1 allows forging of signed SAML messages via parameter manipulation (when using SAML bindings that rely on non-XML signatures).
CVE-2025-54419 1 Node-saml 1 Node-saml 2026-04-15 10 Critical
A SAML library not dependent on any frameworks that runs in Node. In version 5.0.1, Node-SAML loads the assertion from the (unsigned) original response document. This is different than the parts that are verified when checking signature. This allows an attacker to modify authentication details within a valid SAML assertion. For example, in one attack it is possible to remove any character from the SAML assertion username. To conduct the attack an attacker would need a validly signed document from the identity provider (IdP). This is fixed in version 5.1.0.
CVE-2025-24903 2026-04-15 8.5 High
libsignal-service-rs is a Rust version of the libsignal-service-java library which implements the core functionality to communicate with Signal servers. Prior to commit 82d70f6720e762898f34ae76b0894b0297d9b2f8, any contact may forge a sync message, impersonating another device of the local user. The origin of sync messages is not checked. Patched libsignal-service can be found after commit 82d70f6720e762898f34ae76b0894b0297d9b2f8. The `Metadata` struct contains an additional `was_encrypted` field, which breaks the API, but should be easily resolvable. No known workarounds are available.
CVE-2025-55278 1 Hcltech 1 Devops Loop 2026-04-15 8.1 High
Improper authentication in the API authentication middleware of HCL DevOps Loop allows authentication tokens to be accepted without proper validation of their expiration and cryptographic signature. As a result, an attacker could potentially use expired or tampered tokens to gain unauthorized access to sensitive resources and perform actions with elevated privileges.
CVE-2025-53548 2026-04-15 7.5 High
Clerk helps developers build user management. Applications that use the verifyWebhook() helper to verify incoming Clerk webhooks are susceptible to accepting improperly signed webhook events. The issue was resolved in @clerk/backend 2.4.0.
CVE-2025-24882 2026-04-15 5.2 Medium
regclient is a Docker and OCI Registry Client in Go. A malicious registry could return a different digest for a pinned manifest without detection. This vulnerability is fixed in 0.7.1.
CVE-2024-8531 1 Schneider-electric 1 Data Center Expert 2026-04-15 7.2 High
CWE-347: Improper Verification of Cryptographic Signature vulnerability exists that could compromise the Data Center Expert software when an upgrade bundle is manipulated to include arbitrary bash scripts that are executed as root.
CVE-2025-12007 1 Supermicro 1 Mbd-x13sem-f 2026-04-15 8.4 High
There is a vulnerability in the Supermicro BMC firmware validation logic at Supermicro MBD-X13SEM-F . An attacker can update the system firmware with a specially crafted image.
CVE-2024-25638 1 Dnsjava 1 Dnsjava 2026-04-15 8.9 High
dnsjava is an implementation of DNS in Java. Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. This vulnerability is fixed in 3.6.0.
CVE-2024-25584 2026-04-15 5.3 Medium
Dovecot accepts dot LF DOT LF symbol as end of DATA command. RFC requires that it should always be CR LF DOT CR LF. This causes Dovecot to convert single mail with LF DOT LF in middle, into two emails when relaying to SMTP. Dovecot will split mail with LF DOT LF into two mails. Upgrade to latest released version. No publicly available exploits are known.
CVE-2022-33861 1 Eaton 1 Intelligent Power Protector 2026-04-15 5.1 Medium
IPP software versions prior to v1.71 do not sufficiently verify the authenticity of data, in a way that causes it to accept invalid data.
CVE-2025-68113 1 Altcha 1 Altcha 2026-04-15 6.5 Medium
ALTCHA is privacy-first software for captcha and bot protection. A cryptographic semantic binding flaw in ALTCHA libraries allows challenge payload splicing, which may enable replay attacks. The HMAC signature does not unambiguously bind challenge parameters to the nonce, allowing an attacker to reinterpret a valid proof-of-work submission with a modified expiration value. This may allow previously solved challenges to be reused beyond their intended lifetime, depending on server-side replay handling and deployment assumptions. The vulnerability primarily impacts abuse-prevention mechanisms such as rate limiting and bot mitigation. It does not directly affect data confidentiality or integrity. This issue has been addressed by enforcing explicit semantic separation between challenge parameters and the nonce during HMAC computation. Users are advised to upgrade to patched versions, which include version 1.0.0 of the altcha Golang package, version 1.0.0 of the altcha Rubygem, version 1.0.0 of the altcha pip package, version 1.0.0 of the altcha Erlang package, version 1.4.1 of the altcha-lib npm package, version 1.3.1 of the altcha-org/altcha Composer package, and version 1.3.0 of the org.altcha:altcha Maven package. As a mitigation, implementations may append a delimiter to the end of the `salt` value prior to HMAC computation (for example, `<salt>?expires=<time>&`). This prevents ambiguity between parameters and the nonce and is backward-compatible with existing implementations, as the delimiter is treated as a standard URL parameter separator.
CVE-2025-25188 2026-04-15 N/A
Hickory DNS is a Rust based DNS client, server, and resolver. A vulnerability present starting in version 0.8.0 and prior to versions 0.24.3 and 0.25.0-alpha.5 impacts Hickory DNS users relying on DNSSEC verification in the client library, stub resolver, or recursive resolver. The DNSSEC validation routines treat entire RRsets of DNSKEY records as trusted once they have established trust in only one of the DNSKEYs. As a result, if a zone includes a DNSKEY with a public key that matches a configured trust anchor, all keys in that zone will be trusted to authenticate other records in the zone. There is a second variant of this vulnerability involving DS records, where an authenticated DS record covering one DNSKEY leads to trust in signatures made by an unrelated DNSKEY in the same zone. Versions 0.24.3 and 0.25.0-alpha.5 fix the issue.