CVE-2026-10646 – Use-After-Return in Zephyr BSD-Sockets contains design weakness (30-6-2026)

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

CVE-2026-53311: A memory handling vulnerability in the FUSE subsystem of the Linux Kernel. (2026-06-29)

Preface: KMSAN (Kernel Memory Sanitizer) was developed by Google. It is a dynamic error detector for the Linux kernel that finds uninitialized memory accesses.

Background: The main feature of fuse_dentry_revalidate() in Linux is to verify and refresh the validity of a directory entry (dentry) and its associated inode in the kernel’s cache before they are used. It bridges the gap between the kernel’s Virtual File System (VFS) and the userspace FUSE daemon.

The frequency of fuse_dentry_revalidate() calls in an HPC process is highly frequent and scales directly with metadata-intensive file operations. In a typical High-Performance Computing (HPC) workload, this function can be triggered millions of times per second, often becoming a major performance bottleneck due to excessive network round-trips to the storage server.

The Linux Kernel VFS (Virtual File System) calls fuse_dentry_revalidate() every time a process attempts to look up, open, or stat a file path to verify if the cached directory entry (dentry) is still valid.

HPC applications frequently invoke this function due to specific behavioral patterns:

  • Massive File Scanning: MPI jobs searching through deep directory structures or loading millions of small shared data files.
  • Shared Library Loading: Thousands of parallel processes concurrently running ld.so, which searches LD_LIBRARY_PATH and issues repetitive stat() and open() calls on shared files (e.g., Python workloads loading packages like NumPy).
  • N-to-N File Access: Multiple compute nodes constantly polling or reading files created by other nodes, forcing the kernel to re-validate the cache.

Vulnerability details: CVE-2026-53311 is a memory handling vulnerability in the FUSE (Filesystem in Userspace) subsystem of the Linux Kernel. The primary impact is system availability loss and potential internal kernel memory disclosure.

Attack Vector: Exploitation requires local access. An attacker must be able to mount a FUSE filesystem or trigger fuse_dentry_revalidate through file operations like opening a path.

How to Mitigate:Update Kernel: The issue is resolved by upgrading your Linux kernel to 6.18.34, 7.0.10, or applying the upstream patch across applicable stable releases.

Official announcement: Please refer to the link for detailshttps://www.tenable.com/cve/CVE-2026-53311

CVE-2026-52966: A design flaw in the Linux kernel direct rendering manager (DRM). Don’t underestimate it! (26th Jun 2026)

Preface: Syzbot is an automated testing system operated by Google that continuously tests the Linux kernel to discover hidden bugs, crashes, and security vulnerabilities. It runs a public Syzbot control panel that lists all active bugs, helps developers track fix progress, and sends crash reports directly to Linux community mailing lists.

Background: Linux kernel’s Direct Rendering Manager (DRM) is deeply connected to both the GPU shader cores and the rendering process. It acts as the “traffic cop” and resource manager for your graphics hardware.

The details below are an expansion of the remedies associated with the infographic in this article.

idrobj = idr_replace(&file_priv->object_idr, obj, handle);

idr is the mechanism used in the Linux core to map integer IDs (such as handle) to indicators (such as obj). Idr_replace will replace the old object originally mapped at the handle position with the new obj (obj here is usually NULL, which means releasing or clearing the mapping). Return value: This function returns the old indicator originally stored at this location. If the replacement is successful and was originally empty, NULL should be returned.

spin_unlock(&file_priv->table_lock);

Function: Release the spinlock (Spinlock). Technical details: table_lock is a protection lock set to prevent multiple execution threads from modifying the IDR table at the same time. After modifying the table (executing idr_replace), it must be unlocked immediately so that other threads can access the table.

WARN_ON(idrobj != NULL);

Function: Error checking and warning. Technical details: This is a core debugging mechanism.

Vulnerability details: CVE-2026-52966 is a logic bug in the Linux kernel . It happens when the system accidentally mixes up the old and new addresses of an internal tracking object . This specific mistake occurs during the DRM (Direct Rendering Manager) driver’s “change handle” process.

The Result: The system gets confused, causing system stability issues (like crashes or errors).

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

