🚨 CVE-2026-10773
The DHCPv4 client helper net_dhcpv4_msg_type_name() in subsys/net/lib/dhcpv4/dhcpv4.c indexes a static 8-element const char * name table after a faulty bounds check. The guard used msg_type <= sizeof(name) instead of msg_type <= ARRAY_SIZE(name); sizeof returns the byte size of the pointer array (32 on 32-bit, 64 on 64-bit targets) rather than the element count of 8, so message-type values from 9 up to that byte size pass the check and cause name[msg_type - 1] to read past the end of the array.

The msg_type value originates from the DHCP MESSAGE TYPE option, which is read as an unchecked raw byte from a received packet (net_pkt_read_u8) and passed unmodified into the lookup. A DHCP server, or any host able to inject a spoofed DHCP reply onto the client's link, can therefore drive the index out of bounds. The out-of-range slot yields a garbage const char * that is then dereferenced by a %s log conversion.

The lookup is reached only from a debug log statement (NET_DBG / LOG_DBG), so the out-of-bounds read is triggerable only when the DHCPv4 log module is built at DEBUG level (CONFIG_NET_DHCPV4_LOG_LEVEL_DBG), which is not the default configuration. When that condition holds, the result is an out-of-bounds read and a wild-pointer dereference: most likely a crash of the DHCP client (denial of service) and potentially disclosure of an adjacent pointer's contents through the log output. The fix replaces sizeof with ARRAY_SIZE, restoring the correct 1..8 acceptance window.

🎖@cveNotify

🚨 CVE-2026-2411
Zephyr's Bluetooth host declares a GATT characteristic as two consecutive attributes: a Characteristic Declaration whose permission is hard-coded to BT_GATT_PERM_READ, and a Characteristic Value attribute that carries the application-specified security permissions (e.g. BT_GATT_PERM_READ_ENCRYPT / READ_AUTHEN / READ_LESC). The public notify and indicate APIs explicitly accept either attribute, and passing the declaration is the documented, common idiom. Before sending each notification or indication, the host re-checks link security with bt_gatt_check_perm() against params->attr in gatt_notify(), gatt_indicate(), and gatt_notify_multiple_verify_params() (subsys/bluetooth/host/gatt.c).

When the application passed the Characteristic Declaration attribute, the host correctly redirected the value handle but left params->attr pointing at the declaration, so the security check evaluated the declaration's permissions (no security required) instead of the value's. As a result the encryption/authentication/LESC requirement configured on the characteristic value was skipped. The Notify-Multiple path additionally used a mask that omitted the LE Secure Connections requirement.

A remote peer triggers the disclosure by connecting (optionally without pairing or encryption) and writing the Client Characteristic Configuration descriptor to enable notifications or indications, causing the server to emit the protected value over a link that has not reached the required security level. The impact is information disclosure / access-control bypass for characteristic values the application intended to expose only over a secured link; exposure depends on the application declaring encrypt/authen-required notify/indicate characteristics and on the CCC being writable at a lower security tier. There is no memory-safety or availability impact.

The fix adds bt_gatt_attr_resolve_value(), which maps a declaration attribute to the following value attribute before the permission check, and switches the Notify-Multiple path to the full BT_GATT_PERM_READ_ENCRYPT_MASK so the LESC requirement is also enforced.

🎖@cveNotify

🚨 CVE-2026-10774
Zephyr's Bluetooth Mesh subnet key management leaks one PSA Crypto key slot on every subnet-key teardown. In subsys/bluetooth/mesh/subnet.c, net_keys_create() imports the Private Beacon Key into a PSA key slot under CONFIG_BT_MESH_PRIV_BEACONS (enabled by default), but subnet_keys_destroy() guarded the matching psa_destroy_key() with CONFIG_BT_MESH_V1d1. That Kconfig symbol was removed when explicit Mesh 1.0.1 support was dropped, so the destroy branch became permanently dead code and the import is never balanced by a destroy.

The imbalanced teardown is reached every time subnet keys are destroyed: deleting a subnet (Config Server NetKey Delete), completing a Key Refresh Procedure (which retires the old key set), and resetting/re-provisioning the node. The over-the-air triggers are processed only under the node's device key, so they are exercisable by the provisioner or network administrator that owns the node, reachable over the Bluetooth Mesh network.

