Tod Beardsley

A specially crafted malformed search query could return results from outside a user's organization. Log analysis of runZero's hosted environment found only testing of the issue and no adversary traffic. This issue was fixed in version 5.1.261013.1.

The root-privileged `wsserver` terminal-bridge daemon allows a connected client to execute arbitrary commands on the appliance as root. This occurs because the daemon constructs a shell command using client-supplied WebSocket fields and passes it to the `system()` and `popen()` functions without proper quoting, escaping, or character-set validation. Additionally, the daemon's public-key session path does not perform an appliance-session check.

The device-management process in openUBMC improperly handles PLDM-over-MCTP and NCSI-over-MCTP responses from on-bus devices. Three response parsers within the shared transport libraries subtract a fixed header or reserved-field size from a response length provided by the device without performing a lower-bound check. If a response is undersized, the unsigned length difference wraps to a very large value, causing the parser to read memory far beyond the response buffer. This issue affects the base PLDM control class and the Huawei NCSI driver, making it reachable via any PLDM endpoint or Huawei NIC on the internal management bus.

The software assigns a full privilege set to pseudo-identities used by SNMP callers. This allows an authenticated user with low privileges to execute mapped backend operations with administrative authority. The issue occurs in `route mapper/account.lua` within the `get user privilege()` function, which returns a complete nine-privilege set for the `special users` group, including the `SNMPv1 v2c` pseudo-user.

The software verifies the RSA signature of a firmware image using a public key stored in the `/conf/public.pem` file. An authenticated Redfish client with `firmware-update` privileges can overwrite this file via the `UpdateService.UploadSignKey` action, as the system only validates that the filename ends in `.pem`. This allows an attacker to replace the trust anchor with a custom key and subsequently install a malicious firmware image signed with the corresponding private key. The system lacks a hardware root-of-trust, such as Platform Firmware Resilience (PFR), to detect the key substitution.

openUBMC ships with a default SNMPv3 USM key that utilizes a single value for both authentication and privacy. Because these keys are constants within the open-source build and not unique per unit, an attacker can recover them to authenticate SNMPv3 requests and decrypt traffic. The issue involves the `AuthenticationKey` and `EncryptionKey` variables defined in the `manifest/build/customization/default password.lua` and `account/manufacture/default password.lua` files. These keys are not rotated during Administrator password resets, allowing them to persist after account provisioning. Since SNMP access is mapped to full device administration privileges, this could allow unauthorized system resets and firmware upgrades.

A logic flaw in the IPMI implementation of OpenBMC allows the authorization context of an active session to be replaced with a target account. This occurs while the original integrity and encryption keys remain active, enabling privilege escalation without the need for re-authentication. This implementation is used by several downstream vendors, including NVIDIA and H3C.

A logic flaw in the IPMI implementation allows an unauthenticated client to force the RAKP Message 1 handler to return before the authentication object's constructor defaults are overwritten. Consequently, the IPMI service accepts a RAKP Message 3 where the HMAC is calculated using a predictable `bmcRandomNum` and a constant 20-byte `userKey` initialized as '0penBmc'. This issue affects OpenBMC and downstream vendors using phosphor-net-ipmid as their IPMI stack, including NVIDIA and H3C.

An uninitialized cluster exposure occurs when the `f lseek()` function extends files beyond the end-of-file (EOF) without zero-filling newly allocated clusters. This issue is a Use of Uninitialized Resource, where the system fails to clear memory or storage before use, potentially exposing sensitive data previously stored in those clusters.

An integer underflow occurs during interleaved read and write operations on fragmented filesystems. This issue is caused by an unsigned-subtraction wrap in the `f read()` and `f write()` functions when evaluating the condition `fp->sect - sect < cc`, which leads to a stale dirty-cache skip.

An integer overflow occurs in the `mount volume()` function during FAT32 processing when the operation `fasize *= fs->n fats` wraps. This allows an attacker to control file-size metadata, resulting in unsafe read lengths for downstream callers. This issue can be exploited via crafted FAT images on USB sticks or SD cards to achieve arbitrary code execution on embedded devices, including those using ESP-IDF, STM32Cube, Zephyr, and ArduPilot. Additionally, remote delivery is possible through OTA or update pipelines. Real-world exploitation has been demonstrated on a camera device.

A stack-based buffer overflow occurs in the `f getlabel()` function. This issue arises because the exFAT label length `XDIR NumLabel` is trusted without enforcing the maximum limits defined by the specification.

An issue exists when using GPT scanning with `FF LBA64 = 1` where an unbounded loop count is derived from the GPT header field `GPTH PtNum`. This can lead to extremely long or effectively infinite scans during the mount-time process, resulting in a loop with an unreachable exit condition.

An issue exists in the handling of long filenames when LFN (Long File Name) is enabled. The `fno.fname` variable can reach up to 255 characters, and many callers copy this data into short fixed buffers without performing bounds checks, leading to a buffer overflow. A buffer overflow occurs when a program writes more data to a block of memory than it is allocated to hold.

A divide-by-zero issue exists in the exFAT sync logic. This occurs during write or sync operations when crafted metadata causes the calculation `n fatent - 2` to result in zero. Divide-by-zero is a condition where a program attempts to divide a number by zero, which typically leads to a system crash or application failure.

Insufficient validation of the ACME challenge token against RFC 8555 during challenge-file handling allows a maliciously crafted token to influence local path or filename usage. An attacker capable of supplying ACME challenge responses—such as through a compromised CA endpoint or by tampering with the response path—can achieve unauthorized file write and path traversal effects. This typically occurs with elevated privileges and can lead to remote command injection. This is an instance of External Control of File Name or Path, where an external input determines the path used by the application.

The Aqara Board service at the endpoint "op-test.aqara.com" accepts arbitrary MQTT command payloads and forwards them to the platform's HiveMQ broker without authentication. This missing authentication for a critical function allows for unauthenticated MQTT command injection. When combined with other flaws, this can lead to a complete remote takeover of affected devices.

The Aqara IAM/SSO Gateway at the endpoint 'gw-builder.aqara.com' uses a hardcoded OAuth client credential. This flaw can be combined with other issues to allow a fully unauthenticated remote takeover of affected devices.

The IAM/SSO gateway at 'gw-builder.aqara.com' exposes an unauthenticated AES oracle, allowing bidirectional AES round-trips against the platform's signing key. This occurs due to missing authentication for a critical function and the use of a broken or risky cryptographic algorithm.

🚨 CVE-2026-50082 The Aqara Cloud Developer Portal (developer.aqara.com) issued a developer token to any email address supplied by the attacker. This is an instance of "CWE-306: Missing Authentication for Critical Function" with an estimated CVSS of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N (6.5 Medium). When combined with CVE-2026-50083, CVE-2026-50084, and CVE-2026-50085, any otherwise-unauthenticated attacker could execute a full takeover of affected devices. 🎖@cveNotify