CVE WatchOct 8, 2026

CVE-2025-34500

Deck Mate 2's firmware update mechanism accepts packages without cryptographic signature verification, encrypts them with a single hard-code

CVSS

—

No CVSS

EPSS

0.1%

KEV

—

Exploit Today

0-100

Published: Oct 24, 2025 · Last modified: Oct 8, 2026 · CWE-321 · CWE-327 · CWE-347

EPSS · 30d

0.1%EPSS · 30 days0.1%

2026-10-022026-10-29

Technical description

Deck Mate 2's firmware update mechanism accepts packages without cryptographic signature verification, encrypts them with a single hard-coded AES key shared across devices, and uses a truncated HMAC for integrity validation. Attackers with access to the update interface - typically via the unit's USB update port - can craft or modify firmware packages to execute arbitrary code as root, allowing persistent compromise of the device's integrity and deck randomization process. Physical or on-premises access remains the most likely attack path, though network-exposed or telemetry-enabled deployments could theoretically allow remote exploitation if misconfigured. The vendor confirmed that firmware updates have been issued to correct these update-chain weaknesses and that USB update access has been disabled on affected units.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-631828.1 HIG

—

———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.8h CVE-2026-465607.5 HIG

—

———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.11h CVE-2026-617379.8 CRI

—

———ng-antd-admin is an Angular and NestJS administration system template. Prior to 22.0, a hardcoded default `JWT` secret permits token forgery when a deployment has not replaced the default secret, without a startup warning. An attacker can bypass authentication and authorization, impersonate any user including administrators, and access protected API endpoints, leading to account takeover, data leakage and unauthorized operations. Version 22.0 rejects the shipped secret in production but permits it with a warning in non-production environments.11h CVE-2026-919127.3 HIG

—

———Dell OpenManage Enterprise, versions prior to 4.8.0, contains an Use of Hard-coded Cryptographic Key vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Information disclosure.14h CVE-2026-1195979.8 CRI

—

———OpenDeepWiki through 2.0.6 contains a hard-coded JWT signing key vulnerability that allows unauthenticated attackers to forge administrator tokens using the publicly known Jwt:SecretKey in appsettings.json. Attackers can mint HS256 bearer tokens with an Admin role claim to access /api/admin endpoints and control users, roles, repositories, settings, and API keys.11h CVE-2026-119037—

—

———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.13h