| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The Fedora Secure Boot CA certificate shipped with shim in Fedora was expired which could lead to old or invalid signed boot components being loaded. |
| A vulnerability has been identified in RUGGEDCOM i800 (All versions), RUGGEDCOM i801 (All versions), RUGGEDCOM i802 (All versions), RUGGEDCOM i803 (All versions), RUGGEDCOM M2100 (All versions), RUGGEDCOM M2200 (All versions), RUGGEDCOM M969 (All versions), RUGGEDCOM RMC30 (All versions), RUGGEDCOM RMC8388 V4.X (All versions), RUGGEDCOM RMC8388 V5.X (All versions < V5.10.0), RUGGEDCOM RP110 (All versions), RUGGEDCOM RS1600 (All versions), RUGGEDCOM RS1600F (All versions), RUGGEDCOM RS1600T (All versions), RUGGEDCOM RS400 (All versions), RUGGEDCOM RS401 (All versions), RUGGEDCOM RS416 (All versions), RUGGEDCOM RS416P (All versions), RUGGEDCOM RS416Pv2 V4.X (All versions), RUGGEDCOM RS416Pv2 V5.X (All versions < V5.10.0), RUGGEDCOM RS416v2 V4.X (All versions), RUGGEDCOM RS416v2 V5.X (All versions < V5.10.0), RUGGEDCOM RS8000 (All versions), RUGGEDCOM RS8000A (All versions), RUGGEDCOM RS8000H (All versions), RUGGEDCOM RS8000T (All versions), RUGGEDCOM RS900 (All versions), RUGGEDCOM RS900 (32M) V4.X (All versions), RUGGEDCOM RS900 (32M) V5.X (All versions < V5.10.0), RUGGEDCOM RS900G (All versions), RUGGEDCOM RS900G (32M) V4.X (All versions), RUGGEDCOM RS900G (32M) V5.X (All versions < V5.10.0), RUGGEDCOM RS900GP (All versions), RUGGEDCOM RS900L (All versions), RUGGEDCOM RS900M-GETS-C01 (All versions), RUGGEDCOM RS900M-GETS-XX (All versions), RUGGEDCOM RS900M-STND-C01 (All versions), RUGGEDCOM RS900M-STND-XX (All versions), RUGGEDCOM RS900W (All versions), RUGGEDCOM RS910 (All versions), RUGGEDCOM RS910L (All versions), RUGGEDCOM RS910W (All versions), RUGGEDCOM RS920L (All versions), RUGGEDCOM RS920W (All versions), RUGGEDCOM RS930L (All versions), RUGGEDCOM RS930W (All versions), RUGGEDCOM RS940G (All versions), RUGGEDCOM RS969 (All versions), RUGGEDCOM RSG2100 (All versions), RUGGEDCOM RSG2100 (32M) V4.X (All versions), RUGGEDCOM RSG2100 (32M) V5.X (All versions < V5.10.0), RUGGEDCOM RSG2100P (All versions), RUGGEDCOM RSG2100P (32M) V4.X (All versions), RUGGEDCOM RSG2100P (32M) V5.X (All versions < V5.10.0), RUGGEDCOM RSG2200 (All versions), RUGGEDCOM RSG2288 V4.X (All versions), RUGGEDCOM RSG2288 V5.X (All versions < V5.10.0), RUGGEDCOM RSG2300 V4.X (All versions), RUGGEDCOM RSG2300 V5.X (All versions < V5.10.0), RUGGEDCOM RSG2300P V4.X (All versions), RUGGEDCOM RSG2300P V5.X (All versions < V5.10.0), RUGGEDCOM RSG2488 V4.X (All versions), RUGGEDCOM RSG2488 V5.X (All versions < V5.10.0), RUGGEDCOM RSG907R (All versions < V5.10.0), RUGGEDCOM RSG908C (All versions < V5.10.0), RUGGEDCOM RSG909R (All versions < V5.10.0), RUGGEDCOM RSG910C (All versions < V5.10.0), RUGGEDCOM RSG920P V4.X (All versions), RUGGEDCOM RSG920P V5.X (All versions < V5.10.0), RUGGEDCOM RSL910 (All versions < V5.10.0), RUGGEDCOM RST2228 (All versions < V5.10.0), RUGGEDCOM RST2228P (All versions < V5.10.0), RUGGEDCOM RST916C (All versions < V5.10.0), RUGGEDCOM RST916P (All versions < V5.10.0). The affected devices support the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 cipher suite, which uses CBC (Cipher Block Chaining) mode that is known to be vulnerable to timing attacks. This could allow an attacker to compromise the integrity and confidentiality of encrypted communications. |
| The Copypress Rest API plugin for WordPress is vulnerable to Remote Code Execution via copyreap_handle_image() Function in versions 1.1 to 1.2. The plugin falls back to a hard-coded JWT signing key when no secret is defined and does not restrict which file types can be fetched and saved as attachments. As a result, unauthenticated attackers can forge a valid token to gain elevated privileges and upload an arbitrary file (e.g. a PHP script) through the image handler, leading to remote code execution. |
| The device uses a weak hashing alghorithm to create the password hash. Hence, a matching password can be easily calculated by an attacker. This impacts the security and the integrity of the device. |
| VyOS 1.3 through 1.5 (fixed in 1.4.2) or any Debian-based system using dropbear in combination with live-build has the same Dropbear private host keys across different installations. Thus, an attacker can conduct active man-in-the-middle attacks against SSH connections if Dropbear is enabled as the SSH daemon. I n VyOS, this is not the default configuration for the system SSH daemon, but is for the console service. To mitigate this, one can run "rm -f /etc/dropbear/*key*" and/or "rm -f /etc/dropbear-initramfs/*key*" and then dropbearkey -t rsa -s 4096 -f /etc/dropbear_rsa_host_key and reload the service or reboot the system before using Dropbear as the SSH daemon (this clears out all keys mistakenly built into the release image) or update to the latest version of VyOS 1.4 or 1.5. Note that this vulnerability is not unique to VyOS and may appear in any Debian-based Linux distribution that uses Dropbear in combination with live-build, which has a safeguard against this behavior in OpenSSH but no equivalent one for Dropbear. |
| sigstore-python is a Python tool for generating and verifying Sigstore signatures. Versions of sigstore-python newer than 2.0.0 but prior to 3.6.0 perform insufficient validation of the "integration time" present in "v2" and "v3" bundles during the verification flow: the "integration time" is verified *if* a source of signed time (such as an inclusion promise) is present, but is otherwise trusted if no source of signed time is present. This does not affect "v1" bundles, as the "v1" bundle format always requires an inclusion promise.
Sigstore uses signed time to support verification of signatures made against short-lived signing keys. The impact and severity of this weakness is *low*, as Sigstore contains multiple other enforcing components that prevent an attacker who modifies the integration timestamp within a bundle from impersonating a valid signature. In particular, an attacker who modifies the integration timestamp can induce a Denial of Service, but in no different manner than already possible with bundle access (e.g. modifying the signature itself such that it fails to verify). Separately, an attacker could upload a *new* entry to the transparency service, and substitute their new entry's time. However, this would still be rejected at validation time, as the new entry's (valid) signed time would be outside the validity window of the original signing certificate and would nonetheless render the attacker auditable. |
| A vulnerability has been found in running-elephant Datart up to 1.0.0-rc3. Affected by this issue is the function getTokensecret of the file datart/security/src/main/java/datart/security/util/AESUtil.java of the component API. The manipulation leads to use of hard-coded cryptographic key
. The attack is possible to be carried out remotely. The attack is considered to have high complexity. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. |
| A vulnerability has been identified in RUGGEDCOM i800 (All versions), RUGGEDCOM i801 (All versions), RUGGEDCOM i802 (All versions), RUGGEDCOM i803 (All versions), RUGGEDCOM M2100 (All versions), RUGGEDCOM M2200 (All versions), RUGGEDCOM M969 (All versions), RUGGEDCOM RMC30 (All versions), RUGGEDCOM RMC8388 V4.X (All versions), RUGGEDCOM RMC8388 V5.X (All versions < V5.10.0), RUGGEDCOM RP110 (All versions), RUGGEDCOM RS1600 (All versions), RUGGEDCOM RS1600F (All versions), RUGGEDCOM RS1600T (All versions), RUGGEDCOM RS400 (All versions), RUGGEDCOM RS401 (All versions), RUGGEDCOM RS416 (All versions), RUGGEDCOM RS416P (All versions), RUGGEDCOM RS416Pv2 V4.X (All versions), RUGGEDCOM RS416Pv2 V5.X (All versions < V5.10.0), RUGGEDCOM RS416v2 V4.X (All versions), RUGGEDCOM RS416v2 V5.X (All versions < V5.10.0), RUGGEDCOM RS8000 (All versions), RUGGEDCOM RS8000A (All versions), RUGGEDCOM RS8000H (All versions), RUGGEDCOM RS8000T (All versions), RUGGEDCOM RS900 (All versions), RUGGEDCOM RS900 (32M) V4.X (All versions), RUGGEDCOM RS900 (32M) V5.X (All versions < V5.10.0), RUGGEDCOM RS900G (All versions), RUGGEDCOM RS900G (32M) V4.X (All versions), RUGGEDCOM RS900G (32M) V5.X (All versions < V5.10.0), RUGGEDCOM RS900GP (All versions), RUGGEDCOM RS900L (All versions), RUGGEDCOM RS900M-GETS-C01 (All versions), RUGGEDCOM RS900M-GETS-XX (All versions), RUGGEDCOM RS900M-STND-C01 (All versions), RUGGEDCOM RS900M-STND-XX (All versions), RUGGEDCOM RS900W (All versions), RUGGEDCOM RS910 (All versions), RUGGEDCOM RS910L (All versions), RUGGEDCOM RS910W (All versions), RUGGEDCOM RS920L (All versions), RUGGEDCOM RS920W (All versions), RUGGEDCOM RS930L (All versions), RUGGEDCOM RS930W (All versions), RUGGEDCOM RS940G (All versions), RUGGEDCOM RS969 (All versions), RUGGEDCOM RSG2100 (All versions), RUGGEDCOM RSG2100 (32M) V4.X (All versions), RUGGEDCOM RSG2100 (32M) V5.X (All versions < V5.10.0), RUGGEDCOM RSG2100P (All versions), RUGGEDCOM RSG2100P (32M) V4.X (All versions), RUGGEDCOM RSG2100P (32M) V5.X (All versions < V5.10.0), RUGGEDCOM RSG2200 (All versions), RUGGEDCOM RSG2288 V4.X (All versions), RUGGEDCOM RSG2288 V5.X (All versions < V5.10.0), RUGGEDCOM RSG2300 V4.X (All versions), RUGGEDCOM RSG2300 V5.X (All versions < V5.10.0), RUGGEDCOM RSG2300P V4.X (All versions), RUGGEDCOM RSG2300P V5.X (All versions < V5.10.0), RUGGEDCOM RSG2488 V4.X (All versions), RUGGEDCOM RSG2488 V5.X (All versions < V5.10.0), RUGGEDCOM RSG907R (All versions < V5.10.0), RUGGEDCOM RSG908C (All versions < V5.10.0), RUGGEDCOM RSG909R (All versions < V5.10.0), RUGGEDCOM RSG910C (All versions < V5.10.0), RUGGEDCOM RSG920P V4.X (All versions), RUGGEDCOM RSG920P V5.X (All versions < V5.10.0), RUGGEDCOM RSL910 (All versions < V5.10.0), RUGGEDCOM RST2228 (All versions < V5.10.0), RUGGEDCOM RST2228P (All versions < V5.10.0), RUGGEDCOM RST916C (All versions < V5.10.0), RUGGEDCOM RST916P (All versions < V5.10.0). The affected products support insecure cryptographic algorithms. An attacker could leverage these legacy algorithms to achieve a man-in-the-middle attack or impersonate communicating parties. |
| Missing cryptographic key commitment in the Amazon S3 Encryption Client for Go may allow a user with write access to the S3 bucket to introduce a new EDK that decrypts to different plaintext when the encrypted data key is stored in an "instruction file" instead of S3's metadata record.
To mitigate this issue, upgrade Amazon S3 Encryption Client for Go to version 4.0 or later. |
| Missing cryptographic key commitment in the AWS SDK for C++ may allow a user with write access to the S3 bucket to introduce a new EDK that decrypts to different plaintext when the encrypted data key is stored in an "instruction file" instead of S3's metadata record.
To mitigate this issue, upgrade AWS SDK for C++ to version 1.11.712 or later |
| Emissary is a P2P based data-driven workflow engine. The ChecksumCalculator class within allows for hashing and checksum generation, but it includes or defaults to algorithms that are no longer recommended for secure cryptographic use cases (e.g., SHA-1, CRC32, and SSDEEP). These algorithms, while possibly valid for certain non-security-critical tasks, can expose users to security risks if used in scenarios where strong cryptographic guarantees are required. This issue is fixed in 8.24.0. |
| Weak server key used for TLS encryption. The following products are affected: Acronis Cyber Protect 16 (Linux, macOS, Windows) before build 39938. |
| Inadequate encryption strength for some Edge Orchestrator software for Intel(R) Tiber™ Edge Platform may allow an authenticated user to potentially enable escalation of privilege via adjacent access. |
| Due to outdated Hash algorithm, HCL Glovius Cloud could allow attackers to guess the input data using brute-force or dictionary attacks efficiently using modern hardware such as GPUs or ASICs |
| ### Impact
When this library is used to deserialize messagepack data from an untrusted source, there is a risk of a denial of service attack by an attacker that sends data contrived to produce hash collisions, leading to large CPU consumption disproportionate to the size of the data being deserialized.
This is similar to [a prior advisory](https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-7q36-4xx7-xcxf), which provided an inadequate fix for the hash collision part of the vulnerability.
### Patches
The following steps are required to mitigate this risk.
1. Upgrade to a version of the library where a fix is available.
1. Review the steps in [this previous advisory](https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-7q36-4xx7-xcxf) to ensure you have your application configured for untrusted data.
### Workarounds
If upgrading MessagePack to a patched version is not an option for you, you may apply a manual workaround as follows:
1. Declare a class that derives from `MessagePackSecurity`.
2. Override the `GetHashCollisionResistantEqualityComparer<T>` method to provide a collision-resistant hash function of your own and avoid calling `base.GetHashCollisionResistantEqualityComparer<T>()`.
3. Configure a `MessagePackSerializerOptions` with an instance of your derived type by calling `WithSecurity` on an existing options object.
4. Use your custom options object for all deserialization operations. This may be by setting the `MessagePackSerializer.DefaultOptions` static property, if you call methods that rely on this default property, and/or by passing in the options object explicitly to any `Deserialize` method.
### References
- Learn more about best security practices when reading untrusted data with [MessagePack 1.x](https://github.com/MessagePack-CSharp/MessagePack-CSharp/tree/v1.x#security) or [MessagePack 2.x](https://github.com/MessagePack-CSharp/MessagePack-CSharp#security).
- The .NET team's [discussion on hash collision vulnerabilities of their `HashCode` struct](https://github.com/GrabYourPitchforks/runtime/blob/threat_models/docs/design/security/System.HashCode.md).
### For more information
If you have any questions or comments about this advisory:
* [Start a public discussion](https://github.com/MessagePack-CSharp/MessagePack-CSharp/discussions)
* [Email us privately](mailto:[email protected]) |
| Missing cryptographic key commitment in the Amazon S3 Encryption Client for Java may allow a user with write access to the S3 bucket to introduce a new EDK that decrypts to different plaintext when the encrypted data key is stored in an "instruction file" instead of S3's metadata record.
To mitigate this issue, upgrade Amazon S3 Encryption Client for Java to version 4.0.0 or later. |
| Missing cryptographic key commitment in the AWS SDK for PHP may allow a user with write access to the S3 bucket to introduce a new EDK that decrypts to different plaintext when the encrypted data key is stored in an "instruction file" instead of S3's metadata record.
To mitigate this issue, upgrade AWS SDK for PHP to version 3.368.0 or later |
| In illumos illumos-gate 2024-02-15, an error occurs in the elliptic curve point addition algorithm that uses mixed Jacobian-affine coordinates, causing the algorithm to yield a result of POINT_AT_INFINITY when it should not. A man-in-the-middle attacker could use this to interfere with a connection, resulting in an attacked party computing an incorrect shared secret. |
| A static initialization vector (IV) in the encrypt function of netbird management's service from v0.23.2 to v0.29.1 allows attackers to obtain sensitive information (email addresses) when in possession of the audit events database. |
| Reusing a nonce, key pair in encryption issue exists in "FreeFrom - the nostr client" App versions prior to 1.3.5 for Android and iOS. If this vulnerability is exploited, the content of direct messages (DMs) between users may be manipulated by a man-in-the-middle attack. |
