Overview 464 matches · 27 in Waratek scope · 2 protected · 4 exploited · 2 CISA KEV · 11 public PoC · 0 EPSS ≥ 0.5
464matches
27in Waratek scope5.8%
2protected0.4%
4exploited0.9%
2CISA KEV0.4%
11public PoC2.4%
0EPSS ≥ 0.50.0%
Protected by Waratek
2
0.4%
Rule in development
0
0.0%
Mitigation candidate
2
0.4%
No exploit published
23
5.0%
Outside Waratek scope
2
0.4%
Not applicable
435
93.8%
Withdrawn CVE
0
0.0%
blocked by ARMR today
2
0.4%
partly blocked
0
0.0%
not blocked
462
99.6%
not established
0
0.0%
unrecorded
0
0.0%
split by
peak 208 / year
20022
Not applicable2
High2
not blocked2
No public exploit2
20030
20040
20052
Not applicable2
High2
not blocked2
No public exploit2
20060
20070
20080
20090
20100
20110
20120
20131
Not applicable1
High1
not blocked1
Exploited1
20140
20150
20160
20178
No exploit published1
Not applicable7
High8
not blocked8
No public exploit8
201819
Protected by Waratek2
Not applicable17
High19
blocked by ARMR today2
not blocked17
Working exploit published1
No public exploit18
201917
No exploit published1
Not applicable16
High17
not blocked17
No public exploit17
202041
No exploit published3
Not applicable38
High41
not blocked41
Exploited1
Working exploit published2
No public exploit38
202133
Not applicable33
High33
not blocked33
No public exploit33
202229
No exploit published2
Outside Waratek scope1
Not applicable26
High29
not blocked29
Proof of concept only1
No public exploit28
202338
Outside Waratek scope1
Not applicable37
High38
not blocked38
No public exploit38
202429
Mitigation candidate1
No exploit published1
Not applicable27
High29
not blocked29
Working exploit published1
Proof of concept only4
No public exploit24
202537
Not applicable37
High37
not blocked37
Exploited1
Working exploit published1
Proof of concept only7
No public exploit28
2026208
Mitigation candidate1
No exploit published15
Not applicable192
High208
not blocked208
Exploited1
Proof of concept only38
No public exploit169
2002200420062008201020122014201620182020202220242026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-59074 | High | 2026-11-13 | Not applicable | No public exploit | Edito CMS is vulnerable to improper cryptographic signature verification in the JWT refresh logic. An authenticated low-privilege user can submit self-crafted JWT containing an existing user identifier and, due to the lack of signature validation, obtain a valid, fully-signed session token for any account in the system. This allows the attacker to impersonate any user, including administrators. This issue was fixed in version 5.10.2607. Hotfixes for older versions (5.8) have also been released. |
| CVE-2026-128909 | High | 2026-11-13 | Not applicable | No public exploit | Improper verification of cryptographic signature (CWE-347) in the firmware update handler of the management service (uavmonitor_usbv1) of the 1300 communications board in DJI AeroScope Mobile (TP703) firmware 03.00.00.26, with 1300 communications board firmware 02.00.07.12 through 02.00.08.40, allows an unauthenticated attacker on the local network to install modified firmware, which gives persistent code execution as root. The device accepts any image that matches an MD5 checksum supplied in the same request and does not verify a signature. Exploitation requires network access to TCP port 16000 on the board and that the unit is not connected to another controlling host. Reproduced by running the unmodified device binaries in emulation; not tested on a physical device. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. DJI has discontinued AeroScope Mobile and no fixed firmware is available. |
| CVE-2026-127121 | High | 2026-11-12 | Not applicable | No public exploit | SOGo before 5.12.13 contains an improper cryptographic signature verification vulnerability that allows remote attackers to replace a victim's contact S/MIME certificate by sending a spoofed multipart/signed message with a mismatched signature and an impersonated From address. Attackers can deliver a crafted CMS signedData object containing their own self-signed certificate, which SOGo's UIxMailView stores on the contact card without validating signature authenticity or certificate identity, enabling subsequent encrypted communications to be decrypted with the attacker's private key. |
| CVE-2026-64855 | High | 2026-11-11 | Not applicable | No public exploit | soapbar is a SOAP library for Python — client, server, and WSDL handling. Prior to version 0.13.0, verify_envelope_bsp() derived its trust anchor from the message it was verifying. It read the X.509 certificate out of the caller-untrusted wsse:BinarySecurityToken, validated only that certificate's not-before / not-after dates, and then verified the signature against that same certificate. There was no CA-chain validation, no issuer/subject allowlist, and no pinning. A successful verify_envelope_bsp() therefore proved only that the envelope was signed by whoever supplied the embedded certificate — never that it was signed by a trusted party. An attacker who mints their own certificate, signs a forged envelope, and embeds that certificate in the token passes verification. Any consumer that treats a successful BSP verification as authentication can be impersonated (signature forgery / authentication bypass). verify_envelope() (which pins a caller-supplied x509_cert) was not affected — the flaw was specific to the BSP variant whose trust anchor came from the message. This issue has been patched in version 0.13.0. |
| CVE-2026-70003 | High | 2026-11-10 | Not applicable | No public exploit | Improper verification of cryptographic signature in JDBC Driver for SQL Server allows an unauthorized attacker to bypass a security feature over a network. |
| CVE-2026-4762 | High | 2026-11-10 | No exploit published | No public exploit | A vulnerability to perform a privilege escalation attack on the server as a non-admin user. |
| CVE-2026-118737 | High | 2026-11-10 | Not applicable | No public exploit | Improper verification of cryptographic signature in Windows Remote Procedure Call Runtime allows an unauthorized attacker to execute code over a network. |
| CVE-2026-109799 | High | 2026-11-10 | Not applicable | No public exploit | The SAP Cloud SDK for Python contains an improper cryptographic signature verification vulnerability (CWE-347) in IASContextProvider, the runtime-context provider registered by default via bootstrap(app).IASContextProvider extracted the app_tid, sap_gtid and user_uuid claims from the IAS JWT in the Authorization header using an unverified decoder and wrote them into the request-scoped RuntimeContext without validating the token signature. A remote caller could submit a self-signed JWT naming a victim tenant/user; the forged identity then propagated to every consumer of the runtime context:OTel span attributes (sap.tenancy.tenant_id, user.id) via RuntimeContextSpanProcessorlog records via IdentityLogFilteraudit events (tenant_id, user_initiator_id) via AuditClienttenant routing via CBCClientThis completes an earlier remediation that fixed the same unverified pattern in StarletteIASTelemetryMiddleware but did not cover IASContextProvider. |
| CVE-2025-0008 | High | 2026-11-10 | Not applicable | No public exploit | Insufficient verification of data authenticity may allow a local attacker to bypass Secure Debug Unlock (SDU), potentially resulting in unauthorized debug access. |
| CVE-2026-123798 | High | 2026-11-09 | Not applicable | No public exploit | SuperTokens Core is an open source authentication server. From 11.3.0 until 11.3.7, 11.4.7, and 12.0.10, SAML.verifySamlResponseSignature calls OpenSAML SignatureValidator.validate without first applying SAMLSignatureProfileValidator. The Core can therefore accept a cryptographically valid signature that references a different XML element from the Response or Assertion whose NameID and attributes are used for authentication. An ordinary user of the configured identity provider can move a genuinely signed element elsewhere in the document while supplying an attacker-authored identity-bearing element, causing XML Signature Wrapping authentication as another IdP user. Both response-level and assertion-level signing paths are affected, and SP-initiated login remains reachable without enabling allowIDPInitiatedLogin. This issue is fixed in versions 11.3.7, 11.4.7, and 12.0.10. |
| CVE-2026-123605 | High | 2026-11-08 | Not applicable | No public exploit | Hickory DNS hickory-proto 0.1 through 0.25.0-alpha.3 and hickory-net before 0.26.2 contain a DNSSEC validation bypass because the validator verifies an RRSIG against the DNSKEY of whatever name appears in its Signer's Name field without checking that this name is the zone containing the RRset. Attackers controlling any secure zone can produce valid signatures over arbitrary records in unrelated zones, which resolvers, recursors, and clients using DnssecDnsHandle accept as authenticated. |
| CVE-2026-123538 | High | 2026-11-08 | Not applicable | No public exploit | OpenAM before 16.1.4 does not verify that a signed SAML 1.x assertion or response was signed by the partner named as its issuer, accepting a signature from any certificate in OpenAM's keystore. An attacker holding such a private key, such as a trusted SAML 1.x partner, can forge assertions claiming another partner's issuer and sign in as that partner's users, including privileged ones. |
| CVE-2026-17379 | High | 2026-11-07 | Not applicable | No public exploit | IBM API Connect 10.0.8.0 through 10.0.8.12 and 12.1.0.0 through 12.1.1.2 could allow a remote attacker to bypass authentication and assign arbitrary roles due to improper verification of cryptographic signatures. |
| CVE-2026-85708 | High | 2026-11-06 | Not applicable | Proof of concept only | Chartbrew is an open-source web application that can connect directly to databases and APIs and use the data to create charts. Prior to 5.2.3, Chart share and embed tokens were signed with CB_SECRET, including known or shipped-default values in stock source and repository Docker Compose installs. The vulnerable surface is chart share-token verification and filter-access routes for private charts. An attacker who knows the deployment's CB_SECRET targets a private chart that has been shared at least once so a share-policy row exists, then forges a Chart-subject token for that chart id. The known signing key permits valid Chart tokens, and the filter-access path accepts sequential integer ids without requiring a legitimate share link; token expiry and revocation are ineffective once the secret is known. The condition requires a known or default secret and an existing share-policy row. A bare container where CB_SECRET is undefined is outside this path, and a unique secret excludes it only while the value remains unknown and unpredictable. An unauthenticated attacker can enumerate integer ids and read arbitrary private chart data, including chartData, without possessing a legitimate share link. This issue is fixed in version 5.2.3. |
| CVE-2026-93998 | High | 2026-11-05 | No exploit published | No public exploit | A flaw was found in the SAML adapter component of Keycloak, which is used to secure applications with SAML-based authentication. The adapter fails to verify that the issuer of a signed SAML assertion matches the expected identity provider configured for the application. If multiple identity providers share the same trusted signing key, an attacker who controls one of those providers can create a validly signed assertion to log into the application as any user, potentially gaining full administrative control. |
| CVE-2026-122267 | High | 2026-11-05 | Not applicable | No public exploit | MinIO Signature V4 verification before RELEASE.2026-09-22T19-25-18Z accepts unsigned x-amz-* headers, letting a presigned PUT URL be escalated into a cross-bucket read. |
| CVE-2026-91898 | High | 2026-11-02 | Not applicable | No public exploit | 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. |
| CVE-2026-58930 | High | 2026-11-02 | Not applicable | No public exploit | An unprivileged application can exploit a lack of package/signature validation in SystemUI's `RemoteQCController` when resolving a hardcoded `content://` URI. This allows the attacker to squat on a specific authority if the legitimate package is absent, inject spoofed UI elements into the trusted SystemUI Quick Controls panel, and gain a Background Activity Launch (BAL) grant from SystemUI when the user interacts with the spoofed element. |
| CVE-2026-63182 | High | 2026-10-30 | Not applicable | Proof of concept only | 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. |
| CVE-2026-46560 | High | 2026-10-30 | No exploit published | No public exploit | 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. |
| CVE-2026-119561 | High | 2026-10-30 | Not applicable | No public exploit | phpMyAdmin through 5.2.3 contains an authentication bypass vulnerability in CustomServer::parseAndValidateAssertionResponse() that never verifies WebAuthn assertion signatures against stored public keys. Attackers holding a victim's MySQL credentials can POST a crafted webauthn_request_response with matching challenge, origin, and rpIdHash to bypass the second factor and gain database privileges. |
| CVE-2026-119037 | High | 2026-10-30 | Not applicable | No public exploit | Business::GoCardless versions before 1.01 for Perl accept forged webhooks when a configured webhook secret is undef or empty. signature_valid uses each configured secret as the HMAC key, and nothing rejects undef or an empty string, both of which Digest::SHA treats as an empty key. A secret read from an unset environment variable, or an empty entry in a list of rotated secrets, is used as is. A remote attacker can sign a forged webhook with an empty key and have it accepted as sent by GoCardless. |
| CVE-2026-33923 | High | 2026-10-29 | Not applicable | No public exploit | A signature verification vulnerability was discovered in the update installation functionality due to inconsistent validation of the update bundle contents. An attacker with administrative privileges can remotely supply a crafted update bundle that passes signature verification but runs an unsigned script when the bundle is installed. The script runs with root privileges, allowing the attacker to read or modify sensitive data, change the appliance configuration, or shut down the appliance. |
| CVE-2026-87103 | High | 2026-10-28 | Not applicable | No public exploit | Sensitive information disclosure and manipulation due to improper token validation. The following products are affected: Acronis Cyber Protect 17 (Linux, Windows) before build 42587. |
| CVE-2026-87102 | High | 2026-10-28 | Not applicable | No public exploit | Sensitive information disclosure and manipulation due to improper token validation. The following products are affected: Acronis Cyber Protect 17 (Linux, Windows) before build 42587. |
| CVE-2026-118040 | High | 2026-10-28 | Not applicable | No public exploit | In Progress® Telerik® Document Processing Libraries prior to version 2026.3.1027, improper verification of cryptographic signatures and improper certificate validation in RadPdfProcessing digital signature validation allow an unauthenticated attacker to cause signature validation to report forged content as unmodified and its signing certificate as valid via a crafted signed PDF document. |
| CVE-2026-117602 | High | 2026-10-27 | Not applicable | No public exploit | Electrum 4.6.0 before 4.7.2 contains an authorization bypass in the external plugin loader, which executes a plugin's __init__.py module when the plugin is marked enabled in the config file, without verifying its plugin-password signature. A rogue local process with write access to the Electrum data directory can place plugin code in the plugins/ folder and mark it enabled, causing arbitrary code execution inside the Electrum process. |
| CVE-2026-116116 | High | 2026-10-26 | Not applicable | Proof of concept only | A vulnerability was detected in Yoosee GM8135S Camera 21.00.01.36. Affected is an unknown function of the component Secure Boot. Performing a manipulation results in improper verification of cryptographic signature. The attack needs to be approached locally. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| CVE-2026-116189 | High | 2026-10-25 | Not applicable | Proof of concept only | rclone from 1.55.0 before 1.75.2 contains a signature verification bypass in stable selfupdate that trusts checksums from unsigned bytes preceding the PGP-clearsigned SHA256SUMS block. Attackers controlling the release distribution path can prepend an unsigned checksum line matching a malicious archive, causing selfupdate to install an attacker-controlled rclone executable. |
| CVE-2026-56837 | High | 2026-10-23 | Not applicable | No public exploit | PraisonAI is a multi-agent teams system. From version 4.6.56 to before version 4.6.59, PraisonAI's LinearBot starts a public webhook listener on 0.0.0.0 and treats LINEAR_WEBHOOK_SECRET as optional. When the secret is absent, startup only logs a warning and _handle_webhook() skips Linear-Signature verification entirely. An unauthenticated network caller who can reach the webhook endpoint can submit a forged Linear-Event: AgentSession request. The forged request is parsed, scheduled for background processing, dispatched to _handle_agent_session(), and passed into BotSessionManager.chat(). The bot then attempts to post the agent response back to Linear under the configured bot token. The PoV is offline and deterministic. It does not contact Linear. It calls the webhook handler directly, monkey-patches the outbound Linear comment path, and proves both sides of the boundary. This issue has been patched in version 4.6.59. |
| CVE-2026-115374 | High | 2026-10-22 | Not applicable | No public exploit | Incus 7.0.0 before 7.0.2 and 7.1.0 before 7.5.0 contains a signature verification flaw in its built-in S3 server that allows presigned URL holders to inject unsigned x-amz-* headers. Attackers can add an unsigned X-Amz-Copy-Source header to a presigned upload URL to copy other bucket objects onto the granted key, disclosing their contents and ETags. |
| CVE-2026-113229 | High | 2026-10-20 | Not applicable | No public exploit | Improper signature verification in Loader in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) |
| CVE-2026-110765 | High | 2026-10-14 | Not applicable | Proof of concept only | FlexPrice through 2.1.38 contains an authentication bypass vulnerability in HandleQuickBooksWebhook that skips signature verification when the intuit-signature header is omitted. Unauthenticated attackers knowing a tenant and environment ID can replay forged payment notifications to repeatedly add payment amounts, marking invoices paid or overpaid. |
| CVE-2026-97799 | High | 2026-10-13 | Not applicable | No public exploit | Improper verification of cryptographic signature in Windows Audio Service allows an authorized attacker to elevate privileges locally. |
| CVE-2026-96957 | High | 2026-10-13 | Not applicable | No public exploit | Improper verification of cryptographic signature in .NET allows an unauthorized attacker to bypass a security feature over a network. |
| CVE-2026-95633 | High | 2026-10-13 | Not applicable | No public exploit | CAI Content Credentials is affected by an Improper Verification of Cryptographic Signature vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploitation of this issue does not require user interaction. |
| CVE-2026-95632 | High | 2026-10-13 | Not applicable | No public exploit | CAI Content Credentials is affected by an Improper Verification of Cryptographic Signature vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploitation of this issue does not require user interaction. |
| CVE-2026-87696 | High | 2026-10-13 | Not applicable | No public exploit | Improper verification of cryptographic signature in Microsoft Exchange Server allows an authorized attacker to elevate privileges over a network. |
| CVE-2026-69650 | High | 2026-10-13 | Not applicable | No public exploit | Improper verification of cryptographic signature in Windows Key Distribution Center allows an authorized attacker to elevate privileges locally. |
| CVE-2026-108971 | High | 2026-10-13 | Not applicable | Proof of concept only | A flaw has been found in D-Link DCS-930L B1.08B4. This impacts the function mpfd_decode of the file bootloader_region.bin of the component Emergency HTTP Recovery Server. Executing a manipulation of the argument firmware can lead to improper verification of cryptographic signature. The attack may be performed from remote. The exploit has been published and may be used. |
| CVE-2026-103297 | High | 2026-10-13 | Not applicable | No public exploit | CAI Content Credentials is affected by an Improper Verification of Cryptographic Signature vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploitation of this issue does not require user interaction. |
| CVE-2026-103296 | High | 2026-10-13 | Not applicable | No public exploit | CAI Content Credentials is affected by an Improper Verification of Cryptographic Signature vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploitation of this issue does not require user interaction. |
| CVE-2026-102866 | High | 2026-10-13 | Not applicable | No public exploit | Improper verification of cryptographic signature in Microsoft Office SharePoint allows an unauthorized attacker to elevate privileges over a network. |
| CVE-2026-85962 | High | 2026-10-12 | Not applicable | No public exploit | Progress MarkLogic Server 12.x releases before 12.1.0 and 11.x releases before 11.3.7 contain an improper authentication vulnerability in SAML processing. In deployments that use SAML authentication, an unauthenticated remote attacker could cause the affected server to accept an assertion that should be rejected, potentially resulting in unauthorized access. |
| CVE-2026-103902 | High | 2026-10-12 | Not applicable | No public exploit | Improper verification of cryptographic signature vulnerability in DigiDoc libdigidocpp, DigiDoc DigiDoc4, DigiDoc DigiDoc Android, and DigiDoc DigiDoc iOS. The vulnerability allows an attacker to create forged digital signatures that are displayed a valid by affected DigiDoc software.This issue affects libdigidocpp: from 4.0.0 before 4.5.0; DigiDoc4: from 4.6.0 before 4.11.0; DigiDoc Android: from 2.7.0 before 3.1.0; DigiDoc iOS: from 2.7.0 before 3.1.0. |
| CVE-2026-108699 | High | 2026-10-11 | Not applicable | Proof of concept only | hyper-mcp through 0.8.3 contains an improper signature verification vulnerability that allows attackers to load malicious WebAssembly plugins because cosign_verify_args() accepts any signer identity and OIDC issuer by default. Attackers controlling a plugin image reference can sign a malicious image with a free Sigstore keyless certificate to execute plugins with configured host, filesystem, and environment capabilities. |
| CVE-2026-106581 | High | 2026-10-09 | Not applicable | No public exploit | Before 4.92.0, Docker Desktop for Windows did not verify the signature of a package supplied to Docker Desktop Installer.exe install -package. An attacker able to provide a crafted package and convince a user to approve the Docker-signed UAC prompt could execute attacker-controlled installer actions as LocalSystem. |
| CVE-2026-84271 | High | 2026-10-08 | Not applicable | No public exploit | IBM Guardium Data Protection 12.2 is vulnerable to a signature verification bypass in the patch installer. An attacker with local access could exploit this vulnerability to execute arbitrary code with root privileges. |
| CVE-2026-14999 | High | 2026-10-08 | Not applicable | No public exploit | IBM DataPower Gateway 10.5.0.0 through 10.5.0.22, 10.6.1 through 10.6.6, 10.6.0.0 through 10.6.0.10, and 11.0.0.0 through 11.0.0.2 could allow a remote attacker to bypass authentication by forging valid JSON Web Signatures due to improper verification of cryptographic signatures. |
| CVE-2026-14497 | High | 2026-10-08 | Not applicable | No public exploit | IBM DataPower Gateway 10.5.0.0 through 10.5.0.22, 10.6.1 through 10.6.6, 10.6.0.0 through 10.6.0.10, and 11.0.0.0 through 11.0.0.2 could allow a remote authenticated attacker to bypass security restrictions due to improper verification of cryptographic signatures. |
| CVE-2026-107724 | High | 2026-10-08 | Not applicable | Proof of concept only | fast-jwt provides fast JSON Web Token (JWT) implementation. In 6.2.4, fast-jwt can classify raw serialized public JWK or JWKS JSON as an HMAC secret because src/crypto.js performDetectPublicKeyAlgorithms treats non-PEM strings as symmetric key material. If HS256 is explicitly allowed or inferred, an attacker who knows the exact serialized public-key bytes can use those bytes as an HMAC key and create a token containing arbitrary claims that createVerifier accepts. Serialization ordering or whitespace differences can prevent exploitation, and applications using supported PEM keys with an asymmetric-only algorithm allowlist are not affected. This issue is fixed in version 6.3.0. |
| CVE-2026-107720 | High | 2026-10-08 | Not applicable | Proof of concept only | fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.3.1, fast-jwt createVerifier accepts an unsigned JWT when key is an empty string or null and algorithms is a non-empty allowlist. Falsy synchronous keys bypass prepareKeyOrSecret, allowedAlgorithms remains active, hasKey is false, and the empty signature avoids the verifySignature gate. An attacker can therefore submit a token containing arbitrary claims without possessing a signing key, resulting in authentication or authorization bypass. Claim validators still run, and non-empty keys, an empty key without algorithms, and the async key resolver path do not have this behavior. This issue is fixed in version 6.3.1. |
| CVE-2026-79807 | High | 2026-10-06 | Not applicable | No public exploit | A missing integrity verification vulnerability in the Windows client software for ClearPass Policy Manager could allow malicious users on a local instance to elevate their user privileges. A successful exploit could allow these users to execute attacker-supplied code with elevated privileges on the local system. |
| CVE-2026-25302 | High | 2026-10-06 | Not applicable | No public exploit | Cryptographic Issue when processing non-ELF partitions, authentication and signature checks are bypassed, allowing unsigned or corrupted images to be mounted and processed. |
| CVE-2026-78860 | High | 2026-10-05 | Not applicable | Proof of concept only | An issue in Mercusys AC12 V2 allows a local attacker to execute arbitrary code via the storage of information in plaintext |
| CVE-2026-77805 | High | 2026-10-05 | Not applicable | No public exploit | In Progress® Telerik® Fiddler® Classic for Windows, versions prior to v6.0.20262.10021, the integrity check applied to the external helper tools launched by the application is insufficient. Before executing a helper tool, the application only verifies that the file carries a valid Authenticode signature whose certificate subject name matches a broad allow list of publisher name fragments, rather than verifying that the file is the specific executable shipped with that version of the product. A local threat actor with low privileges who replaces one of these helper executables with any other validly signed binary from an allow-listed publisher can cause the substituted binary to be executed by the application, including with Administrator privileges for the tools that request elevation, resulting in privilege escalation and execution of unintended code. Successful exploitation requires the user to launch the affected external tool and to approve the elevation prompt without noticing that it refers to a different executable. |
| CVE-2026-71891 | High | 2026-10-03 | No exploit published | No public exploit | In Bouncy Castle for Java before 1.86, BLS12_381BasicScheme.keyValidate, and so BLSPublicKeyParameters and every BasicScheme, MessageAugmentation and ProofOfPossession verify and aggregateVerify that gate on it, accepted a public key built on a foreign ECCurve that merely shares BLS12-381's field characteristic. The prime-order subgroup check trusts a point's own curve to name its cofactor, since ECPoint.satisfiesOrder returns true outright when the curve's cofactor is one, so a point on a curve with a different equation and a cofactor forged to one passed keyValidate despite not being a G1 point at all. In BC's pairing implementation such a point contributes the identity in the target group, so an aggregate signature verified against a set of public keys including it is accepted even though it contains no signature for that key and message pair, admitting a phantom signer. keyValidate now first confirms that the point's curve carries exactly the canonical G1 field, equation, order and cofactor before any subgroup check. The issue is reachable only where an application constructs an ECPoint on an explicit, non-canonical curve and accepts it as an authority-bearing key; the standard 48-byte compressed-point decoder always supplies the canonical curve and was never affected. |
| CVE-2026-71887 | High | 2026-10-03 | No exploit published | No public exploit | In Bouncy Castle for Java before 1.86, the high-level OpenPGP API accepted a data signature made by a signing subkey whose Subkey Binding signature carried no embedded Primary Key Binding (cross-certification) signature, in the case where that binding omits a Key Flags subpacket. RFC 9580 sec. 5.2.1.8 and sec. 10.1.3 require the embedded Primary Key Binding signature on any subkey that can issue signatures; it is the subkey's own statement that it belongs to the primary key it is bound under. OpenPGPCertificate resolved the subkey's key flags two different ways. isSigningKey() goes through getKeyFlags() and getApplyingSubpacket(), which falls back to the primary key's direct-key or primary User ID self-signature when the binding signature omits the subpacket, so the subkey inherited the primary's SIGN_DATA and counted as signing-capable; verifyEmbeddedPrimaryKeyBinding(), which enforces the requirement, reads the binding signature's own hashed subpackets, found no SIGN_DATA there, and returned early as a non-signing key without ever demanding the back signature. The same subkey was therefore signing-capable - so its signatures were attributed to the certificate and OpenPGPSignature.OpenPGPDocumentSignature.isValid() returned true - while being exempt from cross-certification, where GnuPG refuses the identical certificate and message. An attacker needs only the victim's public signing subkey, which is public material: they bind it to their own primary key with a Subkey Binding signature they are able to make, carrying no Key Flags and no embedded Primary Key Binding signature, which they cannot make without the subkey's private key, and a relying party verifying one of the victim's genuinely signed messages against that certificate is told the signature is valid and given the attacker's certificate as its issuer. Because a certificate's User IDs are self-asserted, a verifier that pins on the subkey's fingerprint or key ID while taking the identity from the enclosing certificate reports a real signature under an attacker-chosen identity. This is misattribution of a genuine signature rather than forgery of a new one: no private key is recovered, and the signature must be one the grafted subkey actually made. The low-level PGPSignature / PGPPublicKeyRing API performs no binding checks by design and is unaffected. Key Flags are a statement about the key the carrying signature refers to (RFC 9580 sec. 5.2.3.29), so a subkey no longer inherits them from the certificate-wide signatures of the primary key: a Subkey Binding signature that omits the subpacket now leaves the subkey with no capabilities rather than the primary's, which makes the flags the cross-certification check consults the same flags every other decision consults. Preferences and the other subpackets a direct-key signature carries are inherited as before, and the primary key itself, whose flags legitimately come from its own direct-key or User ID self-signature, is unaffected. |
| CVE-2026-86326 | High | 2026-10-02 | Not applicable | No public exploit | An improper verification of cryptographic signature vulnerability exists in protocol gateways because the device does not properly verify the cryptographic authenticity of firmware images before installation. An attacker with high privileges and access to the firmware update interface could provide a specially crafted or modified firmware image, causing it to be installed on the device. Successful exploitation could allow the attacker to execute unauthorized code, compromise the integrity and availability of the device, and persist malicious modifications across subsequent firmware updates. |
| CVE-2026-63571 | High | 2026-10-02 | Not applicable | No public exploit | Improper verification of cryptographic signature in the attribute certificate path validator (PkixAttrCertPathValidator, also used by PkixAttrCertPathBuilder) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote attacker to have a forged X.509 attribute certificate accepted as valid, and so obtain whatever roles or privileges an application grants on the strength of its attributes, via an attribute certificate that names a trusted attribute authority as its issuer but was not signed by it, because the RFC 3281 validation steps check the holder and issuer certification paths, validity period, extensions and revocation status but never verify the attribute certificate's signature with the issuer's public key. Only applications that use these classes to validate attribute certificates are affected. |
| CVE-2026-104437 | High | 2026-10-02 | Not applicable | Proof of concept only | Zebra before 4.4.0 contains a consensus divergence vulnerability in V5 transparent signature verification, computing a ZIP-244 digest for SIGHASH_SINGLE inputs lacking corresponding outputs instead of failing. Attackers can craft V5 transactions with fewer outputs than inputs that Zebra accepts and templates via getblocktemplate, producing blocks zcashd rejects. |
| CVE-2026-104435 | High | 2026-10-02 | Not applicable | No public exploit | Zebra zebrad 4.4.0 and zebra-script 6.0.0 fail to enforce a ZIP-244 consensus rule, accepting V5 transparent inputs signed with SIGHASH_SINGLE that lack a corresponding output. Attackers can broadcast crafted V5 transactions with more inputs than outputs that Zebra accepts but zcashd rejects, causing a network consensus split. |
| CVE-2026-87004 | High | 2026-09-30 | Not applicable | Proof of concept only | Tugtainer is a self-hosted app for automating updates of Docker containers. Prior to version 1.31.3, when the OIDC login flow completes, backend/modules/auth/providers/auth_oidc_provider.py decodes the id_token returned by the identity provider's token endpoint using jose.jwt.get_unverified_claims() instead of jwt.decode(). This skips signature verification, audience (aud) validation, issuer (iss) validation, and expiry (exp) checking entirely. The extracted claims (email/sub/preferred_username) are then used directly as the user_id for the resulting Tugtainer session. This issue has been patched in version 1.31.3. |
| CVE-2026-47554 | High | 2026-09-30 | Not applicable | No public exploit | 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-91191 | High | 2026-09-29 | Not applicable | No public exploit | 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. |
| CVE-2026-100293 | High | 2026-09-29 | Not applicable | No public exploit | In Anjvision YSSD‑RTMP‑H5 firmware version 3.3.2.4, both the local and cloud update mechanisms apply new firmware without any cryptographic verification, relying only on basic hashing. This design allows an attacker who can reach the update routine to introduce untrusted firmware images that the device will accept as valid. |
| CVE-2026-102273 | High | 2026-09-28 | Not applicable | No public exploit | PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because HMAC key guard only recognizes top-level public JWK forms and misses container representations. This occurs when an application allows HMAC and asymmetric algorithms and passes a public JWK container as the raw key. As a result, public asymmetric key material is accepted as the HMAC secret. Consequently, an attacker who knows the public key can forge a token with arbitrary authenticated claims. This issue is fixed in version 2.14.0. |
| CVE-2026-102272 | High | 2026-09-28 | Not applicable | Proof of concept only | PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.prepare_key in jwt/algorithms.py is affected because raw-JWK detector does not normalize accepted Unicode byte-order marks before checking for JSON. This occurs when a public JWK is prefixed with a UTF-8 BOM and used in a mixed-algorithm verification path. As a result, public JWK bypasses asymmetric-key detection and becomes the HMAC secret. Consequently, an attacker who knows the public key can forge authenticated tokens. This issue is fixed in version 2.14.0. |
| CVE-2026-102271 | High | 2026-09-28 | Not applicable | Proof of concept only | PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because asymmetric-key guard relies on textual markers that are absent from DER encoding. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a DER public key as the shared verification key. As a result, PyJWT uses public DER bytes as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0. |
| CVE-2026-97731 | High | 2026-09-25 | Not applicable | No public exploit | 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. |
| CVE-2026-84465 | High | 2026-09-25 | Not applicable | No public exploit | Zammad is a web based open source helpdesk/customer support system. Prior to 7.1.2, when Zammad checks the digital signature on an incoming S/MIME-signed email, it does not verify that the signing certificate is genuinely trusted, it only checks whether a certificate with a matching name is already stored in the system. An attacker can create their own certificate using the name of a real, previously trusted sender and use it to send a forged email. Zammad will display that email with the same "validly signed" indicator as a genuine message from the real sender, even though the attacker never had access to that sender's actual certificate or private key. This issue is fixed in version 7.1.2. |
| CVE-2026-56727 | High | 2026-09-25 | Not applicable | No public exploit | 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. |
| CVE-2026-57178 | High | 2026-09-24 | Not applicable | No public exploit | Python Social Auth is a social authentication/registration mechanism. Prior to version 5.0.0, the `vk-app` backend accepted VK application callback data without verifying the callback signature when the `auth_key` parameter was omitted. Applications using this backend could treat unsigned attacker-controlled data as a verified VK identity. An attacker could choose callback fields such as `viewer_id`, `access_token`, `api_id`, and `api_result`, potentially allowing authentication as an arbitrary VK user ID. The issue affects only applications using the `vk-app` backend. The issue has been fixed in version 5.0.0 by requiring `auth_key` to be present and valid before callback data is trusted. |
| CVE-2026-85995 | High | 2026-09-22 | Not applicable | No public exploit | 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. |
| CVE-2026-18152 | High | 2026-09-22 | Not applicable | No public exploit | 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. |
| CVE-2026-94368 | High | 2026-09-21 | Not applicable | No public exploit | 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. |
| CVE-2026-75939 | High | 2026-09-21 | Not applicable | No public exploit | 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. |
| CVE-2026-93657 | High | 2026-09-18 | Not applicable | No public exploit | 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. |
| CVE-2026-86038 | High | 2026-09-17 | Not applicable | Proof of concept only | libp2p is a JavaScript implementation of the libp2p networking stack. From 15.0.0 until 16.0.5, @libp2p/gossipsub uses the default StrictSign policy in packages/gossipsub/src/utils/buildRawMessage.ts, where validateToRawMessage verifies a signature with attacker-controlled msg.key but skips binding that key to msg.from when the claimed author is an RSA peer ID that does not inline a public key. An unauthenticated attacker can place a victim RSA peer ID in msg.from, sign the message with the attacker's private key, and supply the attacker's public key in msg.key, causing the message to be accepted and propagated as authored by the victim. Applications that trust message.from for validators, authorization, accounting, moderation, reputation, or audit logging can process attacker-controlled data under false origin attribution. The issue is fixed in version 16.0.5. |
| CVE-2026-54581 | High | 2026-09-17 | Not applicable | No public exploit | mport is the MidnightBSD Package Manager. Prior to 2.7.8, the mport_fetch_bootstrap_index() function in libmport/fetch.c could return success when bootstrap index hash verification encountered a missing or invalid hash because the failure path did not preserve a fatal result. A network attacker or compromised mirror able to alter bootstrap index content or its transport path could therefore cause mport to proceed with an unverified or tampered bootstrap package index. This issue is fixed in version 2.7.8. |
| CVE-2026-92718 | High | 2026-09-16 | Not applicable | Proof of concept only | 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. |
| CVE-2026-86585 | High | 2026-09-16 | Not applicable | No public exploit | 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. |
| CVE-2026-86109 | High | 2026-09-16 | Not applicable | No public exploit | 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. |
| CVE-2026-42784 | High | 2026-09-16 | Not applicable | No public exploit | 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. |
| CVE-2026-58200 | High | 2026-09-15 | Not applicable | No public exploit | 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. |
| CVE-2026-57122 | High | 2026-09-14 | Not applicable | No public exploit | 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. |
| CVE-2026-54155 | High | 2026-09-14 | Not applicable | No public exploit | 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. |
| CVE-2026-80469 | High | 2026-09-11 | Not applicable | No public exploit | An attacker may achieve arbitrary code execution on a target system by uploading a malicious device driver package, bypassing driver verification mechanisms, and triggering the execution of attacker-controlled code. User interaction is required. |
| CVE-2026-73784 | High | 2026-09-11 | Not applicable | No public exploit | A potential security vulnerability in HPE IceWall products could be exploited to tamper SAML response, allowing an attacker to impersonate another user. |
| CVE-2023-54355 | High | 2026-09-09 | Not applicable | No public exploit | PocketMine-MP versions before 5.3.1 and 4.23.1 fail to validate that the identityPublicKey in LoginPacket uses the required secp384r1 elliptic curve. Attackers can provide LoginPackets with keys using different curves or non-EC key types to pass login verification but trigger an uncaught exception during ECDH key derivation, crashing the server. |
| CVE-2026-77105 | High | 2026-09-08 | Not applicable | No public exploit | CommServe contained a cryptographic signature verification issue affecting privilege management. Software customers upgrade to resolved maintenance release. Update CommServe and Web Server. |
| CVE-2026-69646 | High | 2026-09-08 | Not applicable | No public exploit | Improper verification of cryptographic signature in Skype for Business allows an unauthorized attacker to perform spoofing over an adjacent network. |
| CVE-2026-57098 | High | 2026-09-08 | Not applicable | No public exploit | Improper verification of cryptographic signature in Windows RDP Client allows an unauthorized attacker to disclose information over a network. |
| CVE-2026-28590 | High | 2026-09-08 | Not applicable | No public exploit | 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. |
| CVE-2026-14296 | High | 2026-09-07 | Not applicable | No public exploit | When using the Direct XIP update strategy, the main application image starts other cores (i.e. radio core), based on the currently active slot without additional verification. The MCUboot in the bare (upstream) configuration assumes that if there is at least a single slot for each image available, the system is bootable and continues the boot process. This may lead to a situation when MCUboot picks different slot for different images (i.e. (a) for the main application and (b) for the radio image), boots the main application (from slot (a)) that afterwards starts the radio image by providing an address of the unauthenticated slot ((a) instead of (b)). |
| CVE-2026-52767 | High | 2026-09-05 | Not applicable | Proof of concept only | YesWiki is a wiki system written in PHP. From version 4.6.2 to before version 4.6.6, HttpSignatureService::verifySignature() checks the result of PHP's openssl_verify() with a loose boolean negation - if (!openssl_verify(...)) { throw ... }. PHP's openssl_verify has four possible return values: 1, 0, -1, and "false". The -1 row is the bypass: PHP's truthiness rules make -1 a truthy value, so !(-1) === false, the throw is skipped, and the controller proceeds to processActivity(). Any condition that makes OpenSSL's EVP_VerifyFinal() return -1 triggers the bypass. The reachable consequence is the controller silently treats a failed verification as success and processes the attacker's payload. This issue has been patched in version 4.6.6. |
| CVE-2026-85525 | High | 2026-09-04 | No exploit published | No public exploit | 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. |
| CVE-2026-79389 | High | 2026-09-04 | Not applicable | No public exploit | Trueview T18161 S 6.0.23.4 contains an improper verification in MQTT command processing. An attacker with network access can replay or modify captured MQTT messages, including security-related nonce, timestamp, and signature fields, and the device accepts the modified messages and executes the associated commands. |
| CVE-2026-85393 | High | 2026-09-03 | Not applicable | Proof of concept only | node-forge through 1.4.0 fails to validate element count in nested DigestAlgorithm sequences during RSA PKCS#1 v1.5 signature verification. Attackers can embed garbage bytes inside the DigestAlgorithm sequence to forge valid signatures for arbitrary messages using low-exponent RSA keys. This is an incomplete fix for CVE-2026-33894. |
| CVE-2026-80465 | High | 2026-09-03 | Not applicable | No public exploit | A vulnerability has been identified in Mendix SAML (Mendix 10 compatible) (All versions < V4.2.4), Mendix SAML (Mendix 11 compatible) (All versions < V4.2.4), Mendix SAML (Mendix 9.24 compatible) (All versions < V3.6.29). Affected versions of the module do not properly validate the SAML response signature. This could allow unauthenticated remote attackers to hijack an account (session) in specific SSO configurations. |