RDK-B WebUI improper cryptographic signature verification vulnerability

Improper cryptographic signature verification in `jst_functions.c` in RDK-B WebUI `rdkb-2025q4-kirkstone.04.10.26` allows a remote attacker to bypass authentication and obtain administrative access via a forged JWT containing an invalid RSA signature.

Net::OAuth versions before 0.33 for Perl allow the sender to choose the signature algorithm in verify

Net::OAuth versions before 0.33 for Perl allow the sender to choose the signature algorithm in verify. verify resolves the signature method class from the signature_method parameter of the incoming message. signature_method is required on every request, so the algorithm used to check a signature is chosen by whoever sent it, and nothing lets the verifying party pin the method instead. When a message names HMAC-SHA1 or HMAC-SHA256, the key is derived from consumer_secret and token_secret rather than from the key the provider deployed. A provider deployed on RSA-SHA1 holds only the consumer public key, and RFC 5849 does not use consumer_secret for that method, so the required parameter is filled with a placeholder. A client that names HMAC-SHA1 instead has its signature checked against that placeholder, so a guessable one is enough to forge requests for any consumer key and token.

Tenable Agent Path Traversal Leading to Remote Code Execution

A path traversal vulnerability in Tenable Agent 11.2.0 and 11.1.3 and lower allows a privileged attacker to write arbitrary files outside the intended plugin directory, potentially leading to remote code execution.

WatchGuard Agent improper authentication allows unauthenticated remote code execution

Improper authentication in the WatchGuard Agent allows an unauthenticated attacker with network access to cause the agent to execute arbitrary code with elevated privileges.

Ingenic T31 Boot ROM Secure-Boot Verification Flaw Allows Firmware Forgery

The Ingenic T31 SoC boot ROM flash-boot verification path compares only a single 32-bit word of the RSA signature output against a single 32-bit word of the SHA-256 payload digest, rather than compare the full data. This allows an attacker with physical write access to boot media to forge modified SPL (Secondary Program Loader) images that pass secure boot verification without possession of the OEM signing key. Each forgery attempt succeeds with approximately 2/3 probability. This has been validated via reverse engineering, software emulation against vendor-signed images, and end-to-end hardware acceptance of a forged firmware image on a Wyze Video Doorbell v2 (T31X).

The Ingenic T41, and probably also T32, T40, and A1 SoC boot ROMs parse and execute an attacker-controlled init table from the SPL header before checking the secure boot state and before invoking signature verification. The init table parser supports full-address 32-bit write operations, allowing modification of SRAM-resident secure boot state prior to the verification decision. An attacker with physical write access to boot media can inject an init-table entry that disables the secure boot check, causing the ROM to accept unsigned or modified first-stage boot code. This has been hardware-validated on a secureboot-enabled T41 device; ROM analysis confirms closely related behavior on T32, T40, and A1.

Verification Bypass vulnerability exists in EPSON 150075647YWWV110 EasyMP Network Updater Ver.1.20. The Epson projector can be updated by encrypted firmware through USB.

Cisco Enterprise NFV Infrastructure Software Remote Code Execution Vulnerability

A vulnerability in the upgrade component of Cisco Enterprise NFV Infrastructure Software (NFVIS) could allow an authenticated, local attacker to install a malicious file when upgrading. The vulnerability is due to insufficient signature validation. An attacker could exploit this vulnerability by providing a crafted upgrade file. A successful exploit could allow the attacker to upload crafted code to the affected device.

Azure Data Factory Elevation of Privilege Vulnerability

Improper verification of cryptographic signature in Azure Data Factory allows an unauthorized attacker to elevate privileges over a network.

OMEN Gaming Hub – Potential Escalation of Privilege & Information Disclosure

A potential security vulnerability has been identified in the OMEN Gaming Hub for versions prior to 1101.2608.0.0. The vulnerability could potentially allow a local attacker to escalate privileges due to insufficient access controls.

Missing JSON Web Token signature validation in Otalio Ship Property Management System

Missing signature validation in JSON Web Tokens in Otalio Ship Property Management System versions before 2.22.0 allows authenticated attackers to escalate privileges via tampering with JWTs

libcrux before 0.0.6 Cryptographic Implementation Bug Fixes

libcrux-ecdh and libcrux-ed25519 before 0.0.6, and libcrux-psq before 0.0.7, contain cryptographic implementation bugs. libcrux-ecdh did not properly check length and clamping during X25519 secret validation (and had a broken clamping check for imported X25519 secret keys); libcrux-ed25519 performed a duplicated clamping step during key generation; and libcrux-psq panicked instead of propagating an AEADError. These were fixed in the respective patched releases.

Quay: stripe webhook accepts forged events without signature verification in quay