CVE-2026-55447: A critical security vulnerability in the AI workflow platform Langflow versions prior to 1.9.2  (25th June 2026)

Preface: AI models do not use Langflow to generate or write code for you. When a large language model (like ChatGPT, Claude, Gemini, or specialized coding assistants) writes code in response to your prompts, it uses its own internal neural network, parameters, and training data.

The relationship between AI and Langflow is actually the exact opposite: human developers use Langflow to build, connect, and manage AI models.

Background: Langflow is an open-source, visual low-code framework specifically built to design, prototype, and deploy Artificial Intelligence (AI) workflows, multi-agent systems, and Retrieval-Augmented Generation (RAG) applications. It functions as a visual orchestration layer that abstracts complex Python AI code into drag-and-drop components.

Langflow features an embedded AI sidekick called the Langflow Assistant. The coolest part about this feature is its “inception-style” architecture: the Langflow Assistant is actually powered by a hidden Langflow graph running behind the scenes on your local server. When you ask it a question or give it a command, it runs an internal AI flow to alter or build the external AI flow you are working on.

When developers use Langflow, the strongest and most effective type of coding is Python-based integration, data orchestration, and AI pipeline customization.

Security Focus: Langflow is a tool for building and deploying AI-powered agents and workflows. Prior to 1.9.2, by controlling a files that are digested into the RAG, an attacker can direct the node to read any file on the file-system by absolute path. All components based on BaseFileComponent are vulnerable to the vulnerability.

Ref: Controlling the files ingested into a Retrieval-Augmented Generation (RAG) pipeline means curating, filtering, and optimizing your source data before it is processed by the search and language models.

This process directly dictates the quality of your AI’s responses and prevents the system from “hallucinating” or wasting resources on irrelevant noise.

Affected Nodes on Your Canvas

Any flow using the following visual components prior to version 1.9.2 is vulnerable:

  • Read File (FileComponent)
  • Docling nodes (DoclingInlineComponent, DoclingRemoteComponent)
  • NVIDIA Retriever Extraction (NvidiaIngestComponent)
  • Video File (VideoFileComponent) Unstructured API (UnstructuredComponent)

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

CVE-2026-56412: Use After Free occurs in libexpat before 2.8.2 (24th June 2026)

Preface: The primary machine learning tools and libraries that rely on libexpat include: OpenCV, GDAL / OGR, Apple Core ML Tools, Apache Spark / PySpark, ROS / ROS 2 (Robot Operating System) and Python AI Ecosystem.

Background: Primary machine learning (ML) tools and libraries rely on libexpat because it serves as the underlying engine for fast, memory-efficient XML parsing within Python, which is the dominant programming language for ML development.

Machine learning requires processing massive datasets, often distributed via structured XML-based formats (like Wikipedia dumps, Annotated Image Pascal VOC files for computer vision, or clinical medical notes).

The libexpat Solution: It is a stream-oriented (SAX-like) parser. It processes XML documents sequentially in tiny chunks (events), allowing ML data pipelines to extract and stream features on the fly without running out of memory.

Machine learning models are trained and deployed across highly diverse environments—from Linux-based GPU cloud clusters to Windows workstations and edge devices. libexpat is a light, stable C99 library with virtually no external dependencies. This makes it effortless to package, compile, and distribute across any operating system alongside primary ML wheels.

Ref: If a specific version of your ROS 2 environment compiles urdfdom with an unpatched version of libexpat, the system is still vulnerable to CVE-2026-56412.

CVE-2026-56412 is a Use-After-Free (UAF) vulnerability. Even though a developer uses a “safe” API wrapper, if urdfdom passes a maliciously crafted URDF XML file to an unpatched libexpat, the resulting memory corruption happens within the process’s shared memory space. This can still crash the ROS node or lead to arbitrary code execution.

Vulnerability details: libexpat before 2.8.2 does not consider XML_TOK_DATA_CHARS in doCdataSection and thus lacks handler call depth tracking for various calls from within handlers in cases of a policy violation. Thus, a use-after-free can occur. NOTE: this issue exists because of an incomplete fix for CVE-2026-50219.

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

CVE-2026-12773: A weakness has been identified in BerriAI litellm up to 1.59.8. (23rd Jun 2026)

