arduino-esp32 is an Arduino core for the ESP32, ESP32-S2, ESP32-S3, ESP32-C3, ESP32-C6 and ESP32-H2 microcontrollers. Prior to 3.3.8, the WebServer multipart form parser in arduino-esp32 allocates a Variable Length Array (VLA) on the stack whose size is derived from an attacker-controlled HTTP header field (Content-Type: multipart/form-data; boundary=...) without enforcing any length limit. Sending a boundary string longer than ~8000 characters overflows the 8192-byte task stack of the loopTask, causing a crash and potential remote code execution. This vulnerability is fixed in 3.3.8.

espressif

arduino-esp32 is an Arduino core for the ESP32, ESP32-S2, ESP32-S3, ESP32-C3, ESP32-C6 and ESP32-H2 microcontrollers. Prior to 3.3.8, there is a remotely reachable memory corruption issue in the NBNS packet handling path. When NetBIOS is enabled by calling NBNS.begin(...), the device listens on UDP port 137 and processes untrusted NBNS requests from the local network. The request parser trusts the attacker-controlled name_len field without enforcing a bound consistent with the fixed-size destination buffers used later in the flow. This vulnerability is fixed in 3.3.8.

espressif

Cocos AI is a confidential computing system for AI. The current implementation of attested TLS (aTLS) in CoCoS is vulnerable to a relay attack affecting all versions from v0.4.0 through v0.8.2. This vulnerability is present in both the AMD SEV-SNP and Intel TDX deployment targets supported by CoCoS. In the affected design, an attacker may be able to extract the ephemeral TLS private key used during the intra-handshake attestation. Because the attestation evidence is bound to the ephemeral key but not to the TLS channel, possession of that key is sufficient to relay or divert the attested TLS session. A client will accept the connection under false assumptions about the endpoint it is communicating with — the attestation report cannot distinguish the genuine attested service from the attacker's relay. This undermines the intended authentication guarantees of attested TLS. A successful attack may allow an attacker to impersonate an attested CoCoS service and access data or operations that the client intended to send only to the genuine attested endpoint. Exploitation requires the attacker to first extract the ephemeral TLS private key, which is possible through physical access to the server hardware, transient execution attacks, or side-channel attacks. Note that the aTLS implementation was fully redesigned in v0.7.0, but the redesign does not address this vulnerability. The relay attack weakness is architectural and affects all releases in the v0.4.0–v0.8.2 range. This vulnerability class was formally analyzed and demonstrated across multiple attested TLS implementations, including CoCoS, by researchers whose findings were disclosed to the IETF TLS Working Group. Formal verification was conducted using ProVerif. As of time of publication, there is no patch available. No complete workaround is available. The following hardening measures reduce but do not eliminate the risk: Keep TEE firmware and microcode up to date to reduce the key-extraction surface; define strict attestation policies that validate all available report fields, including firmware versions, TCB levels, and platform configuration registers; and/or enable mutual aTLS with CA-signed certificates where deployment architecture permits.

ultraviolet

Protection mechanism failure in wolfCrypt post-quantum implementations (ML-KEM and ML-DSA) in wolfSSL on ARM Cortex-M microcontrollers allows a physical attacker to compromise key material and/or cryptographic outcomes via induced transient faults that corrupt or redirect seed/pointer values during Keccak-based expansion. This issue affects wolfSSL (wolfCrypt): commit hash d86575c766e6e67ef93545fa69c04d6eb49400c6.

wolfssl

RIOT is an open-source microcontroller operating system, designed to match the requirements of Internet of Things (IoT) devices and other embedded devices. In 2026.01 and earlier, the default handler for the well_known_core resource coap_well_known_core_default_handler writes user-provided option data and other data into a fixed size buffer without validating the buffer is large enough to contain the response. This vulnerability allows an attacker to corrupt neighboring stack location, including security-sensitive addresses like the return address, leading to denial of service or arbitrary code execution.

riot-os

Exposure of Sensitive System Information to an Unauthorized Actor vulnerability in Microcom ZeusWeb allows Web Application Fingerprinting of sensitive data. This issue affects ZeusWeb: 6.1.31.

microcom360

An attacker with access to the web application ZeusWeb of the provider Microcom (in this case, registration is not necessary, but the action must be performed) who has the vulnerable software could introduce arbitrary JavaScript by injecting an XSS payload into the ‘Surname’ parameter of the ‘Create Account’ operation at the URL:  https://zeus.microcom.es:4040/index.html?zeus6=true . This issue affects ZeusWeb: 6.1.31.

microcom360

An attacker with access to the web application ZeusWeb of the provider Microcom (in this case, registration is not necessary, but the action must be performed) who has the vulnerable software could introduce arbitrary JavaScript by injecting an XSS payload into the ‘Email’ parameters within the ‘Recover password’ section at the URL: https://zeus.microcom.es:4040/index.html?zeus6=true . This issue affects ZeusWeb: 6.1.31.

