Preface: Mercedes-Benz has integrated the Snapdragon Auto 5G Modem-RF platform directly into its newest vehicle architectures.

Porsche relies on Qualcomm hardware through a long-term, group-wide technology agreement between its parent company, the Volkswagen Group, and Qualcomm.

Ref: Qualcomm notified customers of a product design weakness (CVE-2026-25289) on May 4, 2026. The issue has been resolved.

Background: The Neighborhood Area Network (NAN) acts as the vital communication bridge in the middle of the smart grid. It links local smart meters to the central Wide Area Network (WAN).

Role and Function Data link: Connects home meters to utility control centers.

Two-way flow: Sends use data out and brings power rules in.

Grid support: Helps manage power use and check system health.

While ZigBee itself is rarely used in moving vehicles (due to handover and speed limitations), it is used to offload data from expensive 4G/5G networks for real-time monitoring using low-cost, low-power neighborhood networks (NANs). Instead of ZigBee, the automotive industry uses specialized low-cost, short-range wireless standards to build these neighborhood-level car networks. This is known as V2V (Vehicle-to-Vehicle) or V2I (Vehicle-to-Infrastructure) communication. They use DSRC (Dedicated Short-Range Communications) or ITS-G5 (which are based on IEEE 802[.]11p, a modified version of Wi-Fi), and more recently, PC5 / Sidelink C-V2X. When cars are stuck in traffic, parked in a residential neighborhood, or stopped at a red light, they form an ad-hoc local network (a NAN).

For Wi-Fi Neighbor Awareness Networking (NAN) / Wi-Fi Aware, management and service discovery frames do not have a single fixed “default” byte size. Instead, they rely on variable-length attribute payloads governed by the standard maximum IEEE 802[.]11 frame body limit of 2,304 bytes (and up to 2,346 total frame bytes including MAC headers).

Vulnerability details: CVE-2026-25289 is a stack-based buffer overflow / memory corruption flaw that occurs when processing “Device Capability Extended” attributes inside Neighbor Awareness Networking (NAN) service discovery frames. The vulnerability triggers when the parsing code blindly trusts an attacker-controlled length field from an incoming frame and copies data into a fixed-size stack buffer without verification.

Remedy: To mitigate CVE-2026-25289, you must apply the official August 2026 security patch or newer from your device vendor (such as updating Android or Qualcomm WLAN firmware components).

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

Preface: In Bouncy Castle Java, a Stapled OCSP (Online Certificate Status Protocol) response refers to a mechanism where an SSL/TLS server attaches a pre-fetched, digitally signed proof of its certificate’s validity directly into the TLS handshake. Instead of requiring the client (like a web browser or Java client application) to contact a third-party Certificate Authority (CA) to check if a certificate is revoked, the client reads the “stapled” status response provided immediately by the server.

Background: If the cryptographic flaw happens entirely within the user-space Java framework (Bouncy Castle/Conscrypt), why does your architecture slide map all the way down to the Kernel and the TEE/KeyMint TA? Doesn’t the TEE protect itself?

That is a crucial distinction. The TEE and KeyMint TA are cryptographically secure, but they operate on a ‘garbage in, garbage out’ model regarding external network state. The TEE handles hardware-bound keys and cryptographic operations, but it relies on the rich user-space Java layer to fetch, parse, and validate the transport-layer revocation status—like the stapled OCSP response. If the Bouncy Castle or Conscrypt validation engine tells the system a certificate is valid when it is actually revoked, the user-space daemon passes valid parameters down the stack. The architecture map highlights that a high-level logic flaw completely undermines our low-level hardware protections, making it a full-stack security concern.

If an attacker is leveraging a mismatched CertID from a completely different, valid certificate, wouldn’t the cryptographic signature on that OCSP response fail when checked against the target server’s certificate chain?

No, and that is exactly why this design weakness is so deceptive. The attacker intercepts the connection via a Man-in-the-Middle attack and presents a revoked certificate. However, they staple a valid OCSP response belonging to a completely different, legitimate website that happens to be signed by the same Intermediate Certificate Authority (CA). Because both certificates share the same issuer, the Bouncy Castle engine successfully verifies the CA’s signature on the stapled token and marks it cryptographically valid. Because the original code omitted the strict identity binding check between the token’s internal serial number and the server’s actual certificate serial number, the mismatch went unnoticed.

Vulnerability details: CVE-2026-58062 – In Bouncy Castle for Java before 1.85, Stapled OCSP response accepted without binding to the checked certificate. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).

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

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