Export limit exceeded: 416298 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 416298 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 416298 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (3122 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-32977 | 1 Quest | 1 Kace Systems Management Appliance | 2026-04-15 | 9.6 Critical |
| Quest KACE Systems Management Appliance (SMA) 13.0.x before 13.0.385, 13.1.x before 13.1.81, 13.2.x before 13.2.183, 14.0.x before 14.0.341 (Patch 5), and 14.1.x before 14.1.101 (Patch 4) allows unauthenticated users to upload backup files to the system. While signature validation is implemented, weaknesses in the validation process can be exploited to upload malicious backup content that could compromise system integrity. | ||||
| CVE-2025-40776 | 1 Isc | 1 Bind | 2026-04-15 | 8.6 High |
| A `named` caching resolver that is configured to send ECS (EDNS Client Subnet) options may be vulnerable to a cache-poisoning attack. This issue affects BIND 9 versions 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.37-S1, and 9.20.9-S1 through 9.20.10-S1. | ||||
| CVE-2025-40758 | 1 Mendix | 2 Mendix, Saml | 2026-04-15 | 8.7 High |
| A vulnerability has been identified in Mendix SAML (Mendix 10.12 compatible) (All versions < V4.0.3), Mendix SAML (Mendix 10.21 compatible) (All versions < V4.1.2), Mendix SAML (Mendix 9.24 compatible) (All versions < V3.6.21). Affected versions of the module insufficiently enforce signature validation and binding checks. This could allow unauthenticated remote attackers to hijack an account in specific SSO configurations. | ||||
| CVE-2025-40778 | 1 Isc | 1 Bind 9 | 2026-04-15 | 8.6 High |
| Under certain circumstances, BIND is too lenient when accepting records from answers, allowing an attacker to inject forged data into the cache. This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, 9.21.0 through 9.21.12, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.39-S1, and 9.20.9-S1 through 9.20.13-S1. | ||||
| CVE-2025-40780 | 1 Isc | 1 Bind 9 | 2026-04-15 | 8.6 High |
| In specific circumstances, due to a weakness in the Pseudo Random Number Generator (PRNG) that is used, it is possible for an attacker to predict the source port and query ID that BIND will use. This issue affects BIND 9 versions 9.16.0 through 9.16.50, 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, 9.21.0 through 9.21.12, 9.16.8-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.39-S1, and 9.20.9-S1 through 9.20.13-S1. | ||||
| CVE-2025-40918 | 2026-04-15 | 6.5 Medium | ||
| Authen::SASL::Perl::DIGEST_MD5 versions 2.04 through 2.1800 for Perl generates the cnonce insecurely. The cnonce (client nonce) is generated from an MD5 hash of the PID, the epoch time and the built-in rand function. The PID will come from a small set of numbers, and the epoch time may be guessed, if it is not leaked from the HTTP Date header. The built-in rand function is unsuitable for cryptographic usage. According to RFC 2831, The cnonce-value is an opaque quoted string value provided by the client and used by both client and server to avoid chosen plaintext attacks, and to provide mutual authentication. The security of the implementation depends on a good choice. It is RECOMMENDED that it contain at least 64 bits of entropy. | ||||
| CVE-2025-40919 | 2026-04-15 | 6.5 Medium | ||
| Authen::DigestMD5 versions 0.01 through 0.02 for Perl generate the cnonce insecurely. The cnonce (client nonce) is generated from an MD5 hash of the PID, the epoch time and the built-in rand function. The PID will come from a small set of numbers, and the epoch time may be guessed, if it is not leaked from the HTTP Date header. The built-in rand function is unsuitable for cryptographic usage. According to RFC 2831, "The cnonce-value is an opaque quoted string value provided by the client and used by both client and server to avoid chosen plaintext attacks, and to provide mutual authentication. The security of the implementation depends on a good choice. It is RECOMMENDED that it contain at least 64 bits of entropy." | ||||
| CVE-2025-40920 | 1 Perl | 1 Catalyst Authentication Credential Http | 2026-04-15 | 8.6 High |
| Catalyst::Authentication::Credential::HTTP versions 1.018 and earlier for Perl generate nonces using the Perl Data::UUID library. * Data::UUID does not use a strong cryptographic source for generating UUIDs. * Data::UUID returns v3 UUIDs, which are generated from known information and are unsuitable for security, as per RFC 9562. * The nonces should be generated from a strong cryptographic source, as per RFC 7616. | ||||
| CVE-2025-40923 | 2026-04-15 | 7.3 High | ||
| Plack-Middleware-Session before version 0.35 for Perl generates session ids insecurely. The default session id generator returns a SHA-1 hash seeded with the built-in rand function, the epoch time, and the PID. The PID will come from a small set of numbers, and the epoch time may be guessed, if it is not leaked from the HTTP Date header. The built-in rand function is unsuitable for cryptographic usage. Predicable session ids could allow an attacker to gain access to systems. | ||||
| CVE-2025-40924 | 2026-04-15 | 6.5 Medium | ||
| Catalyst::Plugin::Session before version 0.44 for Perl generates session ids insecurely. The session id is generated from a (usually SHA-1) hash of a simple counter, the epoch time, the built-in rand function, the PID and the current Catalyst context. This information is of low entropy. The PID will come from a small set of numbers, and the epoch time may be guessed, if it is not leaked from the HTTP Date header. The built-in rand function is unsuitable for cryptographic usage. Predicable session ids could allow an attacker to gain access to systems. | ||||
| CVE-2025-40925 | 1 Starch | 1 Starch | 2026-04-15 | 9.1 Critical |
| Starch versions 0.14 and earlier generate session ids insecurely. The default session id generator returns a SHA-1 hash seeded with a counter, the epoch time, the built-in rand function, the PID, and internal Perl reference addresses. The PID will come from a small set of numbers, and the epoch time may be guessed, if it is not leaked from the HTTP Date header. The built-in rand function is unsuitable for cryptographic usage. Predicable session ids could allow an attacker to gain access to systems. | ||||
| CVE-2025-40933 | 2026-04-15 | 7.5 High | ||
| Apache::AuthAny::Cookie v0.201 or earlier for Perl generates session ids insecurely. Session ids are generated using an MD5 hash of the epoch time and a call to the built-in rand function. The epoch time may be guessed, if it is not leaked from the HTTP Date header. The built-in rand function is unsuitable for cryptographic usage. Predicable session ids could allow an attacker to gain access to systems. | ||||
| CVE-2025-4371 | 2026-04-15 | 6.8 Medium | ||
| A potential vulnerability was reported in the Lenovo 510 FHD and Performance FHD web cameras that could allow an attacker with physical access to write arbitrary firmware updates to the device over a USB connection. | ||||
| CVE-2025-47909 | 2026-04-15 | 7.3 High | ||
| Hosts listed in TrustedOrigins implicitly allow requests from the corresponding HTTP origins, allowing network MitMs to perform CSRF attacks. After the CVE-2025-24358 fix, a network attacker that places a form at http://example.com can't get it to submit to https://example.com because the Origin header is checked with sameOrigin against a synthetic URL. However, if a host is added to TrustedOrigins, both its HTTP and HTTPS origins will be allowed, because the schema of the synthetic URL is ignored and only the host is checked. For example, if an application is hosted on https://example.com and adds example.net to TrustedOrigins, a network attacker can serve a form at http://example.net to perform the attack. Applications should migrate to net/http.CrossOriginProtection, introduced in Go 1.25. If that is not an option, a backport is available as a module at filippo.io/csrf, and a drop-in replacement for the github.com/gorilla/csrf API is available at filippo.io/csrf/gorilla. | ||||
| CVE-2025-47934 | 1 Openpgpjs | 1 Openpgpjs | 2026-04-15 | N/A |
| OpenPGP.js is a JavaScript implementation of the OpenPGP protocol. Startinf in version 5.0.1 and prior to versions 5.11.3 and 6.1.1, a maliciously modified message can be passed to either `openpgp.verify` or `openpgp.decrypt`, causing these functions to return a valid signature verification result while returning data that was not actually signed. This flaw allows signature verifications of inline (non-detached) signed messages (using `openpgp.verify`) and signed-and-encrypted messages (using `openpgp.decrypt` with `verificationKeys`) to be spoofed, since both functions return extracted data that may not match the data that was originally signed. Detached signature verifications are not affected, as no signed data is returned in that case. In order to spoof a message, the attacker needs a single valid message signature (inline or detached) as well as the plaintext data that was legitimately signed, and can then construct an inline-signed message or signed-and-encrypted message with any data of the attacker's choice, which will appear as legitimately signed by affected versions of OpenPGP.js. In other words, any inline-signed message can be modified to return any other data (while still indicating that the signature was valid), and the same is true for signed+encrypted messages if the attacker can obtain a valid signature and encrypt a new message (of the attacker's choice) together with that signature. The issue has been patched in versions 5.11.3 and 6.1.1. Some workarounds are available. When verifying inline-signed messages, extract the message and signature(s) from the message returned by `openpgp.readMessage`, and verify the(/each) signature as a detached signature by passing the signature and a new message containing only the data (created using `openpgp.createMessage`) to `openpgp.verify`. When decrypting and verifying signed+encrypted messages, decrypt and verify the message in two steps, by first calling `openpgp.decrypt` without `verificationKeys`, and then passing the returned signature(s) and a new message containing the decrypted data (created using `openpgp.createMessage`) to `openpgp.verify`. | ||||
| CVE-2025-54369 | 1 Node-saml | 1 Node-saml | 2026-04-15 | N/A |
| Node-SAML is a SAML library not dependent on any frameworks that runs in Node. In versions 5.0.1 and below, 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. This issue is fixed in version 5.1.0. | ||||
| 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-54549 | 1 Arista | 1 Danz Monitoring Fabric | 2026-04-15 | 5.9 Medium |
| Cryptographic validation of upgrade images could be circumventing by dropping a specifically crafted file into the upgrade ISO | ||||
| CVE-2025-29775 | 1 Redhat | 1 Rhdh | 2026-04-15 | 9.1 Critical |
| xml-crypto is an XML digital signature and encryption library for Node.js. An attacker may be able to exploit a vulnerability in versions prior to 6.0.1, 3.2.1, and 2.1.6 to bypass authentication or authorization mechanisms in systems that rely on xml-crypto for verifying signed XML documents. The vulnerability allows an attacker to modify a valid signed XML message in a way that still passes signature verification checks. For example, it could be used to alter critical identity or access control attributes, enabling an attacker to escalate privileges or impersonate another user. Users of versions 6.0.0 and prior should upgrade to version 6.0.1 to receive a fix. Those who are still using v2.x or v3.x should upgrade to patched versions 2.1.6 or 3.2.1, respectively. | ||||
| CVE-2018-25099 | 1 Dcit | 1 Perl-cryptx | 2026-04-15 | 9.8 Critical |
| In the CryptX module before 0.062 for Perl, gcm_decrypt_verify() and chacha20poly1305_decrypt_verify() do not verify the tag. | ||||