NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer where improper verification of cryptographic signatures may cause signature verification to be bypassed under memory pressure. A successful exploit of this vulnerability might lead to denial of service and data tampering.
CVE-2026-55174 is a medium severity vulnerability in the shrec UltrafastSecp256k1 library prior to version 4.2.0. The issue involves insufficient verification of data authenticity in the ECDSA adaptor pre-signature verification process, where forged adaptor pre-signatures with an "r" value not cryptographically bound to the adaptor point "T" can be accepted. This flaw has been addressed in version 4.2.0.
Improper Verification of Cryptographic Signature and Improper Certificate Validation in the OPC UA driver of Apache PLC4X (PLC4J) allows an attacker in a network position between client and server to impersonate the OPC UA server and to read, forge or modify secure-channel traffic, including user credential ssent by the client.
The defect manifests differently depending on the version:
- In 0.9.0 through 0.11.0 a failed message-signature check is only logged and never enforced, and there is no mechanism to verify the server certificate: it is taken from the unauthenticated GetEndpoints discovery response and used to encrypt the user's password.
- In 0.12.0 through 0.13.1 the signature check is inverted (valid signatures are rejected, invalid ones accepted), and server certificates are accepted without a trust anchor by default.
- In all affected versions the default security policy is None. Starting with 0.12.0 the driver additionally continues silently at a weaker security policy than the one configured, and starting with 0.13.0 endpoint selection prefers the weakest matching endpoint.
Users checking only for one of these mechanisms may wrongly conclude they are unaffected.
This issue affects Apache PLC4X: from 0.9.0 before 1.0.0.
Users are recommended to upgrade to version 1.0.0, which fixes the issue. Version 1.0.0 verifies message signatures correctly, refuses to connect unless the server certificate can be verified against a configured trust store or pinned certificate, defaults to Basic256Sha256 with SignAndEncrypt, and fails the
connection if the negotiated security policy is weaker than the configured one.
The device's update mechanism includes conditions that allow unauthorized software packages to be accepted as authentic. During the boot process, the stock done function disables signature verification in the OPKG configuration before restoring optional packages from a writable, unsigned feed. Separately, the publicly distributed SDK contains the production private key whose corresponding public key is trusted by both stable and beta firmware builds. Either issue undermines package authenticity, and together they allow an attacker to provide packages that appear valid to the system. Even if signature enforcement is restored, the exposed production key enables an attacker to generate signatures that the device will continue to trust. An attacker who can supply a malicious package may be able to execute arbitrary code with root privileges during installation.
Anjvision YSSD-RTMP-H5 firmware version 3.3.2.4 has a vulnerability where the update mechanisms, both local and cloud, do not perform cryptographic signature verification on new firmware. Instead, they rely solely on basic hashing, allowing an attacker with access to the update routine to install untrusted firmware. This flaw can lead to full compromise of the device's confidentiality, integrity, and availability.
PyJWT versions from 2.4.0 up to but not including 2.14.0 contain a vulnerability in the HMACAlgorithm.prepare_key function. This flaw arises when applications mix HMAC and asymmetric algorithms and provide a DER-encoded public key as the shared verification key. Due to improper verification of cryptographic signatures, PyJWT mistakenly uses the public DER bytes as an HMAC secret. An attacker with knowledge of the public key can exploit this to forge authenticated HMAC tokens. The vulnerability is fixed in version 2.14.0.
PyJWT versions prior to 2.14.0 contain a vulnerability in the is_pem_format function that improperly verifies cryptographic signatures. This flaw allows an attacker who knows a public key to forge authenticated HMAC tokens by exploiting how the library misinterprets certain malformed PEM public keys as HMAC secrets. The issue is resolved in version 2.14.0.
PyJWT versions from 2.13.0 up to but not including 2.14.0 contain a vulnerability in the HMACAlgorithm.prepare_key function. The issue arises because the HMAC key guard only recognizes top-level public JWK forms and misses container representations, allowing public asymmetric key material to be accepted as the HMAC secret. This flaw enables an attacker who knows the public key to forge tokens with arbitrary authenticated claims. The vulnerability is fixed in version 2.14.0.
PyJWT version 2.13.0 has a vulnerability in its cryptographic signature verification due to improper handling of UTF-8 BOM prefixes in JSON Web Key detection. This flaw allows attackers who know the RSA public key to forge JWT tokens with arbitrary claims if the verifier accepts both HS256 and RS256 algorithms. The issue causes an RSA public key to be misinterpreted as an HMAC secret, resulting in complete authentication and authorization bypass. A fix has been committed but not yet released as of the advisory date.
CVE-2026-102266 is a vulnerability in PyJWT 2.13.0 where verification of HS256 tokens using an empty symmetric octet JWK key bypasses the intended empty key rejection. While raw empty HMAC keys are rejected, empty keys supplied via PyJWK objects are accepted, allowing attackers to forge valid HS256 JWTs if the application uses an empty key in its JWK set. This occurs because the PyJWK verification path does not invoke the empty key validation, enabling signature verification with a zero-length key.
Contrast is a Kubernetes runtime for confidential containers. In versions before 1.12.1, the secure persistent volume feature is vulnerable to a malicious host supplying a crafted LUKS2 volume to a pod VM. LUKS2 volume metadata is not authenticated and, with cryptsetup versions prior to 2.8.1, a header specifying the null keyslot encryption algorithm (cipher_null-ecb) is accepted without error. Because the Contrast Initializer assumes a device is protected if `cryptsetup open` succeeds with the secret seed, the guest will open the attacker-supplied volume and write secret data in plaintext, or under a volume key known to the attacker, allowing the host to read confidential data that should have been encrypted. Contrast v1.12.1 ships cryptsetup 2.8.1, which disables null ciphers in keyslots when the passphrase is non-empty; v1.13.0 adds detached-header validation in guest memory and integrity protection for secure persistent storage. Contrast persistent volumes were not integrity protected, so integrity impact is not considered.
IRONMACE Ironshield 1.0.0.167 has a tvk.sys kernel-mode driver that authenticates client executables by checking for expected publisher and root-certificate strings in WIN_CERTIFICATE data ("IRONMACE Co., Ltd." and "DigiCert Trusted Root G4") instead of parsing and validating the PKCS signature data. As a result, a local unprivileged attacker may bypass this via crafted certificate data and obtain access to privileged IOCTL functionality.
Python Social Auth's social-core component prior to version 5.0.0 contains an improper authentication vulnerability in the vk-app backend. The backend accepted VK application callback data without verifying the callback signature if the auth_key parameter was missing. This allowed attackers to impersonate arbitrary VK user identities by manipulating callback fields. The issue is fixed in version 5.0.0 by enforcing the presence and validity of auth_key before trusting callback data.
Improper Verification of Cryptographic Signature vulnerability in dashbit nimble_zta allows an unauthenticated remote attacker to authenticate as an arbitrary Cloudflare service token. Applications using the Cloudflare Zero Trust authentication strategy are affected.
verify_token/2 in lib/nimble_zta/cloudflare.ex matches the result of JOSE.JWT.verify/2 against {_, token, _s}, which discards the boolean verification result and returns the decoded token after a failed signature check. The attacker sends a forged JWT in the cf-access-jwt-assertion header, carrying the expected iss claim and the seven service token claims. verify_iss/2 reads the iss claim from the forged token, so it rejects nothing, and the service token path then returns those claims as the authenticated identity.
This issue affects nimble_zta: from 0.1.2 before 0.1.3.
A signature validation vulnerability exists in Foxit PDF Editor/Reader’s handling of incrementally updated PDF documents. Changes to visible document content may not invalidate the existing signature, allowing attackers to alter signed content and potentially carry out content spoofing while the document continues to appear validly signed.
IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote attacker to forge validly-signed messages due to improper verification of cryptographic signatures.
The Payment Gateway of Stripe for WooCommerce plugin for WordPress is vulnerable to Improper Verification of Cryptographic Signature in all versions up to, and including, 5.0.8. This is due to the publicly accessible `woocommerce_api_wt_stripe` webhook endpoint (`EH_Stripe_Webhook_Handler::handle()`) wrapping the only call to `\Stripe\Webhook::constructEvent()` inside an `if (!empty($endpoint_secret))` guard that is never entered on default installations — because the `eh_stripe_webhook_secret` option is empty after a fresh plugin install — causing the raw, attacker-controlled POST body to be decoded and processed as a fully trusted Stripe event without any signature verification, authentication, or authorization. This makes it possible for unauthenticated attackers to send forged Stripe webhook events to manipulate WooCommerce order statuses, including marking unpaid orders as paid or completed via `payment_complete()`, forcing legitimate orders into a failed state, fabricating dispute notifications, and injecting forged refund events. This vulnerability is only exploitable when the Stripe webhook signing secret has not been configured by an administrator; once a valid signing secret is saved, `\Stripe\Webhook::constructEvent()` is enforced and forged requests are rejected.
Mnemosyne is a memory layer for artificial intelligence agents. Prior to v3.10.1, the auth check in mnemosyne/core/sync_server.py parsed the JWT's header and payload using base64 decoding, then passed the token to a jwt library call with options that effectively disabled signature verification. The server accepted any well-formed token regardless of the signature, including tokens with alg: none and tokens signed with the wrong key. The fix in v3.10.1 replaces the broken decode with a from-scratch HS256 verifier using only the Python standard library. For users who cannot upgrade immediately, restrict network access to the sync server endpoint to trusted clients only. Firewall, reverse proxy with mTLS, or localhost bind with SSH tunnel are all viable. The vulnerability is not exploitable against an unreachable endpoint.
An authenticated user with access to the NetBackup Flex OS management
shell could read arbitrary files from the underlying operating system by
supplying a specially crafted path argument to a diagnostic command.
Successful exploitation could expose sensitive system configuration and
credential material stored on the appliance.
An authenticated, low-privileged user with access to the NetBackup Flex
OS management shell could bypass the cryptographic signature
verification step of a privileged support command by supplying a
specially formed access credential. Successful exploitation grants the
attacker an unrestricted root shell with full control over the Flex
appliance host and all hosted containers, completely compromising
confidentiality, integrity, and availability.