With the default CONFIG_MBEDTLS_PSA_KEY_SLOT_COUNT of 16, repeated add/delete or key-refresh cycles exhaust the shared PSA key-slot pool after roughly a dozen rounds. Once exhausted, bt_mesh_private_beacon_key() and thus subnet creation fail: the node can no longer add subnets or complete key refresh, and other PSA crypto consumers on the device may be starved, until the device is rebooted. The fix aligns the destroy guard with the import guard (CONFIG_BT_MESH_PRIV_BEACONS) so each slot is freed.

🎖@cveNotify

🚨 CVE-2026-10848
The OCPP 1.6 client in subsys/net/lib/ocpp parsed inbound WAMP RPC frames in parse_rpc_msg() (subsys/net/lib/ocpp/ocpp_j.c) using a hand-rolled helper, extract_string_field(), that copied the message's uid and action fields with strncpy(out_buf, token + 1, outlen - 1) and then scanned the result with strchr(out_buf, '"'). Because strncpy does not NUL-terminate the destination when the source is at least outlen - 1 (127) bytes long, the subsequent strchr reads past the 128-byte destination buffer into adjacent stack memory; if a " byte is found beyond the buffer, a one-byte out-of-bounds NUL write also occurs. A related defect in extract_payload() runs strchr/strrchr over the receive buffer, which may not be NUL-terminated when a maximal-length frame fills it.