A flaw was found in Red Hat Quay's Stripe billing webhook handler. This vulnerability allows an unauthenticated attacker to forge billing events by sending crafted JSON requests to the `/webhooks/stripe` endpoint without validating the Stripe-Signature header. Successful exploitation can lead to the unauthorized resetting of a namespace's build quota to its maximum and trigger unsolicited billing emails to namespace administrators.

Lemur : JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure

Lemur manages TLS certificate creation. Prior to 1.9.2, the JWT verifier in lemur/auth/service.py:130-137 used fetch_token_header to read header_data["alg"] from an unverified token and passed that attacker-controlled value to decode_with_multiple_secrets. PyJWT 2.x rejects alg=none with the configured key, so the flaw is a defense-in-depth gap rather than a direct authentication bypass in the shipped configuration. The unpinned algorithm can become exploitable after an asymmetric-signing migration through algorithm confusion, and it weakens algorithm-based anomaly detection because the token chooses the recorded value. A separate disclosure of LEMUR_TOKEN_SECRET would also permit forged HS256 tokens, although that disclosure is an independent prerequisite. The fix introduces the server-controlled LEMUR_TOKEN_ALGORITHMS allowlist and defaults it to HS256. This issue is fixed in version 1.9.2.

kas checks out SHA-like git branches as valid commits

kas is a setup tool for bitbake based projects. Prior to version 5.3, when relying solely on a git commit ID (SHA-1 or SHA-256) to qualify if a checkout of a repository is equivalent to the state validated while adding its commit ID to a kas configuration, users may be tricked to check out a branch of the same name from this repository. This implies that the referenced repository has been taken over by an attacker and modified to carry such a branch. SHA-1 commits may also be replaced by creating hash collisions, so the primary impact of this issue is on SHA-256 commit IDs. Version 5.3 fixes the issue. As a workaround, avoid relying solely on the commit ID for integrity validation of a repository that might become under control of a malicious 3rd party. If available, additional validate cryptographically signed commits or tags. Alternatively, mirror the repository to a save place, validate its integrity, and use this instead of the original one.

PAX Technology Q80 Application Installer Signature Verification Bypass Remote Code Execution Vulnerability

PAX Technology Q80 Application Installer Signature Verification Bypass Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of PAX Technology Q80. Authentication is not required to exploit this vulnerability. The specific flaw exists within the application installer. The issue results from the lack of proper verification of a cryptographic signature before installing an application. An attacker can leverage this in conjunction with other vulnerabilities to execute code in the context of root. Was ZDI-CAN-30585.

kas's late signature validation may allow unnoticed repository manipulations

kas is a setup tool for bitbake based projects. Starting in version 4.8 and prior to version 5.3, kas checks out and processes repositories regarding configuration includes prior to validating signatures of those repositories. This may allow to replace on original repository with one under the control of an attacker under very specific conditions. First of all, the attacker must have gained control of a repository that a kas file of the victim is referencing. Furthermore, the following conditions must be fulfilled: the victim's kas configuration must include a configuration file from the attacked repository; the repository state is referenced by tag, and no commit ID is specified (this is triggering a warning, though); the key used for validating the tag or commit signature is stored as file in a repository; no fingerprint for the key is specified; and the `_source_dir` key must not be set by the victim when calling kas (e.g. by avoiding a local `.config.yaml`). Given these conditions, the attacker could modify the included kas configuration in way that the key used to validate the tag signature of the attacker's repository could be replaced by an attacker-chosen key. No other exploit possibilities have been identified so far, but this does not rule out that those may exist. All patches have been released along with kas version 5.3. As a workaround, pin the expected signature key via its fingerprint, also when storing it as file in a repository.

Ignore unrelated, unauthenticated hashes in Lookup in golang.org/x/mod/sumdb

A malicious GOSUMDB was capable of serving arbitrary module content not contained within the transparency log. This attack allows for a coordinating GOPROXY and GOSUMDB to serve a client malicious module content that cannot be detected by evaluating the transparency log. In order to determine if you have been affected: rm -r go.sum go.work.sum vendor/ && go mod tidy

Network-AI before 5.13.4 Cryptographic Signature Verification Bypass

Network-AI before 5.13.4 contains an improper cryptographic signature verification vulnerability in APSAdapter where the default local verifier accepts any non-empty string as valid. Unauthenticated attackers can submit forged APS delegation payloads with arbitrary scopes to bypass signature verification and obtain signed permission-grant tokens for sensitive resources including SHELL_EXEC.

Fix transparency log tile verification bypass in golang.org/x/mod/sumdb/tlog

A malicious GOPROXY was previously capable of forging up to two sumdb tiles that allow for a requested module to bypass the GOSUMDB check and persist attacker-controlled module content to a local Go module cache. This attack allows for a malicious GOPROXY to serve malicious module content that cannot be detected by evaluating the transparency log. All tiles are now correctly verified against their parents. In order to determine if you have been affected: rm -r go.sum go.work.sum vendor/ && go mod tidy