AI Threat Brief: Brittle Foundations and Infrastructure Denial-of-Service

This week's security advisories expose fragility in the foundational technologies that support AI and automation. Two separate denial-of-service vulnerabilities in the popular vLLM inference engine highlight risks in shared AI infrastructure. A cross-tenant data exposure flaw in the n8n-MCP automation tool shows similar dangers in adjacent ecosystems. These specific software flaws are contextualized by a new report on AI's role in modern attacks and a zero-day chain affecting Siemens industrial hardware. The pattern is clear: a weak link in the underlying platform can create systemic risk for all services built on top.

n8n-MCP Flaw Exposes Cross-Tenant Workflow Data

A critical vulnerability in n8n-mcp, tracked as CVE-2026-54052, allowed for cross-tenant data access in certain deployments [17]. In multi-tenant HTTP configurations, an authenticated user could read workflow version backups belonging to other tenants.

The flaw also allowed an attacker to delete or destroy these stored backups [1].

The exposed data includes complete workflow snapshots. These snapshots can contain sensitive information, including credential references and authorization headers configured on nodes within a workflow [2]. This vulnerability therefore presents a risk to data confidentiality, integrity, and availability.

All versions up to and including 2.56.0 are affected [1].

The issue stemmed from the fact that locally stored workflow version histories were not isolated per tenant. A single server instance serving multiple tenants used a shared local store for these backups. The vulnerability does not impact single-user, stdio, or single-tenant HTTP deployments [2].

A patch is available in version 2.56.1, which isolates version history per instance [3]. For operators unable to upgrade immediately, workarounds include disabling the workflow versions tool or running each tenant on a separate instance.

The vulnerability was reported by researchers at Manifold Security [2].

vLLM Vulnerable to ReDoS via Malicious Regex Patterns

A Regular Expression Denial of Service (ReDoS) vulnerability was discovered in the vLLM inference engine [4].

The flaw, identified as CVE-2026-55574, allows an attacker to hang an inference worker indefinitely with a single malicious request [6]. This can cause a denial of service for other users of a shared vLLM instance.

The vulnerability exists because the `structured_outputs.regex` API parameter passes user-supplied regex strings to compiler backends without a compilation timeout [5]. The `xgrammar` and `outlines` backends are both vulnerable.

While the `outlines` backend performs some validation, it does not protect against patterns with nested quantifiers that can cause exponential state-space explosion during compilation [9].

An attacker can craft a simple but malicious regex pattern, such as `(a+)+b`, and submit it via the API. This pattern passes the existing structural checks but hangs the compiler. The worker process that receives the request becomes permanently unresponsive [5].

A patch adds a timeout to the compilation calls to mitigate the issue [7].

The fix was implemented by wrapping the calls in a thread with a deadline [8].

vLLM Engine Crashable via Invalid Token Reinjection

A second critical vulnerability in vLLM allows a remote attacker to crash the entire engine worker, causing a service-wide outage [10].

Tracked as CVE-2026-54234, this issue results from improper state handling during speculative decoding [12]. An attacker can trigger the flaw using a specific sequence of legitimate requests through the public gRPC interface.

The attack chain begins when a multi-request workload causes the speculative decoding process to produce a "recovered token" with a value equal to the model's vocabulary size [11]. This out-of-vocabulary value is then converted to -1.

The system incorrectly reinjects this -1 value back into the input ID buffer for the next processing step [10].

The root cause is the consumption of this invalid -1 token by the model's drafting or embedding path. This triggers a `device-side assert` on the GPU, which crashes the worker process [11]. Because the worker is shared, the crash aborts all concurrent requests and blocks new ones until the service is manually restarted.

The issue was demonstrated on vLLM version 0.17.1 [10].

A fix has been merged into the vLLM project to correct the state-handling logic [13].

The patch ensures that out-of-vocabulary recovered tokens are not selected as the next live token for a request [14]. Operators of shared vLLM deployments should apply this update to prevent remote denial-of-service attacks.

Zero-Day Chain Gives Root on Siemens OT Switches

Researchers from Palo Alto Networks published an analysis of three chained zero-day vulnerabilities in Siemens ROX II industrial switches [15]. These devices are widely deployed in Operational Technology (OT) networks that manage physical processes. A successful exploit allows an attacker to gain persistent root access to the switch.

Compromising network infrastructure in an OT environment represents a critical security failure. An attacker with root access on a core switch could potentially disrupt or monitor sensitive industrial control systems. The analysis provides a technical breakdown of the exploit chain, from initial access to privilege escalation and persistence [15].

The security of OT hardware is increasingly relevant as these systems become more connected and targeted by automated attacks. AI-driven tools can be used to discover and exploit such vulnerabilities at scale. This research highlights the importance of securing the foundational network layer upon which industrial and AI-driven systems depend.

Report Highlights AI's Role in Modern Attacks

Providing broader context, the Unit 42 2026 Global Incident Response Report explores the impact of AI and automation on the cybersecurity landscape [16]. The report offers perspectives on how these technologies are being adopted by both attackers and defenders. It analyzes real-world incident response data to identify key trends.

The findings detail how threat actors are using automation to accelerate attacks and exploit vulnerabilities more efficiently. For defenders, the report discusses how AI can enhance threat detection and response capabilities. This strategic analysis frames the specific infrastructure vulnerabilities seen this week as part of a larger technological shift in cybersecurity operations [16].

Common Threads: Infrastructure as the Battlefield

This week's incidents share a common focus on the fragility of shared infrastructure. The vulnerabilities in vLLM and n8n-MCP demonstrate how flaws in multi-tenant platforms can have cascading effects. A single malicious request to a shared AI or automation service can lead to widespread denial of service or data leakage, affecting all users.

The Siemens zero-day chain extends this theme from software to the physical hardware layer of OT networks. It underscores that foundational network devices remain high-value targets for attackers seeking deep system access. The Unit 42 report confirms this trend, showing how attackers use automation to exploit such vulnerabilities at scale. The security of any complex system is ultimately dependent on the integrity of each underlying layer.

Defender Takeaway

The vulnerabilities in vLLM and n8n-MCP are potent reminders of the risks inherent in multi-tenant systems. Default security boundaries are not always sufficient. Operators must actively manage dependencies and apply patches promptly, especially for internet-facing infrastructure that serves multiple clients. Teams should assume that any user-supplied input, from a regex string to a complex request sequence, will be weaponized.