The parsed bytes come directly from the OCPP central-system server over a websocket: the reader thread fills recv_buf via websocket_recv_msg() and calls parse_rpc_msg() on each inbound DATA frame (subsys/net/lib/ocpp/ocpp.c). A malicious or compromised central server, or an on-path attacker (OCPP is commonly deployed over plain ws://), can send an RPC frame whose uid or action field is 127+ bytes with no closing quote, triggering the out-of-bounds access.

The primary impact is a remotely triggerable denial of service: the unbounded scan can fault on an unmapped page, and the stray NUL write can corrupt adjacent stack state. The over-read data is not reflected to the peer, so disclosure is limited. The feature is EXPERIMENTAL and must be explicitly enabled (CONFIG_OCPP). The fix replaces the manual parser with the bounds-respecting json_mixed_arr_parse() and copies the extracted uid with an explicitly NUL-terminated buffer, eliminating both over-reads.

🎖@cveNotify

🚨 CVE-2025-9291
A
certification validation weakness exists in communication between affected
Omada devices and cloud controllers. Certificate identity verification does not
adequately validate that a presented certificate corresponds to the expected
cloud controller hostname, which may allow certificate validation protections
to be bypassed under specific conditions.





Successful
exploitation may allow interception or modification of communication between
affected devices and cloud controllers.

🎖@cveNotify

🚨 CVE-2025-15544
A cryptographic
weakness exists in the Omada device adoption process.  During adoption, authentication credentials associated
with site management are transmitted using a weak hashing algorithm that does
not provide sufficient protection.









An attacker who
successfully intercepts adoption-related authentication traffic may be able to
recover valid credentials and gain unauthorized access to managed devices or
controller-managed environments.

🎖@cveNotify

🚨 CVE-2025-15627
A cryptographic
weakness exists in the Omada adoption protocol. 
The protocol relies on hard-coded cryptographic keys to establish trust and
protect authentication exchanges between controllers and managed devices during
device adoption.









An attacker may
be able to impersonate trusted controllers or managed devices and gain access
to sensitive adoption-related communications.

🎖@cveNotify

🚨 CVE-2025-15628
Affected
Omada devices rely on embedded certificates that are shared across deployments
to establish trust between controllers and managed devices.









An attacker
who obtains the embedded certificates may be able to impersonate trusted
controllers or devices and intercept affected communications.

🎖@cveNotify

🚨 CVE-2025-15629
A cryptographic
weakness exists in the Omada adoption protocol where session encryption keys
used to protect communications between controllers and managed devices may be
predictable due to insufficient entropy in session key generation.









An attacker
who successfully intercepts adoption-related communications may be able to recover
session encryption keys and decrypt affected communications.

🎖@cveNotify

🚨 CVE-2025-15630
A race
condition exists in the cloud-based Omada device adoption process when an
attacker may be able to interact with the adoption workflow before a legitimate
device completes registration, resulting in provisioning information being
delivered to an attacker.









Successful
exploitation may allow disclosure of provisioning information intended for a
legitimate device.

🎖@cveNotify

🚨 CVE-2025-15631
A
cryptographic weakness exists in affected Omada devices where site credentials
are protected using a legacy hashing algorithm that does not provide sufficient
protection.









An attacker
who obtains access to stored credential data may be able to recover valid credentials
to gain unauthorized access to affected devices or management environments.

🎖@cveNotify

🚨 CVE-2026-10849
The hawkBit device management client in subsys/mgmt/hawkbit accumulates the body of an HTTP response from the update server into a heap buffer in response_json_cb() (subsys/mgmt/hawkbit/hawkbit.c). The buffer is sized to hold the received body bytes but reserves no space for a terminating NUL. When the full response has arrived, the code writes response_data[downloaded_size] = '\0' — and whenever the accumulated body length equals the allocation, that terminator lands one byte past the end of the heap object (a heap-based out-of-bounds write, CWE-122 / CWE-787).

The body length and fragmentation are taken directly from the parsed HTTP response (rsp->body_frag_start / rsp->body_frag_len) and are fully controlled by the remote hawkBit server, which chooses its own response length. The precise trigger depends on how the buffer grows, and both forms are remotely reachable. Since v4.0.0 the reallocation is sized to exactly downloaded_size + body_len, so any response body larger than the 1100-byte initial buffer makes the out-of-bounds write deterministic; such response sizes are normal for hawkBit deployment metadata. Before v4.0.0 the buffer grew by doubling and the growth check ((downloaded_size + body_len) > response_buffer_size) is false at equality, so a response body whose length is exactly the current allocation — 1100 bytes with the default initial buffer — skips the reallocation entirely and writes the terminator at response_data[1100] of an 1100-byte object. The HTTP length-mismatch check does not catch this, because the declared and received lengths genuinely agree. Either form is reachable by a malicious, compromised, or man-in-the-middle update server (TLS is optional and, when enabled, does not protect against a hostile server), with no authentication of response content and no client-side length cap protecting the write.

The out-of-bounds write is a fixed single NUL byte immediately following the allocation, corrupting adjacent allocator metadata or the next allocation. The practical impact is heap corruption leading to denial of service (fault on a subsequent allocation or free), with the bounded, allocator-dependent possibility of further corruption. The fix sizes the buffer to the body length plus one and copies with memcpy, ensuring the terminator always lands within the allocation.

🎖@cveNotify

🚨 CVE-2026-65802
External control of file name or path in Microsoft Edge for Android allows an unauthorized attacker to disclose information over a network.

🎖@cveNotify

🚨 CVE-2026-65804
Improper control of generation of code ('code injection') in Microsoft Edge (Chromium-based) allows an unauthorized attacker to perform spoofing over a network.

🎖@cveNotify

🚨 CVE-2026-66310
External control of file name or path in Microsoft Edge for Android allows an unauthorized attacker to disclose information locally.

🎖@cveNotify

🚨 CVE-2026-66311
Missing authorization in Microsoft Edge (Chromium-based) allows an unauthorized attacker to perform tampering locally.

🎖@cveNotify

🚨 CVE-2026-66312
Buffer over-read in Microsoft Edge (Chromium-based) allows an authorized attacker to execute code over a network.

🎖@cveNotify

🚨 CVE-2026-66313
Origin validation error in Microsoft Edge (Chromium-based) allows an unauthorized attacker to perform tampering locally.

🎖@cveNotify

🚨 CVE-2026-66314
Time-of-check time-of-use (toctou) race condition in Microsoft Edge (Chromium-based) allows an unauthorized attacker to disclose information over a network.

🎖@cveNotify

🚨 CVE-2026-66315
Use after free in Microsoft Edge (Chromium-based) allows an unauthorized attacker to execute code over a network.

🎖@cveNotify

🚨 CVE-2026-66316
Origin validation error in Microsoft Edge (Chromium-based) allows an unauthorized attacker to perform spoofing over a network.

🎖@cveNotify