Hardware-Security

Found this at 2 AM, reading ESP-TEE source I had no business reading. One line looked off. It was off by a single character. That character had re-opened a CVSS 9.3, inside the fix meant to close it. TL;DR Two sibling flaws in the ESP-TEE secure-service wrappers. Same code, opposite primitives. The write (CVE-2026-45328, CVSS 9.3 critical, CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H; the C:H term is the chained worst case, see the impact section). Its root cause is incomplete pointer validation. Espressif fixed it, then one omitted commit re-opened the write in v6.0.1: a single character, = instead of &= inside _ss_esp_tee_sec_storage_aead_encrypt(), dead-stores the five-term pointer-validation chain the moment aad_len != 0. A REE app points the iv argument into TEE M-mode memory; the TEE then calls esp_fill_random(iv, iv_len) before the AEAD body runs, writing attacker-length random bytes to the attacker-chosen TEE address. ...

Some bugs hide behind clever exploitation. This one is a memcpy with no length check, reachable before authentication, from any BLE radio in range. TL;DR CVE-2026-47773 (GHSA-77v6-cw9f-9whg). A missing bounds check in ArduinoBLE’s ATT write-request handler. When a client writes to a characteristic that requires encryption (the BLEEncryption permission) but the link is not yet AES-encrypted, ArduinoBLE stashes the pending write into a fixed 64-byte writeBuffer inside the global ATTClass object, to replay it once encryption is up. It copies the attacker-supplied value into that buffer with no length check. ...