Preface: Today, the average person spends seven to eight hours a day staring at electronic screens, creating a huge demand for computer glasses. The widespread adoption of remote work, online learning, and smartphones has transformed computer glasses from a niche accessory into an everyday necessity. By 2026, the computer glasses market will have officially evolved from a simple health accessory into a highly complex, multi-billion dollar industry. This year, the market is valued at over $2.1 billion and is experiencing rapid growth, driven by factors such as workplace culture, people’s extreme reliance on screens, and rapid technological advancements.

Background: The HLOS (Advanced Operating System) embedded or deployed on the Snapdragon AR1+ first-generation platform is custom-developed, with extensive modifications to the standard open-source baseline to meet the extreme constraints of ultra-light smart glasses. Qualcomm provides OEMs with highly customized, stripped-down Board Support Packages (BSPs) based on either a minimal Android Open Source Project (AOSP) core or a custom Yocto-based Linux platform. All unnecessary smartphone background services (like telephony, desktop rendering pipelines, and heavy UI frameworks) are completely removed. In modern cryptography (like AES-GCM or AES-CBC), the IV must be unique for every single encryption operation under the same key. Reusing an IV breaks the security guarantees of these modes, potentially exposing your plaintext data.

A failure in how Qualcomm’s internal handler performs AES-GCM key wrapping. Specifically, the platform was mistakenly using a static Initialization Vector (IV / Nonce) every time it wrapped a key.

Ref: When vulnerability occurs, an attacker has two ciphertexts generated with the same keystream, they can XOR them together to cancel out the keystream and expose the original plaintexts.

Here is how modern modes like AES-GCM and AES-CTR eliminate this vulnerability.

The Initialization Vector (IV) or NonceThe primary defense is the introduction of an IV (Initialization Vector) or a Nonce (number used once).

Unique Input: Before generating the keystream, the cipher mixes the secret key with the unique IV/Nonce.

Changing Keystream: Because the Nonce changes for every single message, the mathematical output (the keystream) changes completely, even if the secret key stays the same.

Vulnerability details:

CVE ID CVE-2026-21383

Title : Reusing a Nonce, Key Pair in Encryption in HLOS

Description : Cryptographic Issue when using a static initialization vector for AES-GCM key wrapping, which requires a unique value for each call to ensure security.

Official announcement: Please refer to the link for details – https://nvd.nist.gov/vuln/detail/CVE-2026-21383

Preface: mruby/c remains active in certain industry scenarios that require Ruby’s rapid development capabilities but are limited by hardware constraints that standard mruby (which requires more memory) cannot support. It is widely used in:

• Internet of Things (IoT) edge devices.

• Factory automation and industrial sensors (especially favored by Japanese engineering companies).

• Custom firmware requiring lightweight, high-efficiency script engines embedded in C code.

Background: Which type of IoT devices use mruby/c?

mruby/c is used in resource-constrained, battery-powered IoT devices that require concurrent tasks but lack the memory to run a full operating system. Because its virtual machine runs on as little as 20 KB of RAM, it is deployed in hardware environments where other high-level languages like MicroPython or standard mruby (which requires >100 KB) are too heavy.

When a method lookup fails across the normal inheritance chain, the virtual machine invokes a specialized, static “builtin fallback routine” inside mrbc_find_method(). Because the bytecode execution pointer (pc) or target ID array indexes are processed directly within the loop logic without an explicit boundary assertion check, malicious or unexpectedly formatted bytecode can trigger an out-of-bounds read.

Why does a microcontroller use a Virtual Machine? Unlike a system virtual machine (like VMware or VirtualBox) that emulates an entire computer system or operating system, a programming language VM (like the Java Virtual Machine or the mruby/c VM) acts as a software execution engine.

•               The Process: Your Ruby code is first compiled into bytecode.

•               The VM’s Job: The mruby/c VM reads this bytecode step-by-step and translates it into physical instructions the ESP32 chip can understand.

Vulnerability details: mrubyc through release3.4.1 was found to contain an out-of-bounds read in builtin missing-method lookup inside mrbc_find_method().

Remedy: If you are compiling custom firmware using embedded mruby/c, you can fix this risk by following the repository changes:

1.             Pull the official fixed code directly from the mruby/c GitHub repository.

