| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| 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. |
| 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. |
| 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." |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| SEL-5037 Grid Configurator contains an overly permissive Cross Origin Resource Sharing (CORS) configuration for a data gateway service in the application. This gateway service includes an API which is not properly configured to reject requests from unexpected sources. |
| 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. |
| 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`. |
| 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. |
| 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. |
| Cryptographic validation of upgrade images could be circumventing by dropping a specifically crafted file into the upgrade ISO |
| 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. |
| Matrix JavaScript SDK is a Matrix Client-Server SDK for JavaScript and TypeScript. matrix-js-sdk before 38.2.0 has insufficient validation of room predecessor links in MatrixClient::getJoinedRooms, allowing a remote attacker to attempt to replace a tombstoned room with an unrelated attacker-supplied room. The issue has been patched and users should upgrade to 38.2.0. A workaround is to avoid using MatrixClient::getJoinedRooms in favor of getRooms() and filtering upgraded rooms separately. |
| SillyTavern is a locally installed user interface that allows users to interact with text generation large language models, image generation engines, and text-to-speech voice models. In versions prior to 1.13.4, the web user interface for SillyTavern is susceptible to DNS rebinding, allowing attackers to perform actions like install malicious extensions, read chats, inject arbitrary HTML for phishing attacks, etc. The vulnerability has been patched in the version 1.13.4 by introducing a server configuration setting that enables a validation of host names in inbound HTTP requests according to the provided list of allowed hosts: `hostWhitelist.enabled` in config.yaml file or `SILLYTAVERN_HOSTWHITELIST_ENABLED` environment variable. While the setting is disabled by default to honor a wide variety of existing user configurations and maintain backwards compatibility, existing and new users are encouraged to review their server configurations and apply necessary changes to their setup, especially if hosting over the local network while not using SSL. |
| 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. |
