| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Improper OCSP response validation in the Snowflake Python, Go, JDBC, and Node.js drivers allowed a revoked TLS certificate to be accepted as valid, because OCSP responses were not reliably bound to the certificate being validated and definitive verification failures were treated as transient. A man-in-the-middle attacker holding a revoked certificate and its private key for a Snowflake or stage hostname could cause the driver to establish a TLS session to the attacker-controlled endpoint anyway, allowing the attacker to read and modify data transmitted within that connection. Successful exploitation requires that on-path position and the corresponding private key, and impact is limited to data carried within the intercepted connection. The fix is available in Snowflake Connector for Python v4.7.3, Snowflake Go Driver v2.2.0, Snowflake JDBC Driver v4.3.4 (including the snowflake-jdbc-fips and snowflake-jdbc-thin), and Snowflake Node.js Driver v3.3.0. Users must manually upgrade. |
| An issue in OpenDDS 3.33.x allows a local attacker to cause a denial of service via the verify function in the SIgnedDocument module |
| Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, summary In Zammad's inbound PGP email processing, the return value of the gpg verification call was silently discarded. Regardless of whether gpg reported a valid, invalid, or missing signature, the handler unconditionally wrote sign: { success: true, comment: "Good signature" } to the article's security preferences. Impact Any sender could tamper with the body of a multipart/signed PGP email, or craft a message with an entirely fabricated or mismatched signature, and Zammad would display it to the recipient as cryptographically verified with a "Good signature" label. Users and agents relying on Zammad's signature indicator to confirm message authenticity and integrity would be misled into trusting modified or forged content. The vulnerability affects all inbound PGP-signed emails processed while the PGP integration is enabled. This issue is fixed in version 7.0.2. |
| Zammad is a web based open source helpdesk/customer support system. In 7.0.3 and 7.1.1, under certain conditions, Zammad's verification of inbound PGP-signed email can mark a message as carrying a valid ("Good") PGP signature from a registered sender key, even though the displayed message content is not actually covered by that signature. As a result, the inbound article may be stored with a successful signature status that does not reflect the authenticity of the shown content. This can mislead agents who rely on the signature indicator when assessing the trustworthiness of incoming mail. This issue is fixed in version 7.1.2. |
| MinIO through 7aac2a2 does not verify that every x-amz-* header present on a request also appears in the client-supplied X-Amz-SignedHeaders list. extractSignedHeaders() in cmd/signature-v4-utils.go iterates only the claimed list and never enumerates the headers that actually arrived, and thus a header that arrives unsigned is neither hashed into the canonical request nor rejected. Because cmd/api-router.go dispatches CopyObject on the presence of x-amz-copy-source alone, the holder of a presigned PUT URL scoped to a single object can add that header to the unmodified URL and cause a server-side copy, executed as the signer, of any object the signing key can read. A grant to write one object becomes a read of every bucket that key can reach. Amazon S3 rejects the equivalent request with HTTP 403 AccessDenied. The minio/minio GitHub repository was archived in April 2026; pgsty/silo before 1233254 is also affected. |
| RouterOS does not compare the complete RSA public key when matching an SSH authentication request to an authorized user key, checking the key type and modulus but omitting the exponent. Because signature verification uses the client-supplied key, an attacker knowing an authorized RSA modulus can supply a key with exponent one, forge a valid signature, and open an SSH command channel as the target user without the private key.This issue affects only 7.x branch was fixed in versions: 7.23.4 (Long-term) and 7.24.2 (Stable) |
| MikroTik RouterOS accepts malformed RSA/PKCS#1 v1.5 signatures across RSA-based services, including TLS/X.509 certificate validation and SSH host-key authentication. Because its trust store includes an e=3 root CA, an attacker controlling or redirecting an outbound RouterOS TLS connection can use the root’s public certificate - without its private key - to forge a trusted intermediate and issue certificates for arbitrary hostnames, enabling TLS server impersonation. The same permissive verification also undermines RSA-based SSH authentication.
This issue affects only 7.x branch was fixed in versions: 7.23.6 (Long-term) and 7.24.3 (Stable).
Releases 7.23.4 and 7.24.2 included an incomplete fix. |
| 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. |
| A flaw was found in Picketlink's SP signature validation; a SAML response containing zero assertion elements matching the signature check can allow an attacker to forge a SAML response and auth as any principal with any roles on the protected application. |
| A flaw was found in Picketlink Federation SAML; the unsolcited response handler would accept forged assertions with no verification or validation, permitting an unauthed attacker to authenticate as any principal in any role. This could lead to information disclosure, access to restricted operations, or other flaws. |
| The JWT authentication mechanism accepts tokens signed with algorithms other than those explicitly configured or supported. This allows an attacker to craft a JWT with an unsupported algorithm, which is then incorrectly validated, leading to unauthorized access.
Successful exploitation of this vulnerability may result in unauthorized access to the system, including the potential compromise of administrative accounts and full account takeover. The CVSS score is adjusted to 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) in single-tenant deployments, reflecting that the impact is contained within a single security authority boundary. |
| 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. |
| The github-issue-bot templates in appwrite/templates verify the GitHub webhook signature with an inverted condition. verifyWebhook in node/github-issue-bot/src/github.js and in node-typescript/github-issue-bot/src/github.ts returns "typeof signature !== 'string' || (await verify(...))", so when the X-Hub-Signature-256 header is absent the first operand is true, the logical OR short-circuits, and the function reports success without performing any HMAC verification. main.js rejects a request only when verifyWebhook returns false, so an unauthenticated request carrying no signature passes the check. Processing then continues to postComment, which takes the repository and issue objects directly from the request body, letting the caller direct the deployed function to post a comment on a repository and issue of their choosing using the configured GITHUB_TOKEN, with the issue author login from the body interpolated into the comment text. |
| A flaw was found in openshift/oc-mirror. The tool incorrectly verifies PGP (Pretty Good Privacy) release image signatures by checking for signature errors before the entire signed body is processed, leading to a bypass of the signature verification. A remote attacker, by intercepting or manipulating network traffic to the signature endpoint, could exploit this to craft a PGP message with a valid Red Hat release key ID but a forged signature. This enables the `oc-mirror` tool to accept and mirror a malicious release payload into a disconnected registry, potentially compromising the integrity of software deployments. |
| 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. |
| A flaw was found in the Kerberos federation provider of Keycloak, an open-source identity and access management solution. When Kerberos password authentication is used without SPNEGO, the system fails to verify the identity of the Key Distribution Center (KDC) by requesting a server ticket. This allows an attacker on the same network to spoof the KDC and bypass the authentication process, potentially gaining unauthorized access to user accounts. |
| hickory-resolver versions before 0.26.2 fail to propagate bogus DNSSEC proof states through the Resolver::lookup() and Resolver::lookup_ip() APIs, allowing invalid records to be returned as successful results. Attackers controlling the answering zone or positioned on the network path can have forged DNS records accepted as validated, bypassing DNSSEC authentication checks. |
| Notepad++ is a free and open-source source code editor. From 8.9.7 until 8.9.8, the Notepad++ updater and signature verification path can accept a modified GUP.exe file whose embedded certificate metadata remains present even though its Authenticode digest is invalid. An attacker who can replace or plant the updater-related file can cause Notepad++ to launch attacker-modified code when a user triggers the updater path, but the issue does not provide remote code execution by itself. This issue is fixed in version 8.9.8. |
| A flaw was found in the signature verification logic of noobaa-core, the core component of the NooBaa Multicloud Object Gateway. The issue occurs when the service processes S3 presigned URLs using Signature Version 4 (SigV4). Due to improper validation, the service fails to reject requests containing unsigned x-amz- headers, instead simply dropping them from the signature calculation. This allows an attacker who possesses a valid presigned PUT URL to add an unsigned x-amz-copy-source header, effectively converting a simple upload into a CopyObject operation. This can lead to unauthorized access and copying of any data the original signer is permitted to reach across the entire storage system. |