2.             Recompile your source directory to ensure that both the mrbc_find_method() out-of-bounds read and any related macro handlers are updated on your target MCU.

Official announcement: Please refer to the link for details – https://www.tenable.com/cve/CVE-2026-38973

Preface: CIPster is an EtherNet/IP™ stack because it provides the software architecture required to implement the Common Industrial Protocol (CIP) over standard Ethernet, TCP, and UDP networks.

Background: CIPster is an open-source, EtherNet/IP™ stack written in C++.

• Its Role: It is maintained under the GitHub organization liftoff-sr. It allows a Linux-based device to emulate an industrial “slave/adapter” device.
• Its Scope: It only handles communication over EtherNet/IP (the Common Industrial Protocol or CIP, commonly used by Rockwell/Allen-Bradley PLCs). It does not natively handle cloud ingestion, database logging, or security protocols required for cloud routing.

To handle communication over EtherNet/IP, liftoff-sr/CIPster exposes an initialization and execution loop API. Because CIPster is a C++ port of the C-based OpENer stack, its implementation follows a structured lifecycle: initializing the adapter, registering assembly objects (I/O tags), and feeding data into a network socket service loop.

Vulnerability details: A vulnerability was detected in liftoff-sr CIPster up to e8e9dba09bf56962807d3504b783ccdb6287f3e4. Affected by this issue is the function BufWriter::append of the component EtherNet IP Message Handler. Performing a manipulation results in out-of-bounds write.

Impact: Remote exploitation of the attack is possible. The exploit is now public and may be used.

Recommendation: This product follows a rolling release approach for continuous delivery, so version details for affected or updated releases are not provided.

The patch is named 3a0159ed43125dcd024a1965f0289cb186bae9ff. To fix this issue, it is recommended to deploy a patch.

Official announcement: Please refer to the link for details – https://www.tenable.com/cve/CVE-2026-13592

https://github.com/liftoff-sr/CIPster/issues/48

Preface: Zephyr’s BSD-sockets are a networking API rather than a feature of a specific off-the-shelf industrial robot. Zephyr RTOS is used across embedded robotics in custom, edge-computing, and modular ROS 2 networks.

Background: Zephyr’s BSD Sockets API is a compact, optimized subset designed specifically for resource-constrained Real-Time Operating Systems (RTOS), unlike the complete, full-featured POSIX standard used in systems like Linux or macOS.

Zephyr’s API acts as the foundational hardware abstraction layer that allows high-level distributed coordination systems like Lingua Franca to control microcontrollers. It translates high-level logical commands into real-time, hardware-specific actions across physical nodes without the developer needing to manage complex, low-level concurrency.

Unlike standard desktop operating systems that frequently allocate and duplicate memory dynamically for DNS data, Zephyr utilizes a linked list struct zsock_addrinfo tied directly to the native net_buf (network buffer) infrastructure. This minimizes heap allocations and reduces overall RAM overhead.

Vulnerability details: The core trigger for this vulnerability is actually “Timeout followed by a Retry.” When the semaphore wait times out, getaddrinfo() returns an -EAGAIN error and immediately initiates a second retry query. When doing so, it overwrites ai_state->dns_id. This turns the first query into an un-cancellable “orphan query” lingering in the system workqueue (sysworkq).

Ref: A semaphore timeout (or “Semaphore Timeout Period Has Expired” error) is a system alert indicating that a program or device failed to complete a data transfer or process within the time allotted by your computer’s operating system.

If you are developing on Zephyr versions v4.0.0 through v4.4.0, ensure you pull the latest patch for CVE-2026-10646, which specifically addresses a known memory bug inside this internal getaddrinfo/dns_resolve_cb semaphore flow during extreme timeout conditions.

Note: If a late, delayed DNS response arrived over UDP (or if the resolver’s internal timeout work queue triggered), dns_resolve_cb() executed against that stale stack pointer. An attacker could spoof the 16-bit transaction ID over the network to overwrite critical memory areas, causing a system crash or remote code execution.

Official announcement: Please refer to the link for details – https://www.tenable.com/cve/CVE-2026-10646

Preface: On March 31, 2026, a researcher affiliated with Positive Technologies posted that he had “extracted the Global Wrapping Key from an instance of Intel Gemini Lake Platform.”