Preface: LiteLLM is widely deployed by AI platforms because it provides a free, open-source proxy that unifies access to over 100 LLMs (like OpenAI, Anthropic, and local models) under a single OpenAI-compatible API format. It simplifies multi-model integration while enabling enterprise-grade cost tracking, spend limits, and rate limiting.

Background: LiteLLM (BerriAI) uses user_api_key_auth[.]py to handle backend API key validation, user tracking, and model permission routing. To implement custom authentication, you write a Python script with a user_api_key_auth(request, api_key) function and pass the file path to your proxy configuration.

About Auth Workflow When a request arrives at the proxy, the workflow follows these steps:

Request Interception: The proxy receives the HTTP request (e.g., /v1/chat/completions) and inspects the Authorization: Bearer <api_key> header.

Custom Verification: LiteLLM runs the user_api_key_auth function defined in your custom script. This function checks the <api_key> against an external database, a hardcoded master key, or a third-party auth service.

Pydantic Object Return: On success, your function returns a UserAPIKeyAuth Pydantic object (which tracks user limits, key max budgets, and allowed models).

Policy Enforcement: If configured, the proxy enforces rate limits, model allowlists, and per-model spending budgets before passing the request to the LLM provider

Ref: A Pydantic object return refers to configuring a Python function, API framework, or AI framework to output structured data in the form of a validated Pydantic model instance.

Security Advisory: CVE-2026-12773 (LiteLLM Proxy Auth Bypass)

  • The Issue: Versions of BerriAI LiteLLM up to 1.59.8 contain a weakness in the custom proxy authentication handler. If post-custom checks are disabled, broken custom scripts can lead to financial and structural compromise via key theft or cross-environment token reuse.
  • The Impact: Attackers can bypass request controls, map backend routes, and orchestrate Denial of Wallet (DoW) attacks by draining upstream AI balances.

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

CVE-2026-45617: Design weakness of LiquidJS

Publication date of this article: June 22, 2026

Preface: Liquid[.]js (LiquidJS) is not a machine learning framework or artificial intelligence library; it is a JavaScript implementation of the Liquid template language. Liquid was originally created by Shopify for loading dynamic content on store pages. However, due to its widespread use in building web interfaces and handling automated processes, it has been combined with machine learning and artificial intelligence in several specific ways.

Background: In a typical web application, LiquidJS runs first to build the skeleton of the page, and JavaScript runs second to make that skeleton come alive.

  1. Step 1 (Server): LiquidJS parses an HTML file, injects a user’s name from a database into a template, and outputs a flat HTML string.
  2. Step 2 (Network): The server sends this flat HTML across the internet to the user’s device.
  3. Step 3 (Browser): The browser displays the HTML and encounters a <script> tag. It then executes the JavaScript code to handle interactive menus or popups on that page.

The developer of LiquidJS included the regex purely to implement a built-in convenience filter called strip_html.

To do this lightweight operation quickly without adding heavy HTML parsing libraries, the developer used the exact regex alternation pattern.

/<script[\s\S]*?<\/script>|<style[\s\S]*?<\/style>|<[\s\S]*?>|<!–[\s\S]*?–>/g

Attackers can exploit the generic |<[\s\S]*?>| group using malformed attributes that regex cannot naturally handle.

Vulnerability details: Because LiquidJS runs directly on the Node.js backend of these cloud apps, the flawed regex becomes a critical threat vector. Node.js is single-threaded. When a backend server processes an unclosed string like <script<script… using that flawed regex, the CPU hits 100% trying to calculate the infinite backtracking possibilities. A single bad request can freeze the entire server thread for over 10 seconds, creating an easy, unauthenticated Denial of Service (DoS) exploit. This is so called Event Loop Blocking (ReDoS).

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

CVE-2026-48797: Reflex WebSocket Unauthenticated Training Vulnerability (19th June 2026)

Preface: Backpropagation is not used by a single specific robot, but rather by deep learning architectures and neural network controllers powering many modern autonomous systems. It is the foundational training algorithm used for everything from autonomous wheeled robots and robotic arms to industrial mobile robots.

Background: Backpropagate is a Python library for fine-tuning large language models on a single GPU.

