CVE-2026-17379 is a vulnerability in IBM API Connect versions 10.0.8.0 through 10.0.8.12 and 12.1.0.0 through 12.1.1.2. It involves improper verification of cryptographic signatures, which could allow a remote attacker to bypass authentication and assign arbitrary roles.
CVE-2026-17301 is a critical vulnerability in IBM API Connect versions 10.0.8.0 through 10.0.8.12 and 12.1.0.0 through 12.1.1.2. It involves improper verification of a cryptographic signature, which could allow an unauthenticated attacker to bypass authentication controls.
CVE-2026-105459 is a vulnerability in IBM API Connect versions 10.0.8.0 through 10.0.8.12 and 12.1.0.0 through 12.1.1.2. It involves improper verification of cryptographic signatures, where a token can be accepted without full signature validation. This flaw could allow an attacker to gain unauthorized access to an organization by joining it without a valid invitation.
Chartbrew versions prior to 5.2.3 contain a vulnerability in the verification of cryptographic signatures for chart share and embed tokens. The tokens were signed using a secret (CB_SECRET) that could be a known or default value in stock installations. An attacker who knows this secret can forge valid share tokens to access private chart data without authentication by enumerating chart IDs. This vulnerability is fixed in version 5.2.3.
TracecatHQ's tracecat versions from 0.37.0 up to but not including 1.0.0-beta.49 have a critical vulnerability in Docker Compose deployments with SAML enabled. The vulnerability allows an unauthenticated attacker to bypass signature verification of SAML assertions and responses, enabling session hijacking for existing users, including superadmin account takeover. This flaw is fixed in version 1.0.0-beta.49, which enforces signed assertions and responses.
CVE-2026-122267 is a vulnerability in Chainguard MinIO where the Signature V4 verification process before RELEASE.2026-09-22T19-25-18Z improperly accepts unsigned x-amz-* headers. This flaw allows an attacker to escalate a presigned PUT URL into a cross-bucket read operation.
A cryptographic signature verification flaw exists in the russh SSH server library versions from 0.34.0-beta.1 up to but not including 0.64.0. The server does not enforce that the signature algorithm in a public-key authentication matches the algorithm declared in the authentication request. This allows a client with an authorized RSA private key to present a mismatched signature algorithm and signature, potentially bypassing restrictions or causing misleading audit logs. The issue is fixed in version 0.64.0.
CVE-2026-116790 is an authentication bypass vulnerability in FreeSWITCH prior to version 1.11.2. The flaw involves the inbound ICE handling accepting all connectivity checks without verifying the STUN MESSAGE-INTEGRITY attribute cryptographically. This allows an attacker on the network to spoof ICE connectivity checks, nominate their own address, redirect RTP and DTLS traffic, and terminate the legitimate media path. Unencrypted media legs are vulnerable to eavesdropping and media injection. The issue affects all WebRTC and SIP legs that negotiate ICE. The vulnerability is fixed in FreeSWITCH version 1.11.2 by enabling ice_verify_message_integrity=true.
GPUStack is an open-source GPU cluster manager for AI model serving and GPU instance provisioning. From 0.7.1 until 2.2.2, the /auth/saml/callback endpoint decoded SAML XML, used its NameID and attributes to resolve or provision a user, and minted a gpustack_session JWT without calling OneLogin_Saml2_Auth.process_response to verify the signature, issuer, audience, destination, or time conditions. Any network client could submit an identity for an existing user, including an administrator, or provision a new non-administrator account, even when SAML was not configured. Response and Assertion identifiers were not consumed, so captured signed responses could also be replayed. This issue is fixed in version 2.2.2.
PLCnext Engineer checks GSDX manifest reference digests but does not cryptographically verify the XML `SignatureValue` over canonicalized `SignedInfo`. An unauthenticated local attacker can modify signed GSDML content, update its manifest digest, retain the public certificate data, and leave an invalid nonempty `SignatureValue`. PLCnext Engineer prior to 2026.6 reports the package as `Valid` and selects the modified device description for import under the default policy.
Dell Alienware Command Center (AWCC), versions prior to 6.14.54.0, contain an Improper Verification of Cryptographic Signature vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of Privilege and Arbitrary Code Execution.
Dell Alienware Command Center (AWCC), versions prior to 6.14.54.0, contain an Improper Verification of Cryptographic Signature vulnerability. An unauthenticated attacker with adjacent network access could potentially exploit this vulnerability, leading to Arbitrary Code Execution and Elevation of Privilege.
Dell OpenManage Enterprise, versions prior to 4.8.0, contains an Improper Verification of Cryptographic Signature vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to Filesystem access for attacker.
Dell OpenManage Enterprise, versions prior to 4.8.0, contains an Improper Verification of Cryptographic Signature vulnerability. A high privileged attacker with adjacent network access could potentially exploit this vulnerability, leading to Code execution.
@fastify/secure-session is a session plugin for Fastify that stores an encrypted session in a cookie. In versions 7.5.0 through 8.4.1, when the plugin is configured with the signed cookie option, it calls the cookie unsign routine but, when the signature check reports the value as invalid, still passes the original cookie value to the session decoder, so a session whose signature did not validate is decrypted anyway. The practical effect appears when an application supplies the cookie signing secret independently of the session encryption key and rotates only the signing secret to retire existing sessions while keeping the encryption key active, because a holder of an old session cookie can strip the now obsolete signature and keep using the session. The attacker must already possess an unexpired encrypted session cookie and needs neither secret, and cannot forge session data, extend expiry, or survive rotation of the encryption key. The issue is fixed in @fastify/secure-session 8.4.2, which no longer decodes the session when the signed cookie option is set and the signature check fails, and users should upgrade to 8.4.2 or later. As a workaround, rotate the session encryption key rather than relying on rotation of the cookie signing secret alone.
The `GITEA_TOKEN` of a Gitea Actions job authenticates as the `gitea-actions` system user, and the `/api/v1/user` email and GPG key endpoints accepted that user, so a job could register an email address and a GPG key on it; without required email confirmation (the default) the address is stored as activated. Commit verification treats a key without a real owner as the instance signing key, so any user who can run a workflow job could make commits signed with their own key show as trusted and signed by the instance in every repository where they appear, including pull requests to repositories the user cannot write to. The impact is limited to the displayed signature status: enforcement such as required signed commits only checks that a signature is verified and is unaffected, and no access is gained. The `/api/v1/user` routes now reject system users.
LightSAML implements SAML 2.0 data model classes, XML serialization and deserialization, XML security, certificate support, and message bindings. Prior to 4.7.1 and 5.0.1, LightSAML and xmlseclibs disagree about which assertion an inbound SAML signature covers. `Response::deserialize` uses `manyElementsFromXml` to collect only direct-child `saml:Assertion` elements of `samlp:Response`, and `AssertionSignatureValidatorAction` validates their `ds:Signature` using an out-of-band trusted IdP credential resolved by Issuer, not a key from the document. `XMLSecurityDSig::validateReference()` removes the enveloped signature from the shared DOM, but `processRefNode()` resolves `Reference URI="#id"` document-wide through an XPath of the form `//*[@Id]` and takes `item(0)`, which need not be the assertion whose claims LightSAML consumes. An attacker who has captured one genuinely signed assertion, such as an earlier login response, can place its signature-stripped bytes earlier in `samlp:Extensions` and present a forged direct-child assertion with the same ID and copied genuine signature. Validation then covers the hidden genuine bytes while LightSAML surfaces unsigned attacker-controlled `Subject/NameID`, `Conditions`, and `Attributes`, enabling authentication bypass or privilege escalation even when signature validation is required. The behavior was confirmed in versions 5.0.0 and 4.6.1. This issue is fixed in versions 4.7.1 and 5.0.1.
Open Access Management (OpenAM) is an access management solution. Prior to 16.1.1, the `RADIUS` authentication module opens an unconnected datagram socket and trusts the first UDP datagram received on the client source port. The receive path does not verify the source IP and port, match the response identifier to the outstanding request, or verify the RFC 2865 `Response Authenticator`; the RFC 2869 `Message-Authenticator` is neither sent nor required. Any non-Reject/non-Challenge packet is treated as success. On a deployment with a `RADIUS` module instance enabled on a login chain, an unauthenticated network attacker can race the real server on-path or spray forged `Access-Accept` packets off-path and obtain a session for any `RADIUS`-mapped username without knowing the shared secret. Unlike CVE-2024-3596, exploitation requires no MD5 chosen-prefix forgery because no response authenticator is checked. The resulting session carries the impersonated principal's privileges. This issue is fixed in version 16.1.1.
Business-GoCardless versions prior to 1.01 for Perl contain a vulnerability where cryptographic signatures on webhooks are improperly verified if the webhook secret is undefined or empty. This flaw allows attackers to forge webhooks by signing them with an empty key, which the system incorrectly accepts as valid.
Improper Verification of Cryptographic Signature vulnerability in Drupal Commerce Stripe allows Signature Spoof. This issue affects Commerce Stripe versions: from 0.0.0 to 1.4, from 2.0.0 to 2.2.3.