While researchers have identified foundational design weaknesses and supply chain risks in Secure Boot and key handling, there are no known instances of Intel KEK design flaws being actively exploited in the wild for widespread attacks.

Background: The Intel Gemini Lakes platform remains actively used by the industry in 2026, but only as traditional, long-lived embedded infrastructure, not for manufacturing new products. Although Intel officially completed the end-of-life (EOL) processes for Gemini Lakes and Gemini Lakes Refresh Silicon in 2024, the platform is still widely used in operational environments due to the exceptionally long operational life cycles of commercial systems.

Active Industry Use Cases in 2026

You will still find Gemini Lake chips (like the Celeron N4100 or J4125) actively working in several industries:

• Industrial Automation & Thin Clients
• Network & Edge Gateways
• Network Attached Storage (NAS)

In Intel’s chip design, the Global Wrapping Key (GWK) is burned directly into the chip’s internal fuse during manufacturing. [1] • It is not an open software feature: Intel does not provide any API for operating systems, drivers, or applications to call the GWK. • Its sole function: When an IoT device is powered on, the processor automatically uses the GWK to decrypt the firmware and initialize the chip’s internal security engine (such as the root key for Intel CSME and SGX).

Cybersecurity researchers (Maxim Goryachy et al. from Positive Technologies) discovered a hardware logic flaw in Intel chips regarding the management of debugging permissions. Probe Mode should normally be locked on retail chips, but the researchers successfully exploited a specific vulnerability (such as controlling the timing of microcode loading) to forcibly activate Probe Mode before the hardware locked the debugging interface.

Vulnerability details: On March 31, 2026, a researcher affiliated with Positive Technologies posted that he had “extracted the Global Wrapping Key from an instance of Intel Gemini Lake Platform.”

Based on Intel analysis, the activity appears to extend previously addressed research. The researcher previously indicated that they were running tests on systems they have physical access to, which are not up to date with the latest mitigations and are not properly configured with Intel recommended Flash Descriptor write protection (which occurs as part of end of manufacturing by system manufacturers). Researchers are using previously mitigated vulnerabilities dating as far back as 2017 to gain access to an Intel Unlocked state (aka “Red Unlocked”). See “Additional Resources” for technical papers describing these issues. 

In this latest posting, the researcher claims to have additionally identified a Global Wrapping Key, which is used to decrypt the device-specific Intel® Software Guard Extensions (Intel® SGX) key. This specific issue only impacts Intel Gemini Lake and Gemini Lake Refresh platforms using Intel SGX including products that have exited baseline servicing. Intel® Trust Domain Extensions (Intel® TDX) is not affected.

Official announcement: Please refer to the link for details – https://www.intel.com/content/www/us/en/security-center/announcement/intel-security-announcement-2026-04-08-001.html

Preface: AMD Versal™ AI Edge Series Gen 2 adaptive SoC – These heterogeneous devices are designed to accelerate end-to-end processing (from raw sensor ingestion to AI inference and post-processing) on a single chip. They are built specifically for power and area-constrained embedded systems targeting automotive, aerospace, industrial, and healthcare markets.

Background: In the AMD Versal™ AI Edge Series Gen 2 architecture, the combination of Stage-1 Translation, Stage-2 Translation, and Granule Protection Table (GPT) checks is required to establish Hardware-based Security (Confidential Computing) and Functional Safety (ASIL D / SIL 3).

These three layers of memory management and protection map to specific responsibilities in modern heterogeneous systems:

• Stage-1 Translation (Virtual to Intermediate Physical Address): Handled by the OS or hypervisor within the Arm CPUs to provide memory virtualization, isolation between user applications, and process-level memory management. [1]
• Stage-2 Translation (Intermediate Physical to Physical Address): Handled by the hypervisor to manage virtual machines. It ensures guest operating systems can only access the memory regions explicitly allocated to them.
• Granule Protection Table (GPT) Protection: Because the Versal device has a highly interconnected heterogeneous architecture (CPUs, GPUs, AI Engines, and Programmable Logic), standard MMUs are not enough to protect memory mapped into non-CPU components. GPTs act as a final “hardware gatekeeper” for the physical memory map. They ensure that an untrusted block in the Programmable Logic (FPGA fabric) or a specific AI Engine tile cannot access or overwrite memory assigned to secure/realm OS environments.

