| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| 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. |
| cjwt is a C JSON Web Token (JWT) Implementation. Algorithm confusion occurs when a system improperly verifies the type of signature used, allowing attackers to exploit the lack of distinction between signing methods. If the system doesn't differentiate between an HMAC signed token and an RS/EC/PS signed token during verification, it becomes vulnerable to this kind of attack. For instance, an attacker could craft a token with the alg field set to "HS256" while the server expects an asymmetric algorithm like "RS256". The server might mistakenly use the wrong verification method, such as using a public key as the HMAC secret, leading to unauthorised access. For RSA, the key can be computed from a few signatures. For Elliptic Curve (EC), two potential keys can be recovered from one signature. This can be used to bypass the signature mechanism if an application relies on asymmetrically signed tokens. This issue has been addressed in version 2.3.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability. |
| rfc3161-client is a Python library implementing the Time-Stamp Protocol (TSP) described in RFC 3161. Prior to version 1.0.3, there is a flaw in the timestamp response signature verification logic. In particular, chain verification is performed against the TSR's embedded certificates up to the trusted root(s), but fails to verify the TSR's own signature against the timestamping leaf certificates. Consequently, vulnerable versions perform insufficient signature validation to properly consider a TSR verified, as the attacker can introduce any TSR signature so long as the embedded leaf chains up to some root TSA. This issue has been patched in version 1.0.3. There is no workaround for this issue. |
| Improper verification of the digital signature in ksojscore.dll in Kingsoft WPS Office in versions equal or less than 12.1.0.18276
on Windows allows an attacker to load an arbitrary Windows library. The patch released in version 12.2.0.16909 to mitigate CVE-2024-7262 was not restrictive enough. |
| sigstore-java is a sigstore java client for interacting with sigstore infrastructure. sigstore-java has insufficient verification for a situation where a validly-signed but "mismatched" bundle is presented as proof of inclusion into a transparency log. This bug impacts clients using any variation of KeylessVerifier.verify(). The verifier may accept a bundle with an unrelated log entry, cryptographically verifying everything but fails to ensure the log entry applies to the artifact in question, thereby "verifying" a bundle without any proof the signing event was logged. This allows the creation of a bundle without fulcio certificate and private key combined with an unrelated but time-correct log entry to fake logging of a signing event. A malicious actor using a compromised identity may want to do this to prevent discovery via rekor's log monitors. The signer's identity will still be available to the verifier. The signature on the bundle must still be on the correct artifact for the verifier to pass. sigstore-gradle-plugin and sigstore-maven-plugin are not affected by this as they only provide signing functionality. This issue has been patched in v1.1.0 release with PR #856. All users are advised to upgrade. There are no known workarounds for this vulnerability. |
| Improper Verification of Cryptographic Signature vulnerability in HYPR Passwordless on Windows allows Malicious Software Update.This issue affects HYPR Passwordless: before 9.1. |
| Improper signature verification in AMD CPU ROM microcode patch loader may allow an attacker with local administrator privilege to load malicious CPU microcode resulting in loss of confidentiality and integrity of a confidential guest running under AMD SEV-SNP. |
| An improper file signature check in Palo Alto Networks Cortex XDR agent may allow an attacker to bypass the Cortex XDR agent's executable blocking capabilities and run untrusted executables on the device. This issue can be leveraged to execute untrusted software without being detected or blocked. |
| An insufficiently secured internal function allows session generation for arbitrary users. The decodeParam function checks the JWT but does not verify which signing algorithm was used. As a result, an attacker can use the "ex:action" parameter in the VerifyUserByThrustedService function to generate a session for any user. |
| 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`. |
| 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. |
| ABB is aware of privately reported vulnerabilities in the product versions referenced in this CVE. An attacker could exploit these vulnerabilities by sending a specially crafted firmware or configuration to the system node, causing the node to stop, become inaccessible, or allowing the attacker to take control of the node. |
| 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. |
| aes-gcm is a pure Rust implementation of the AES-GCM. In decrypt_in_place_detached, the decrypted ciphertext (which is the correct ciphertext) is exposed even if the tag is incorrect. This is because in decrypt_inplace in asconcore.rs, tag verification causes an error to be returned with the plaintext contents still in buffer. The vulnerability is fixed in 0.4.3. |
| This vulnerability exists in the TP-Link Archer C50 due to improper signature verification mechanism in the firmware upgrade process at its web interface. An attacker with administrative privileges within the router’s Wi-Fi range could exploit this vulnerability by uploading and executing malicious firmware which could lead to complete compromise of the targeted device. |
| A vulnerability in the Image Signature Verification feature of Cisco SD-WAN Software could allow an authenticated, remote attacker with Administrator-level credentials to install a malicious software patch on an affected device.
The vulnerability is due to improper verification of digital signatures for patch images. An attacker could exploit this vulnerability by crafting an unsigned software patch to bypass signature checks and loading it on an affected device. A successful exploit could allow the attacker to boot a malicious software patch image.Cisco has released software updates that address the vulnerability described in this advisory. There are no workarounds that address this vulnerability. |
| 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. |
| An improper verification of cryptographic signature in Zscaler's SAML authentication mechanism on the server-side allowed an authentication abuse. |
| There is a vulnerability in the BMC firmware image authentication design
at Supermicro MBD-X12DPG-OA6
. An attacker can modify the firmware to bypass BMC inspection and bypass the signature verification process |
