Overview 1,019 matches · 63 in Waratek scope · 4 protected · 19 exploited · 7 CISA KEV · 22 public PoC · 5 EPSS ≥ 0.5
1,019matches
63in Waratek scope6.2%
4protected0.4%
19exploited1.9%
7CISA KEV0.7%
22public PoC2.2%
5EPSS ≥ 0.50.5%
Protected by Waratek
4
0.4%
Rule in development
0
0.0%
Mitigation candidate
4
0.4%
No exploit published
55
5.4%
Outside Waratek scope
11
1.1%
Not applicable
945
92.7%
Withdrawn CVE
0
0.0%
blocked by ARMR today
4
0.4%
partly blocked
0
0.0%
not blocked
1,014
99.5%
not established
1
0.1%
unrecorded
0
0.0%
split by
peak 442 / year
20022
Not applicable2
High2
not blocked2
No public exploit2
20030
20040
20052
Not applicable2
High2
not blocked2
No public exploit2
20061
Not applicable1
Critical1
not blocked1
No public exploit1
20070
20080
20090
20100
20110
20121
Not applicable1
Medium1
not blocked1
No public exploit1
20131
Not applicable1
High1
not blocked1
Exploited1
20142
Protected by Waratek1
Not applicable1
Medium2
blocked by ARMR today1
not blocked1
No public exploit2
20150
20160
201717
No exploit published1
Outside Waratek scope2
Not applicable14
Critical1
High8
Medium8
not blocked17
Working exploit published1
No public exploit16
201842
Protected by Waratek2
No exploit published1
Outside Waratek scope1
Not applicable38
Critical6
High19
Medium16
Low1
blocked by ARMR today2
not blocked40
Exploited2
Working exploit published1
No public exploit39
201949
No exploit published2
Outside Waratek scope1
Not applicable46
Critical6
High17
Medium25
Low1
not blocked49
Forecast only1
No public exploit48
202073
No exploit published3
Outside Waratek scope2
Not applicable68
Critical9
High41
Medium22
Low1
not blocked73
Exploited2
Working exploit published2
Proof of concept only1
No public exploit68
202171
No exploit published3
Not applicable68
Critical18
High33
Medium20
not blocked71
Forecast only1
No public exploit70
202258
No exploit published4
Outside Waratek scope1
Not applicable53
Critical10
High29
Medium19
not blocked58
Proof of concept only6
No public exploit52
202374
No exploit published1
Outside Waratek scope1
Not applicable72
Critical10
High38
Medium26
not blocked74
Exploited1
Proof of concept only7
No public exploit66
202487
Protected by Waratek1
Mitigation candidate1
No exploit published5
Outside Waratek scope1
Not applicable79
Critical26
High29
Medium29
Low3
blocked by ARMR today1
not blocked86
Exploited1
Working exploit published3
Proof of concept only15
No public exploit68
202597
No exploit published3
Outside Waratek scope2
Not applicable92
Critical27
High37
Medium28
Low5
not blocked97
Exploited5
Working exploit published2
Proof of concept only17
Forecast only1
No public exploit72
2026442
Mitigation candidate3
No exploit published32
Not applicable407
Critical106
High208
Medium99
Low29
not blocked441
not established1
Exploited7
Working exploit published1
Proof of concept only83
No public exploit351
2002200420062008201020122014201620182020202220242026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-75491 | Critical | 2026-11-13 | Not applicable | No public exploit | Cudy TR3000 before 2.5.42 contains an authentication bypass vulnerability in the Mosquitto plugin auth_plugin_jwt.so that accepts unsigned JWTs using alg none. Attackers holding any Cudy-trusted client certificate can authenticate as admincudydevice on port 8883 and publish batchcmd requests to execute commands as root. |
| 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-126952 | Critical | 2026-11-13 | Not applicable | Proof of concept only | Zipline through 4.4.0 contains an authentication bypass vulnerability in the WebAuthn login endpoint that creates sessions for a supplied registered credential ID without verifying the assertion. Attackers who obtain a target's passkey credential ID can impersonate that account without its authenticator, potentially gaining administrative control over SUPERADMIN accounts. |
| CVE-2026-116423 | Medium | 2026-11-13 | Not applicable | No public exploit | Dell PowerScale InsightIQ, versions 6.3.0 through 6.4.0, contains an Improper Verification of Cryptographic Signature vulnerability. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to Elevation of privileges and Information tampering. |
| 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-0460 | Low | 2026-11-12 | Not applicable | No public exploit | Improper authentication in Bootgen could result in the use of a fixed salt value for RSA padding instead of a randomly generated salt, potentially impacting data integrity. |
| 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-125335 | Low | 2026-11-10 | Not applicable | No public exploit | Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.3, ed25519.verify() decodes a public key in crypto_sign_open() without rejecting small-order points or their non-canonical encodings. With S = 0 and a small-order R value, an attacker who can choose the public key can produce signatures that verify for many messages, or all messages with the identity key, without a private key. This can defeat proof-of-possession, attribution, non-repudiation, or deduplication checks that rely on a signature being bound to the message. Keys produced by normal Ed25519 key generation are not small-order, so applications that verify only trusted or internally generated public keys are not affected. This issue is fixed in version 1.4.3. |
| CVE-2026-125298 | Critical | 2026-11-10 | Not applicable | No public exploit | AsiaInfo Business Support System (BSS) 9.2.0 through 9.2.40 does not correctly verify cryptographic signatures for JSON Web Tokens (JWT). A remote, unauthenticated attacker could forge a well-formed JWT without a valid signature and use it to execute privileged actions. Fixed in 9.2.41. |
| CVE-2026-123262 | Medium | 2026-11-10 | 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. Exploit depends on conditions beyond the attacker's control. Exploitation of this issue does not require user interaction. |
| CVE-2026-123261 | Medium | 2026-11-10 | 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. Exploit depends on conditions beyond the attacker's control. Exploitation of this issue does not require user interaction. |
| CVE-2026-122100 | Medium | 2026-11-10 | 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 requires user interaction in that a victim must visit a maliciously crafted URL or interact with a compromised web page. |
| CVE-2026-120017 | Critical | 2026-11-10 | Not applicable | No public exploit | SAP NetWeaver AS ABAP and ABAP Platform does not perform sufficient verification of incoming authentication assertions under certain configurations. An unauthenticated attacker could submit specially crafted data to bypass authentication and impersonate arbitrary users, including privileged accounts. Successful exploitation could cause a full system compromise, with the impact potentially extending to connected components and systems beyond the affected system. This results in a high impact on confidentiality, integrity, and availability of the application. |
| CVE-2026-119867 | Medium | 2026-11-10 | Not applicable | No public exploit | Improper verification of cryptographic signature in Windows Installer allows an unauthorized attacker to bypass a security feature over a network. |
| 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-123590 | Medium | 2026-11-08 | Not applicable | No public exploit | Hickory DNS hickory-net 0.26.0-beta.1 before 0.26.2 and hickory-proto through 0.26.0-alpha.1 accept NSEC and NSEC3 records for DNSSEC nonexistence proofs when any other record with the same owner name passes signature validation. Attackers able to supply DNS responses can mix validly signed records with bogus same-name NSEC or NSEC3 records of different types in the authority section to forge nonexistence proofs. |
| 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-17301 | Critical | 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 an unauthenticated attacker to bypass authentication due to improper verification of a cryptographic signature. |
| CVE-2026-105459 | Medium | 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 an attacker to gain unauthorized access to an organization due to improper verification of a cryptographic signature. A token is accepted without its signature being fully verified, which could allow an attacker to join an organization without a valid invitation. |
| 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-58490 | Critical | 2026-11-06 | Not applicable | No public exploit | Tracecat is an open-source security automation platform for teams and AI agents. From version 0.37.0 until 1.0.0-beta.49, Docker Compose deployments with SAML enabled can render SAML_SIGNED_ASSERTIONS and SAML_SIGNED_RESPONSES as empty values, overriding secure application defaults and disabling both signature requirements. An unauthenticated attacker who can reach the SAML assertion consumer endpoint can submit a forged unsigned response for an existing Tracecat user email address and obtain that user’s session. Targeting an existing superadmin can result in superadmin account takeover. Exploitation does not create users when SAML user creation is disabled and does not affect default Fargate or Helm deployments. Version 1.0.0-beta.49 removes the insecure deployment pass-through and requires signed assertions and responses. |
| 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-117691 | Critical | 2026-11-05 | No exploit published | No public exploit | A flaw was found in the SAML HTTP-Redirect binding implementation of Keycloak. The issue occurs because the server processes percent-encoded parameter names (like %53AMLResponse) while the signature verification logic only checks literal parameter names. An attacker can use this discrepancy to provide a crafted, unsigned SAML message that the server processes instead of a legitimately signed one, leading to full account takeover of federated users. |
| CVE-2026-116790 | Critical | 2026-11-05 | Not applicable | No public exploit | FreeSWITCH is a Software Defined Telecom Stack enabling the digital transformation from proprietary telecom switches to a software implementation that runs on any commodity hardware. Prior to 1.11.2, FreeSWITCH's inbound ICE handling accepted every connectivity check without cryptographically validating its STUN MESSAGE-INTEGRITY attribute. A network peer able to reach an ICE-enabled leg's media port could forge an ICE connectivity check without SDP credentials, nominate its own address, redirect RTP and DTLS traffic, and terminate the legitimate media path. On unencrypted legs this enables eavesdropping and media injection, while all WebRTC and SIP legs that negotiate ICE are in scope. Version 1.11.2 introduces the remediation, which requires ice_verify_message_integrity=true. |
| CVE-2026-111062 | Low | 2026-11-05 | Not applicable | Proof of concept only | russh is a Rust SSH client and server library. From version 0.34.0-beta.1 until version 0.64.0, its SSH server does not require the signature algorithm in a public-key authentication signature to match the algorithm named in the authentication request. A client possessing an authorized RSA private key can announce rsa-sha2-512 while supplying a valid ssh-rsa SHA-1 signature, bypassing restrictions or producing misleading audit records when applications rely on the requested algorithm. A valid private-key signature remains required, and russh clients are not affected. This issue is fixed in version 0.64.0. |
| CVE-2026-121970 | Medium | 2026-11-04 | Not applicable | No public exploit | Pay with Vipps and MobilePay for WooCommerce (woo-vipps) before 6.4.1 contains an improper cryptographic signature verification vulnerability in the recurring-payment webhook handler that allows unauthenticated attackers to forge webhook requests when no local webhook secret is stored, because the code fails to return on an empty secret and computes an HMAC keyed with an empty string using a loose == comparison instead of hash_equals. Attackers can craft a recurring.agreement-stopped.v1 event with a known agreementId and a matching empty-key signature to cancel a victim's active WooCommerce subscription. |
| CVE-2026-121606 | Critical | 2026-11-04 | Not applicable | Proof of concept only | A vulnerability has been found in Qihoo 360 D621-2, D603-2, D600-2, D619, D606-6 and D706 up to 6.4.9. Affected by this issue is the function verify_sign of the file fs2/bin/iscm of the component Firmware Signature Verification. Such manipulation of the argument sign leads to improper verification of cryptographic signature. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| CVE-2026-110021 | Medium | 2026-11-04 | Not applicable | No public exploit | 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. |
| CVE-2026-102894 | Critical | 2026-11-04 | Not applicable | No public exploit | 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. |
| CVE-2026-91908 | Medium | 2026-11-02 | Not applicable | No public exploit | 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. |
| CVE-2026-91905 | Medium | 2026-11-02 | Not applicable | No public exploit | 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. |
| CVE-2026-91899 | Medium | 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. A high privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of Privilege and Arbitrary Code Execution. |
| 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-120459 | Critical | 2026-11-02 | Not applicable | No public exploit | python-jose through 3.5.0 contains an authentication bypass vulnerability that allows unauthenticated attackers to forge JWTs because HMACKey and CryptographyHMACKey accept zero-length HMAC secrets. When an application's HS256/HS384/HS512 verification key resolves to empty, such as an oct JWK with empty k, attackers can forge tokens with arbitrary claims that jwt.decode accepts. |
| CVE-2026-117549 | Medium | 2026-11-02 | Not applicable | No public exploit | @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. |
| CVE-2026-116474 | Medium | 2026-11-01 | Not applicable | No public exploit | 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. |
| 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-118559 | Medium | 2026-10-30 | Not applicable | No public exploit | 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. |
| CVE-2026-88078 | Medium | 2026-10-29 | Not applicable | No public exploit | Improper verification of cryptographic signature in Microsoft Edge (Chromium-based) allows an unauthorized attacker to perform spoofing over a network. |
| 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-118774 | Medium | 2026-10-29 | Not applicable | No public exploit | Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used certificate.verify(child), _verifySignature(), lib/x509.js to process the relevant input or security decision. node-forge selected RSA padding and RSASSA-PSS parameters from the issuer certificate rather than the child certificate being verified. A child labeled as RSASSA-PSS could therefore be accepted with a PKCS#1 v1.5 signature when the issuer used PKCS#1 v1.5. The signature still had to be produced with the trusted issuer's private key, so this did not permit certificate identity forgery, but it could bypass policies that require a declared signature scheme. This issue is fixed in version 1.4.1. |
| CVE-2026-118768 | Medium | 2026-10-29 | Not applicable | No public exploit | Botan is a C++ cryptography library. From 1.11.34 until 3.13.0, the botan ocsp_check command requested an OCSP response from a certificate's Authority Information Access URL without verifying the response signature or authorizing the signer. A malicious responder or on-path attacker could return a matching and timely GOOD response with an empty, invalid, or unauthorized signature, causing a revoked certificate to produce exit status 0 and OCSP check OK output. Only the command-line interface is affected. This issue is fixed in version 3.13.0. |
| CVE-2026-87879 | Medium | 2026-10-28 | Not applicable | No public exploit | Sensitive information disclosure due to improper token validation. The following products are affected: Acronis Cyber Protect 17 (Linux, Windows) before build 42587. |
| 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-87101 | Medium | 2026-10-28 | Not applicable | No public exploit | Sensitive information disclosure 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-110985 | Critical | 2026-10-28 | No exploit published | No public exploit | A Kafka broker using SASL/OAUTHBEARER with the default validator (sasl.oauthbearer.jwt.validator.class=DefaultJwtValidator) selects its implementation from configuration. When sasl.oauthbearer.jwks.endpoint.url is set, the validator verifies the JWT signature. When that URL is unset (the default) and no verification key resolver is supplied, DefaultJwtValidator silently falls back to ClientJwtValidator, which does not verify the JWT signature, algorithm, or issuer - and the broker starts with no warning or error. This is the residual of CVE-2026-33557, whose fix restored signature verification only on the path where the JWKS endpoint URL is set. Impact: A broker in this state accepts any structurally valid JWT, including "alg":"none" tokens. An unauthenticated remote attacker who can reach the listener can forge a token asserting any principal - including configured superusers - and gain full access to the cluster. Only brokers that enable SASL/OAUTHBEARER validation without a JWKS endpoint URL (and without a custom verification key resolver) are affected; brokers that set the URL verify signatures and are not affected. Unlike CVE-2026-110952 (issuer/audience not enforced by default), here no signature is verified at all. Mitigation (all affected versions, no upgrade required): Set sasl.oauthbearer.jwks.endpoint.url for every listener/mechanism that uses OAuthBearerValidatorCallbackHandler, or configure a signature-verifying sasl.oauthbearer.jwt.validator.class. Resolution: From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: a broker that would fall back to the non-verifying ClientJwtValidator fails to start with a ConfigException instead of running without signature verification (secure by default). |
| 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-117601 | Critical | 2026-10-27 | Not applicable | Exploited | Electrum before 4.8.3 fails to verify signatures of wallet-owned inputs in unconfirmed mempool transactions, allowing malicious servers to replace a just-broadcast transaction with a conflicting one. Attackers can swallow the user's transaction and display an invalid zero-fee copy paying an attacker address, tricking users into RBF fee-bumping and signing it. |
| CVE-2026-106078 | Medium | 2026-10-27 | Not applicable | No public exploit | A vulnerability allowing an unauthenticated attacker to bypass REST API authentication with a forged federation token and receive responses from REST API endpoints that do not call the Veeam Backup for Microsoft 365 backup service. |
| CVE-2026-103325 | Low | 2026-10-27 | Not applicable | No public exploit | The TiendaCrypto para WooCommerce WordPress plugin through 1.2.1 does not correctly verify the authenticity of its payment webhook, validating the request signature against a key that is always empty, which allows unauthenticated attackers to forge webhook notifications and mark arbitrary WooCommerce orders as paid on web servers that preserve request header case. |
| CVE-2026-65632 | Medium | 2026-10-26 | Not applicable | Proof of concept only | The jose library accepts ECDSA (ES256, ES256K, ES384, and ES512) JWS signatures of a non-canonical length. When verifying an ECDSA signature, jose_jwk_kty_ec:verify/4 in src/jwk/jose_jwk_kty_ec.erl splits the raw signature in half by its actual byte length (split_binary(Signature, byte_size(Signature) div 2)) instead of enforcing the fixed length required by RFC 7518 §3.4, and then decodes each half with crypto:bytes_to_integer/1, which ignores leading zero bytes. As a result, an attacker who holds one valid token can prepend leading zero bytes to each of the R and S halves to produce longer signatures that still split evenly and decode to the same (r, s) pair, so many distinct signature byte strings all verify against the same key (signature malleability). This does not allow forging new payloads or impersonating a signer, because the underlying (r, s) values are unchanged. It does defeat any security control that assumes a valid token or its signature is unique, such as token-revocation-by-hash, replay or idempotency caches, and deduplication logic. This issue affects jose: from 1.0.0 before 1.11.13. |
| 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-112518 | Medium | 2026-10-26 | Not applicable | No public exploit | An issue with signature validation was addressed with improved checks. This issue is fixed in iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, tvOS 27.2, visionOS 27.2, watchOS 27.2. An attacker in a privileged network position may be able to impersonate a Kerberos KDC. |
| 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-89317 | Medium | 2026-10-23 | Not applicable | Proof of concept only | gose parsed the JWS `crit` header into `JwsHeader.Crit` and then never read it. RFC 7515 §4.1.11 requires a recipient to reject a JWS whose listed critical extension parameters it does not understand. gose implements no header extensions, so every token carrying a non-empty `crit` should have been rejected — and none were. |
| 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-87947 | Medium | 2026-10-22 | Not applicable | No public exploit | Improper Verification of Cryptographic Signature vulnerability in Drupal SAML SSO - Service Provider allows Signature Spoof. This issue affects SAML SSO - Service Provider versions: from 0.0.0 to 3.2.0. |
| CVE-2026-84918 | Low | 2026-10-22 | Not applicable | No public exploit | Improper Verification of Cryptographic Signature vulnerability in Drupal Monobank payment API allows Signature Spoof. This issue affects Monobank payment API versions: from 0.0.0 to 1.0.3. |
| 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-114615 | Critical | 2026-10-22 | Not applicable | Proof of concept only | Authlib is a Python library which builds OAuth and OpenID Connect servers. From 1.3.1 until 1.9.0, OctKey.import_key() checks asymmetric-key markers only at byte zero while Authlib's PEM loaders accept leading whitespace, comments, or a byte-order mark. In deployments that use the documented mixed algorithm registry and already configure verification with PEM or certificate bytes containing such a prefix, an unauthenticated attacker who knows those same public-key bytes can use them as an HMAC secret and forge HS256 tokens with arbitrary identity or authorization claims. This is a bypass of the remediation for CVE-2024-37568. The module-level jwt object reaches OctKey.import_key() in authlib/jose/rfc7518/oct_key.py, where POSSIBLE_UNSAFE_KEYS fails to identify prefixed asymmetric key material. This issue is fixed in version 1.9.0. |
| CVE-2026-105869 | Critical | 2026-10-21 | Not applicable | No public exploit | Apache Pulsar's MultiRolesTokenAuthorizationProvider authorizes a client with all roles listed in a claim of its JSON Web Token (JWT). The provider is intended for use with token authentication, which verifies the token before authorization. The provider did not verify the token itself: it parsed the token's claims with the signature removed and trusted that authentication had already checked it. When authentication and authorization are enabled with a non-empty anonymousUserRole setting, some HTTP requests whose credentials fail authentication are not rejected, but are handled as requests of the anonymous user role. For the broker's HTTP endpoints, such as the admin REST API, this fallback applies to requests that do not name an authentication method and requires strictAuthMethod to be false (the default) where that setting is available. For the WebSocket API, failed credentials can also fall back to the anonymous user role; this path does not enforce strictAuthMethod. The authentication data kept for such a request still contained the request's Authorization header. MultiRolesTokenAuthorizationProvider then read the bearer token from that header without verifying its signature and authorized the request with the roles in the token's role claim. As a result, in deployments that use MultiRolesTokenAuthorizationProvider together with a non-empty anonymousUserRole and that permit this fallback, an unauthenticated client can send an HTTP request, for example to the admin REST API or the WebSocket API, with a forged or unsigned token that lists arbitrary roles, and be authorized with those roles. The impact can include super-user access when the token lists a role configured in superUserRoles, allowing the client to read and change tenants, namespaces, topics, permissions and broker configuration. No valid credentials are required. Deployments are not affected if they use the default authorization provider (PulsarAuthorizationProvider) or another authorization provider, or if anonymousUserRole is not set (the default). Requests that authenticate successfully with a valid token are not affected, because the token that MultiRolesTokenAuthorizationProvider reads is the token that authentication verified. Connections that use the Pulsar binary protocol are not affected by this issue, because the broker does not keep client authentication data for connections that it assigns to the anonymous user role. In fixed versions, MultiRolesTokenAuthorizationProvider obtains roles only from tokens that the configured token authentication provider has verified, using its configured keys and validation settings. Broker HTTP requests that are assigned to the anonymous user role are authorized only as that role, and invalid tokens cannot supply additional roles to WebSocket requests. The broker fails to start if MultiRolesTokenAuthorizationProvider is configured with authorization enabled but without a token authentication provider. This issue affects Apache Pulsar versions from 2.8.1 before 4.0.14 and from 4.1.0 before 4.2.5. - 4.0.x version users should upgrade to at least 4.0.14. - 4.1.x and 4.2.x version users should upgrade to at least 4.2.5. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions. The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/. Users who cannot upgrade immediately can remove the anonymousUserRole setting from the broker and WebSocket service configurations, or restrict network access to the HTTP endpoints of these services to trusted clients. |
| CVE-2026-113620 | Critical | 2026-10-20 | Not applicable | No public exploit | In Eclipse ioFog Controller versions 3.8.0 through 3.9.1, operator WebSocket upgrades on the exec and log routes do not verify the bearer JWT. The payload is decoded and its groups or roles are used as RBAC subjects. A self-minted token whose groups contain admin matches the built-in admin role, with no account and no RoleBinding. The attacker can open an exec or log session for a microservice or fog whose UUID they already know. HTTP routes are not affected: they verify the token before RBAC. Agent WebSockets verify the fog token and are not affected. |
| 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-10141 | Critical | 2026-10-20 | Not applicable | No public exploit | A Unsigned Firmware vulnerability exists in the boa Firmware Update functionality of X2000R (version(s): TOTOLINK-X2000R-Gh-V1.0.0-B20250421.1327). A specially crafted firmware binary can lead to arbitrary firmware update. An attacker can make an authenticated HTTP request to trigger this vulnerability. |
| CVE-2026-109838 | Medium | 2026-10-16 | Not applicable | No public exploit | IBM Db2 Genius Hub 1.0 could allow a local attacker to obtain sensitive information due to improper verification of cryptographic signature. |
| CVE-2026-102946 | Critical | 2026-10-15 | Not applicable | Proof of concept only | joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to 1.7.4, joserfc.jws.deserialize_json() accepts a JWS General JSON Serialization with an empty signatures array as authenticated. The verify_general_json() loop performs no iterations for the empty array and returns success because no signature check failed, allowing an attacker without a signing key to supply an arbitrary payload that relying applications may treat as authentic. The issue affects the General JSON Serialization path; compact JWS and JWT decoding, Flattened JSON serialization, and JWE JSON processing do not follow this vulnerable path. This issue is fixed in version 1.7.4. |
| 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-96252 | Critical | 2026-10-13 | Not applicable | No public exploit | Improper verification of cryptographic signature in Active Directory Federation Services (AD FS) allows an unauthorized attacker to perform spoofing 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-85818 | Critical | 2026-10-13 | Not applicable | No public exploit | Improper verification of cryptographic signature in Windows Schannel allows an unauthorized attacker to perform spoofing over a network. |
| CVE-2026-83798 | Medium | 2026-10-13 | Not applicable | No public exploit | Improper verification of cryptographic signature in Windows Update Stack allows an authorized attacker to perform spoofing locally. |
| CVE-2026-70071 | Medium | 2026-10-13 | Not applicable | No public exploit | Improper verification of cryptographic signature in DNS Server allows an authorized attacker to perform tampering locally. |
| 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-65197 | Low | 2026-10-13 | Not applicable | No public exploit | H3C HDM Family-A verifies the RSA signature of a firmware image against a public key it reads from the mutable file `/conf/public.pem`. That file is writable by an authenticated Redfish client through the `UpdateService.UploadSignKey` action, which stores the uploaded body verbatim after validating only that the multipart filename ends in `.pem`. An administrator, or any account with `firmware-update` privilege, can therefore replace the trust anchor with their own key, sign a malicious image with the matching private key, and have it pass verification. Family-A has no hardware root-of-trust (no PFR) to catch the substituted key. This was observed on H3C HDM Family-A G5 HDM 6.14.01. H3C HDM Family-A G3/G5 builds carrying the Redfish/DRE update tree appear to be affected. HDM2 uses a different update path and is not covered by this finding. |
| 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-102502 | Medium | 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 limited write access. Exploitation of this issue does not require user interaction. |
| 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. |