Ref: ASIL D (Automotive Safety Integrity Level) and SIL 3 (Safety Integrity Level) are the highest standard requirements for safety-critical systems in the automotive and general industrial sectors, respectively. While they demand equally rigorous risk reduction, they originate from different regulatory frameworks.

Vulnerability details: CVE-2025-10263 According to the ARM^® security team, a broadcast Translation Lookaside Buffer Invalidate (TLBI) on another Processing Element (PE) may be completed before affected memory accesses are globally observed. This may permit bypass of Stage 1 translation, Stage 2 translation, or Granule Protection Tables(GPT ) protection.

Official announcement: Please refer to the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-8021.html

Preface: The Snapdragon X55’s hardware security architecture, utilizing ARM TrustZone, provides a system-wide, hardware-enforced isolation mechanism designed to protect critical assets by creating a separate “Secure World” (Trusted Execution Environment – TEE).

Background: Industrial IoT manufacturers are using the Snapdragon X55 processor in their industrial 5G cellular gateways to provide secure, high-speed connectivity for industrial customers. What is the connection between CVE-2026-25276 and the industrial sector? The following is a detailed account of the evolution of the cyberattack chain.

Once attackers gain control of the gateway’s local system (e.g., Linux space) via a web interface, they can monitor network traffic but cannot access the most critical assets. This is because the Snapdragon X55’s hardware security architecture (ARM TrustZone) forcibly isolates the following critical data:

• Device root credentials and encryption keys (TLS private keys used for secure communication between the IIoT gateway and the cloud PLC).

• A cryptographic hash of the OEM/Manufacturer’s public key is permanently burned into the Snapdragon X55’s hardware eFuses via Qualcomm’s Fuse-Programmable Read-Only Memory (QFPROM).

Therefore, attackers must launch a second-stage attack, exploiting local vulnerabilities like CVE-2026-25276 to allow code that would normally run on a normal system to arbitrarily corrupt the memory space of the security processor. Once the security processor crashes or is compromised due to out-of-bounds read/write operations, the entire industrial gateway’s “hardware root of trust” is completely destroyed.

Remark: The hardware security architecture does forcibly isolate critical data from the main operating system, but this isolation is achieved via ARM TrustZone.

Security Focus: Please refer to the remedy code in the attached diagram (point 5). The C++ implementation using if-else bounds checking. It uses std::array to prevent dynamic memory fragmentation on your IoT gateway.

Furthermore, it also do the remedy in below circumstances.

•               No try-catch: Fully compatible with embedded toolchains that use -fno-exceptions.

•               Stack Allocated: Uses std::array instead of std::vector, meaning zero heap allocation fragmentation.

•               Defensive Failure Mode: Instead of printing a generic error, it actively stops execution path processing and returns a failure code (-1).

Vulnerability details:

CVE ID – CVE-2026-25276

Title – Improper Validation of Array Index in Secure Processor

Description – Memory corruption while using Strongbox due to missing bounds check.

Technology Area – Secure Processor (Qualcomm)

Vulnerability Type – CWE-129 Improper Validation of Array Index

Official announcement: Please refer to the link for details – https://docs.qualcomm.com/securitybulletin/june-2026-bulletin.html

Preface: You can find Ryzen inside:

• Industrial IoT Gateways: Factory machines that handle massive amounts of real-time data.
• Digital Signage & Kiosks: Large public screens and interactive maps in malls or airports.
• Smart Medical Devices: High-end medical imaging and hospital machines.
• Automotive AI: Modern digital car cockpits and self-driving machine systems.

AMD Ryzen Embedded R2000 Series Processors are highly capable, power-efficient System-on-Chips (SoCs) frequently leveraged in autonomous driving, mobile robotics, and ADAS (Advanced Driver Assistance Systems). They function primarily as the central compute brains for vehicle sensor data processing and digital cockpit controls.

Background: Normally, a chip doesn’t need to be desoldered to be updated. An administrator (or an attacker) can use a tool like flashrom inside Linux to talk directly to the motherboard’s built-in SPI controller to read or write to the BIOS chip.