microcom360

An attacker with access to the web application ZeusWeb of the provider Microcom (in this case, registration is required) who has the vulnerable software could introduce arbitrary JavaScript by injecting an XSS payload into the ‘Name’ and “Surname” parameters within the ‘My Account’ section at the URL: https://zeus.microcom.es:4040/administracion-estaciones.html  resulting in a stored XSS. This issue affects ZeusWeb: 6.1.31.

microcom360

Improper bound check within AMD CPU microcode can allow a malicious guest to write to host memory, potentially resulting in loss of integrity.

Improper handling of values in the microcode flow for some Intel(R) Processor Family may allow an escalation of privilege. Startup code and smm adversary with a privileged user combined with a high complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present with special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (low), integrity (low) and availability (none) of the vulnerable system, resulting in subsequent system confidentiality (low), integrity (low) and availability (none) impacts.

RIOT is an open-source microcontroller operating system, designed to match the requirements of Internet of Things (IoT) devices and other embedded devices. In version 2025.10 and prior, multiple out-of-bounds read allow any unauthenticated user, with ability to send or manipulate input packets, to read adjacent memory locations, or crash a vulnerable device running the 6LoWPAN stack. The received packet is cast into a sixlowpan_sfr_rfrag_t struct and dereferenced without validating the packet is large enough to contain the struct object. At time of publication, no known patch exists.

riot-os

ESPHome is a system to control microcontrollers remotely through Home Automation systems. In versions 2025.9.0 through 2025.12.6, an integer overflow in the API component's protobuf decoder allows denial-of-service attacks when API encryption is not used. The bounds check `ptr + field_length > end` in `components/api/proto.cpp` can overflow when a malicious client sends a large `field_length` value. This affects all ESPHome device platforms (ESP32, ESP8266, RP2040, LibreTiny). The overflow bypasses the out-of-bounds check, causing the device to read invalid memory and crash. When using the plaintext API protocol, this attack can be performed without authentication. When noise encryption is enabled, knowledge of the encryption key is required. Users should upgrade to ESPHome 2025.12.7 or later to receive a patch, enable API encryption with a unique key per device, and follow the Security Best Practices.

esphome

RIOT is an open-source microcontroller operating system, designed to match the requirements of Internet of Things (IoT) devices and other embedded devices. A vulnerability was discovered in the IPv6 fragmentation reassembly implementation of RIOT OS v2025.07. When copying the contents of the first fragment (offset=0) into the reassembly buffer, no size check is performed. It is possible to force the creation of a small reassembly buffer by first sending a shorter fragment (also with offset=0). Overflowing the reassembly buffer corrupts the state of other packet buffers which an attacker might be able to used to achieve further memory corruption (potentially resulting in remote code execution). To trigger the vulnerability, the `gnrc_ipv6_ext_frag` module must be included and the attacker must be able to send arbitrary IPv6 packets to the victim. Version 2025.10 fixes the issue.

riot-os

RIOT is an open-source microcontroller operating system, designed to match the requirements of Internet of Things (IoT) devices and other embedded devices. A vulnerability was discovered in the IPv6 fragmentation reassembly implementation of RIOT OS v2025.07. When receiving an fragmented IPv6 packet with fragment offset 0 and an empty payload, the payload pointer is set to NULL. However, the implementation still tries to copy the payload into the reassembly buffer, resulting in a NULL pointer dereference which crashes the OS (DoS). To trigger the vulnerability, the `gnrc_ipv6_ext_frag` module must be enabled and the attacker must be able to send arbitrary IPv6 packets to the victim. RIOT OS v2025.10 fixes the issue.

riot-os

In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Add RDSEED fix for Zen5 There's an issue with RDSEED's 16-bit and 32-bit register output variants on Zen5 which return a random value of 0 "at a rate inconsistent with randomness while incorrectly signaling success (CF=1)". Search the web for AMD-SB-7055 for more detail. Add a fix glue which checks microcode revisions. [ bp: Add microcode revisions checking, rewrite. ]

In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Add missing terminator for zen5_rdseed_microcode Running x86_match_min_microcode_rev() on a Zen5 CPU trips up KASAN for an out of bounds access.

