Vulnerabilities

OpenBao is an open source identity-based secrets management system. Prior to version 2.5.4, OpenBao's namespaces provide multi-tenant separation. A tenant who intentionally leaks lease identifiers can have their lease and underlying credential revoked or renewed by a user in another tenant via the legacy, undocumented `sys/revoke` and `sys/renew` endpoints. This is fixed in OpenBao v2.5.4.

OpenBao is an open source identity-based secrets management system. Prior to version 2.5.4, in OpenBao's Kerberos auth method on the `GET` handler, or when an `Authorization: Negotiate` header is supplied, the response is includes a `logical.Auth` object in addition to an error message. This results in tokens being created with only the default policy, default TTL, and no entity information, which are hidden by the returned error message. No access to these tokens by the caller occurs and the authentication token is not ever made accessible outside of `sys/raw`. This is fixed in OpenBao v2.5.4. As a workaround, users may set a rate limit quota to limit the creation of these paths. As the path is unauthenticated, it isn't possible to deny access to it.

The kernel queue helper z_queue_node_peek() in kernel/queue.c dereferences a node taken from a queue&amp;#39;s data_q list, reading the node&amp;#39;s flag byte and, for items enqueued via k_queue_alloc_append/alloc_prepend, the data pointer of an internally allocated alloc_node struct. The implementations of z_impl_k_queue_peek_head() and z_impl_k_queue_peek_tail() performed this read-and-dereference without holding the queue&amp;#39;s spinlock, while every other accessor of the same list — including k_queue_get(), which unlinks a node and k_free()s its backing alloc_node — operates under that lock.<br /> <br /> Because peek was unsynchronized, a concurrent k_queue_get() on the same queue (on an SMP build, or under preemption/ISR concurrency) can free the node between the moment peek obtains the node pointer and the moment it dereferences it. The peek then reads flag bits and a data pointer out of freed, potentially re-allocated heap memory and returns a stale or dangling pointer to its caller. k_fifo and k_lifo are thin wrappers over k_queue, so this affects buffer queues used throughout the net_buf, Bluetooth, USB, and networking subsystems; the peek operations are also system calls reachable from CONFIG_USERSPACE threads.<br /> <br /> The consequences are a use-after-free read that can leak stale heap contents (one pointer word) and, when the returned dangling pointer is subsequently consumed as a live buffer, a dereference that can crash the system or corrupt memory. Exploitation requires winning a small race window with local access (e.g. a userspace process racing k_queue_peek_* against k_queue_get on a shared queue, or two CPUs), so practical impact is bounded and of low severity.<br /> <br /> The fix wraps both peek implementations with k_spin_lock/k_spin_unlock on the queue lock, making the read-and-dereference atomic with respect to the concurrent unlink-and-free and bringing peek into line with the rest of the queue&amp;#39;s locking discipline.

The SF32LB MPI QSPI NOR flash driver (drivers/flash/flash_sf32lb_mpi_qspi_nor.c) validated the flash offset and length on its read and write paths with the test (offset + size) &gt; data-&gt;size. Because offset is a signed off_t while size is unsigned, a negative offset is converted to a large unsigned value and the addition can wrap to a small result that passes the check. The read path then performs memcpy(dst, (void *)(data-&gt;base + offset), size) and the write path programs flash at offset and cache-invalidates data-&gt;base + offset, in both cases accessing memory outside the mapped flash window. The driver&amp;#39;s erase path already rejected negative offsets, but read and write did not.<br /> <br /> In builds with CONFIG_USERSPACE, flash_read and flash_write are syscalls whose verifiers validate the device object and the caller&amp;#39;s buffer but deliberately delegate offset bounds checking to the driver. An unprivileged thread that has been granted access to this flash device can therefore call the syscall with a crafted negative offset and a buffer valid in its own memory domain, and reach the unchecked access.<br /> <br /> The most direct impact is on the read path: by choosing a negative offset and matching size, an attacker slides the memcpy source below the flash base and copies arbitrary CPU-addressable memory into its own buffer, disclosing memory it is not authorized to read. The write path additionally allows programming flash at an out-of-range address and invalidating an attacker-chosen cache range, affecting integrity and availability. Reachability requires userspace to be enabled and the raw flash device object to be granted to an untrusted thread.<br /> <br /> The fix replaces the check with qspi_nor_range_is_valid(), which rejects negative offsets and performs the bound comparison in overflow-safe 64-bit arithmetic on both paths, and additionally adds an SRAM DMA bounce buffer plus source/destination overlap rejection to prevent a separate DMA bus-hang condition.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Adobe Genuine Software Integrity Service on Windows is affected by an Incorrect Authorization 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, but requires the attacker to access the target desktop system locally (e.g., keyboard, console), or remotely (e.g., SMB).

A denial-of-service<br /> vulnerability exists in httpd service on Archer A6 v4 where the asynchronous systool<br /> instruction handlng path in httpd does not properly synchronize or safely manage<br /> concurrent systool operations.  <br /> <br /> <br /> <br /> <br /> <br /> By sending<br /> crafted systool instructions through the asynchronous request path, successful<br /> exploitation may cause the httpd process or device management service to crash<br /> and may result in temporary loss of access to the web management interface or<br /> device reboot.

An input validation<br /> vulnerability exists in the HTTP-WRITEOEM handler due to insufficient validation<br /> of user-supplied data before it is processed by internal flash-write handling<br /> logic.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Successful<br /> exploitation may cause httpd process or device to crash, resulting in loss of access<br /> to the web interface and a denial-of-service condition.

Home Assistant is open source home automation software focused on local control and privacy. Prior to 2026.6.1, the Android Companion app is vulnerable to an open redirect. The app passes the URL fragment from a homeassistant://invite deep link into the onboarding flow without ever displaying the destination hostname. Because no screen in the invitation or onboarding flow shows the parsed server URL before onboarding commits to it, a victim has no way to distinguish a legitimate invite from a malicious one. An attacker can craft an invite so that a single tap on the legitimate-looking "Connect to my Home Assistant server" button opens their /auth/authorize endpoint in the URL-less onboarding WebView, presenting a look-alike login page that captures the victim&amp;#39;s credentials. Since invitations are intended to onboard brand-new users, targets are especially unlikely to notice the substitution. This issue is fixed in version 2026.6.1.

Home Assistant is open source home automation software focused on local control and privacy. Prior to 2026.5.0, the iOS Companion app treats tag links (NFC or QR) delivered through an OS-level routing mechanism such as iOS universal links as if they were physically scanned, without validating the calling app or prompting the user. As a result, any untrusted app on the device can forward an arbitrary tag to Home Assistant, causing it to execute the associated automation as though a legitimate user had scanned an authorized tag. This allows silent, unattended automation execution by untrusted local callers. This issue has been fixed in version 2026.5.0.

Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.34, the built-in CORS middleware, hono/cors, is vulnerable to a regular expression denial of service (ReDoS). During a preflight OPTIONS request, the middleware parses the attacker-controlled Access-Control-Request-Headers header using a whitespace-tolerant regular expression whose backtracking makes its running time quadratic in the input length. Because the header value is bounded only by the deployment&amp;#39;s maximum HTTP header size, a single preflight carrying a long run of whitespace can consume seconds of CPU and block request processing. On runtimes that share one execution thread across requests, this stalls concurrent requests as well, and repeated requests can render the service unresponsive. This affects the default configuration, since the vulnerable path is reached whenever cors() is used with an unset or empty allowHeaders. Applications that set a non-empty allowHeaders are not affected. This issue is fixed in version 4.12.34.