| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| Improper Verification of Cryptographic Signature vulnerability in team-alembic AshAuthentication allows a caller of the token revocation action to neutralise a revocation or write arbitrary rows into the token resource.
AshAuthentication.TokenResource.RevokeTokenChange.change/3 reads the :token argument and decodes it with AshAuthentication.Jwt.peek/1, which delegates to Joken.peek_claims/1 and performs no signature check, unlike Jwt.verify/4. The jti, exp and sub claims it returns are written straight onto the revocation record, guarded only by byte_size(token) > 0. Because expires_at derives from the attacker-chosen exp, a forged copy of a genuine token that keeps the real jti but backdates exp yields a revocation row that is already expired: expunge_expired removes it and the genuine token passes revoked? again. Arbitrary jti and sub values can be inserted the same way.
This issue affects ash_authentication: from 0.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14. |
| For a secondary zone with transfers restricted by TSIG, `named` may start to serve the data provided in a zone transfer before the final message with the TSIG signature arrives. This could allow an attacker that does not actually possess a valid TSIG signature to send unauthorized zone contents to a secondary server. Although no TSIG signature ever arrives, `named` does not rollback to the pre-transfer state. To exploit the vulnerability, the transfer must be a multi-message TCP IXFR, as described by RFC 8945.
This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1. |
| Improper verification of cryptographic signature in Windows RDP Client allows an unauthorized attacker to disclose information over a network. |
| 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. |
| A flaw was found in sequoia-openpgp. The library incorrectly infers key flags for older certificates when a key flags subpacket is missing, leading to a discrepancy in how key capabilities are viewed. This key flag confusion allows an attacker to bypass the back-signature check. Consequently, an attacker can illegitimately bind an arbitrary subkey to their own certificate and forge signatures, completely compromising cryptographic integrity. |
| Improper verification of cryptographic signature in Skype for Business allows an unauthorized attacker to perform spoofing over an adjacent network. |
| The lack of signature verification of firmware update packages in VEO and VEO-XS Wi-Fi monitors, in versions prior to 01.48.001, allows an attacker who controls the delivery of an update to install unauthorised firmware. |
| Nuclei versions before 3.11.1 cache template signature verification based only on file modification time without content checksums. Attackers can replace verified templates with unsigned malicious content and restore the original modification time to bypass signature checks and execute arbitrary operating system commands. |
| Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Improper Verification of Cryptographic Signature vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to protection mechanism bypass. |
| The VeloCloud Edge software update workflow may accept update bundles without properly validating their signatures because the workflow does not restrict the digest algorithm used for artifact verification. An attacker with either sufficient privileges to upload packages to VeloCloud Orchestrator or credentials permitting direct access to an Edge may be able to install unauthorized software. |
| Payload Plugins is a collection of plugins designed to enhance Payload CMS. From 0.3.0 until 0.4.0, @jhb.software/payload-cloudinary-plugin deployments with clientUploads enabled expose POST /api/cloudinary-generate-signature, whose handler in cloudinary/src/getGenerateSignature.ts passes attacker-controlled body.paramsToSign directly to cloudinary.utils.api_sign_request without a key allowlist, collection policy, timestamp freshness check, or configured-folder enforcement. Any authenticated Payload user can obtain a valid Cloudinary HMAC-SHA1 signature for unauthorized parameters such as overwrite, type, notification_url, invalidate, folder, and public_id. The signature can authorize asset replacement, upload visibility changes, callbacks to attacker-selected URLs, cache invalidation, and uploads outside the intended folder. The client-visible Cloudinary API key is expected by the upload design, but the unrestricted server-side signature supplies the authorization value needed to complete these operations. This vulnerability is fixed in 0.4.0. |
| In multiple locations, there is a possible improper encryption key validation due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| The RSA and DSA public key parsers did not enforce size limits on key parameters. A crafted public key with an excessively large modulus or DSA parameter could cause several minutes of CPU consumption during signature verification. This could be triggered by unauthenticated clients during public key authentication. RSA moduli are now limited to 8192 bits, and DSA parameters are validated per FIPS 186-2. |
| PraisonAI is a multi-agent teams system. Prior to 4.6.59, the WhatsApp and Linear bot webhook handlers verify HMAC signatures only when WHATSAPP_APP_SECRET or LINEAR_WEBHOOK_SECRET is configured and otherwise parse and dispatch unsigned request bodies. A remote unauthenticated client that reaches the webhook route can forge messages, comments, or agent-session events, impersonate platform users, influence agent prompts and actions, and disrupt bot processing. This issue is fixed in 4.6.59. |
| When a libcurl-based application performs transfers via `SCP://` or `SFTP://`
and utilizes the `CURLOPT_SSH_KEYFUNCTION` callback, it may silently accept an
untrusted server. This vulnerability occurs when a server presents a host key
type that does not match the specific key type already recorded for that host
in the `known_hosts` file. Instead of rejecting the mismatch, the callback
mechanism fails to properly enforce the restriction, allowing the connection
to succeed without warning and risking a potential man-in-the-middle attack. |
| Improper verification of cryptographic signature vulnerability in Apache Syncope.
When SRA is configured for OAuth 2.0 without JWKS set URI assigned, an attacker can forge arbitrary JWTs to impersonate any user identity and permissions, gaining full access to services proxied by SRA.
This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 through 4.0.7, from 4.1.0-M0 through 4.1.2.
Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. |
| Doco-CD is a GitOps continuous delivery tool that automatically deploys and updates Docker Compose projects/services and Swarm stacks. Prior to version 0.90.1, a trust-boundary flaw in OCI artifact verification allowed artifact-provided deployment config to influence the policy used to verify that same artifact. When global OCI signature verification was enabled via `OCI_TRUST_POLICY` (`enabled: true`), an attacker with write access to the configured OCI tag could publish an unsigned or improperly signed artifact containing `.doco-cd.yml` with `oci.verify: false`. This could cause signature verification to be bypassed and untrusted deployment content to be applied. This primarily impacts users deploying from OCI artifacts where deployment config is read from artifact contents (for example, poll/webhook flows without trusted inline deployment overrides). The issue is fixed by enforcing a strict trust boundary and no-downgrade behavior. First, artifact-contained `.doco-cd.yml` is treated as untrusted for OCI trust-policy override decisions. Second, if global `OCI_TRUST_POLICY.enabled` is `true`, per-deployment `oci.verify: false` cannot disable verification. Some workarounds are available. Do not source deployment config from untrusted OCI artifact contents. Use trusted inline `POLL_CONFIG.deployments` and avoid relying on artifact-contained trust-policy overrides. Restrict write/push permissions for OCI repositories/tags used by doco-cd. Prefer immutable digest pinning and protected release/tag workflows. Monitor for unexpected artifact digest changes and failed/suspicious verification events. |
| node-opcua is an OPC UA implementation for TypeScript and Node.js. Prior to 2.166.0, the UserNameIdentityToken authentication handler in packages/node-opcua-server/source/opcua_server.ts decrypts an RSA-OAEP password blob but does not verify that the trailing bytes match the current session serverNonce. An unauthenticated remote attacker can obtain the server public key through GetEndpoints and forge a blob whose little-endian length produces an empty password passed to isValidUser, compromising accounts that accept an empty password. Missing nonce binding also allows a captured UserNameIdentityToken ciphertext to be replayed in another session, and SecurityMode=None removes the separate client-signature safeguard. This issue is fixed in version 2.166.0. |
| python-jose through 3.5.0 fails to properly validate asymmetric keys in HMAC initialization, accepting DER-encoded public keys that lack PEM armor or SSH prefixes. Attackers holding the service's public key can forge HS256 tokens that pass verification when algorithms are not explicitly restricted. This is an incomplete fix for CVE-2024-33663. |