Under normal conditions, hardware security rules called System Management Mode (SMM) ROM protections lock down the SPI controller. Even if you have root access in Linux, the hardware will block flashrom from rewriting critical, protected areas of the BIOS.

CVE-2022-23829 is the exact flaw that breaks this safety net:

• It allows an attacker who already has Ring 0 (kernel-mode / root) access in Linux to bypass that hardware lock.
• Because of this bypass, tools like flashrom or a custom driver can write untrusted or malicious data directly onto the soldered Flash SPI ROM chip.

Once the attacker uses flashrom method to place the malicious data on the chip, the chain reaction on the left side of your image begins:

1.             The Flash SPI ROM Memory Chip now holds the malicious data.

2.             The AMD Secure Processor (ASP) boots up early and automatically reads this data.

3.             Because of a missing size check (insufficient bounds check), the malicious data overflows the processor’s tiny 256-byte buffer, corrupting the memory.

4.             By the time the Main Host x86 Cores wake up to run the standard boot sequence, the system has already been compromised.

Vulnerability details: The Root Cause of CVE-2025-29951 – Official security analysis from AMD Security Bulletin SB-4013 confirms that CVE-2025-29951 lives inside the early AMD Secure Processor (ASP) bootloader.

When the system boots up, the ASP parses external configuration tables and firmware parameters passed from the SPI flash chip. The bootloader copies an input block into a fixed-size local stack variable but fails to perform a boundary length check. An attacker with local access can pass a malicious, oversized table that spills out of the stack variable, allowing them to hijack the execution flow and escalate system privileges.

Official announcement: Please refer to the link for details – https://nvd.nist.gov/vuln/detail/CVE-2025-29951

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-4013.html

Preface: IoT manufacturers are very willing to use lwIP (Lightweight IP) in firmware, and it is widely used in commercial IoT products. It is a dominant TCP/IP stack in the embedded space because it provides a full-featured networking stack (TCP, UDP, DHCP, DNS) while being highly optimized for resource-constrained, low-power devices.

Even though firmware allocate an lwIP pbuf to hold the payload in RAM

[// PBUF_TRANSPORT automatically reserves space for UDP/IP headers]

If your firmware explicitly uses SNMPv3 alongside your Wake-on-LAN feature, you must apply the patch.

Background: Inbound parsing and outbound allocation are two completely different memory directions (see below):

Outbound – When you call pbuf_alloc(PBUF_TRANSPORT, …), you are allocating memory for an outgoing packet. This works perfectly and securely for transmitting your Magic Packet.

Inbound – When an SNMPv3 management command comes into your device, lwIP allocates an incoming pbuf automatically to hold the raw network packet. The vulnerability happens after allocation, during the parsing phase inside snmp_msg[.]c.

Why CVE-2026-8836 Bypasses Pbuf Protection

The flaw is a stack-based buffer overflow, not a pbuf heap overflow.

i.When a remote user sends an SNMPv3 packet, the function snmp_parse_inbound_frame sets up a fixed-size array on the CPU stack called request->msg_authentication_parameters. This buffer is hardcoded to a maximum size of SNMP_V3_MAX_AUTH_PARAM_LENGTH (usually 32 bytes).

ii.The unpatched code uses the variable tlv.value_len (which comes directly from the untrusted incoming packet header) to decide how many bytes to decode into that stack array.

iii.An attacker can craft a malicious SNMPv3 packet stating that the authentication data is 100 bytes long. Because the check was commented out (/* IF_PARSE_ASSERT(…) */), lwIP blindly executes snmp_asn1_dec_raw and writes all 100 bytes into the 32-byte stack buffer, smashing the CPU stack, corrupting the return address, and crashing your chip or allowing remote code execution.

Vulnerability details: A vulnerability was found in lwIP up to 2.2.1. Affected is the function snmp_parse_inbound_frame of the file src/apps/snmp/snmp_msg.c of the component snmpv3 USM Handler. Performing a manipulation of the argument msgAuthenticationParameters results in stack-based buffer overflow. The attack may be initiated remotely.

Remedy: The patch is named 0c957ec03054eb6c8205e9c9d1d05d90ada3898c. It is suggested to install a patch to address this issue.

Official announcement: Please refer to link for details –

https://nvd.nist.gov/vuln/detail/CVE-2026-8836