The backpropagate library bundles Reflex as an optional web UI component. The BACKPROPAGATE_UI_AUTH variable fails because it is an application-specific environment variable for the backpropagate library, not a native Reflex configuration. While the backpropagate CLI exports this variable to subprocesses, its underlying Reflex application code lacks the necessary request guards, middleware, or WebSocket checks to read and enforce it.

FastAPI app managed by Reflex. Because Reflex establishes persistent WebSockets to manage state updates and actions, simply blocking standard HTTP requests is not enough; you must intercept the WebSocket connection handshake.

Ref: Does The BACKPROPAGATE bundle Reflex ?

Yes, the backpropagate library bundles Reflex as an optional web UI component. It uses Reflex to provide a local training control plane where you can upload datasets, start or stop model fine-tuning, orchestrate multi-runs, and push models to Hugging Face.

Vulnerability details: Anyone with simple network access to the Web UI port can connect over WebSockets and bypass security entirely to:

Hijack Training: Remotely trigger arbitrary AI training scripts or alter model weights.

Exfiltrate Data: View or steal private training datasets and path locations.

Tamper with Assets: Export internal GGUF formats or unauthorizedly push models straight to the Hugging Face Hub.

Cause Denial of Service (DoS): Overwhelm and crash host environments by filling up local server disk space with junk data.

Remedy:

Permanent Solution: Update the library to backpropagate version 1.2.0 or later, which formally implements the backend security check.

Temporary Workaround: Inject a standard FastAPI authentication middleware class directly into the application server stack to intercept and enforce HTTP Basic authentication checks on the /_event WebSocket endpoint before Reflex maps it.

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

CVE-2026-24252: NVIDIA NeMo for Linux contains a vulnerability where an attacker may cause OS command injection (18th June 2026)

Preface: NVIDIA NeMo is a widely adopted, end-to-end framework for building, customizing, and deploying generative AI models (LLMs) and conversational AI agents. It is primarily used to tailor open-source models—such as Llama, Mistral, and Google Gemma—using proprietary enterprise data.

Ollama, Mistral, and Google Gemma represent a powerful ecosystem for running local, open-weight Large Language Models (LLMs). Ollama acts as the engine to run models, while Mistral and Gemma are two of the most popular, high-performing model families designed to be efficient enough to run on personal computers.

Ollama itself does not use Nvidia NeMo; Ollama is an open-source runtime designed to pull, manage, and run LLMs (like Llama, Mistral, and Gemma) locally on consumer hardware. However, Mistral and Google actively collaborate with Nvidia, meaning their models frequently utilize Nvidia’s NeMo framework and are accessible via tools like NVIDIA NIM.

Background: A model_weights[.]ckpt file is a checkpoint file that stores the learned parameters (weights and biases) of a neural network. When serialized using Python’s pickle module, the file contains a bytecode payload representing the pickled Python dictionary of arrays, which poses arbitrary code execution risks during deserialization.

The attached infographic details CVE-2026-24252, a critical security vulnerability that could lead to operating system command injection in NVIDIA NeMo for Linux.

How the Exploit Works

  1. Malicious file creation: Attackers package custom code into [.]nemo checkpoints.
  2. Abusing Pickle: They use Python’s __reduce__ method.
  3. Command payload: This method embeds arbitrary shell commands.
  4. Target execution: The victim opens the file locally.
  5. Deserialization trigger: NeMo calls pickle[.]load() automatically.
  6. System compromise: The OS executes the injected command immediately.

Vulnerability details: CVE-2026-24252 NVIDIA NeMo for Linux contains a vulnerability where an attacker may cause OS command injection. A successful exploit of this vulnerability may lead to code execution, data tampering, escalation of privileges and information disclosure.

Remedy: Modern versions of PyTorch and NeMo mitigate this by passing weights_only=True to the loading mechanism. This instructs the deserializer to strictly accept only raw data arrays (like your original np[.]random[.]randn arrays) and explicitly reject any custom Python classes or executable instructions.

Official announcement: Please refer to the link for details – https://nvidia.custhelp.com/app/answers/detail/a_id/5839

Retrospective – Design weaknesses of fantastic IoT 4.0. 17th Jun 2026

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