In the Linux kernel, the following vulnerability has been resolved: mm: prevent poison consumption when splitting THP When performing memory error injection on a THP (Transparent Huge Page) mapped to userspace on an x86 server, the kernel panics with the following trace. The expected behavior is to terminate the affected process instead of panicking the kernel, as the x86 Machine Check code can recover from an in-userspace #MC. mce: [Hardware Error]: CPU 0: Machine Check Exception: f Bank 3: bd80000000070134 mce: [Hardware Error]: RIP 10:<ffffffff8372f8bc> {memchr_inv+0x4c/0xf0} mce: [Hardware Error]: TSC afff7bbff88a ADDR 1d301b000 MISC 80 PPIN 1e741e77539027db mce: [Hardware Error]: PROCESSOR 0:d06d0 TIME 1758093249 SOCKET 0 APIC 0 microcode 80000320 mce: [Hardware Error]: Run the above through 'mcelog --ascii' mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel Kernel panic - not syncing: Fatal local machine check The root cause of this panic is that handling a memory failure triggered by an in-userspace #MC necessitates splitting the THP. The splitting process employs a mechanism, implemented in try_to_map_unused_to_zeropage(), which reads the pages in the THP to identify zero-filled pages. However, reading the pages in the THP results in a second in-kernel #MC, occurring before the initial memory_failure() completes, ultimately leading to a kernel panic. See the kernel panic call trace on the two #MCs. First Machine Check occurs // [1] memory_failure() // [2] try_to_split_thp_page() split_huge_page() split_huge_page_to_list_to_order() __folio_split() // [3] remap_page() remove_migration_ptes() remove_migration_pte() try_to_map_unused_to_zeropage() // [4] memchr_inv() // [5] Second Machine Check occurs // [6] Kernel panic [1] Triggered by accessing a hardware-poisoned THP in userspace, which is typically recoverable by terminating the affected process. [2] Call folio_set_has_hwpoisoned() before try_to_split_thp_page(). [3] Pass the RMP_USE_SHARED_ZEROPAGE remap flag to remap_page(). [4] Try to map the unused THP to zeropage. [5] Re-access pages in the hw-poisoned THP in the kernel. [6] Triggered in-kernel, leading to a panic kernel. In Step[2], memory_failure() sets the poisoned flag on the page in the THP by TestSetPageHWPoison() before calling try_to_split_thp_page(). As suggested by David Hildenbrand, fix this panic by not accessing to the poisoned page in the THP during zeropage identification, while continuing to scan unaffected pages in the THP for possible zeropage mapping. This prevents a second in-kernel #MC that would cause kernel panic in Step[4]. Thanks to Andrew Zaborowski for his initial work on fixing this issue.

Improper cleanup in AMD CPU microcode patch loading could allow an attacker with local administrator privilege to load malicious CPU microcode, potentially resulting in loss of integrity of x86 instruction execution.

Incomplete cleanup after loading a CPU microcode patch may allow a privileged attacker to degrade the entropy of the RDRAND instruction, potentially resulting in loss of integrity for SEV-SNP guests.

ESPHome is a system to control microcontrollers remotely through Home Automation systems. In version 2025.8.0 in the ESP-IDF platform, ESPHome's web_server authentication check can pass incorrectly when the client-supplied base64-encoded Authorization value is empty or is a substring of the correct value. This allows access to web_server functionality (including OTA, if enabled) without knowing any information about the correct username or password. This issue has been patched in version 2025.8.1.

esphome

In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Prevent attempts to reclaim poisoned pages TL;DR: SGX page reclaim touches the page to copy its contents to secondary storage. SGX instructions do not gracefully handle machine checks. Despite this, the existing SGX code will try to reclaim pages that it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages. The longer story: Pages used by an enclave only get epc_page->poison set in arch_memory_failure() but they currently stay on sgx_active_page_list until sgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched. epc_page->poison is not checked in the reclaimer logic meaning that, if other conditions are met, an attempt will be made to reclaim an EPC page that was poisoned. This is bad because 1. we don't want that page to end up added to another enclave and 2. it is likely to cause one core to shut down and the kernel to panic. Specifically, reclaiming uses microcode operations including "EWB" which accesses the EPC page contents to encrypt and write them out to non-SGX memory. Those operations cannot handle MCEs in their accesses other than by putting the executing core into a special shutdown state (affecting both threads with HT.) The kernel will subsequently panic on the remaining cores seeing the core didn't enter MCE handler(s) in time. Call sgx_unmark_page_reclaimable() to remove the affected EPC page from sgx_active_page_list on memory error to stop it being considered for reclaiming. Testing epc_page->poison in sgx_reclaim_pages() would also work but I assume it's better to add code in the less likely paths. The affected EPC page is not added to &node->sgx_poison_page_list until later in sgx_encl_release()->sgx_free_epc_page() when it is EREMOVEd. Membership on other lists doesn't change to avoid changing any of the lists' semantics except for sgx_active_page_list. There's a "TBD" comment in arch_memory_failure() about pre-emptive actions, the goal here is not to address everything that it may imply. This also doesn't completely close the time window when a memory error notification will be fatal (for a not previously poisoned EPC page) -- the MCE can happen after sgx_reclaim_pages() has selected its candidates or even *inside* a microcode operation (actually easy to trigger due to the amount of time spent in them.) The spinlock in sgx_unmark_page_reclaimable() is safe because memory_failure() runs in process context and no spinlocks are held, explicitly noted in a mm/memory-failure.c comment.

linux · debian