Issue #1 · 12 October 2026

The config file is the attack surface

Your MCP settings can run code, your guardrail reads text differently from your model, and the EU moved its high-risk deadline.

Illustration: an MCP server setting whose command field runs an attacker's script

Welcome to the first SecureLLM.ai briefing: one incident taken apart, one attack technique, what changed in compliance, and one defense worth your time, every week.

⚡ This week in 60 seconds

🛡️ Incident Report

The short version: on Langflow, an ordinary login is enough to run any command on the server, and attackers are doing it now.

How a regular Langflow login becomes a shell: the four steps from the advisory, what the honeypots saw, and the key numbers

What happened. Langflow, the open-source platform for building AI apps and agents, has a critical flaw: CVE-2026-105740, CVSS 9.9, affecting versions before 1.9.0. Previdian's honeypots have counted exploitation attempts since 19 September: 1,423 from 27 IP addresses at first, rising to 1,706 from 28 addresses by 15 October, with 333 on 11 October alone. (The Hacker News)

How it works. Langflow lets users register MCP (Model Context Protocol) servers, the plug-ins that give an agent its tools. A server registered over STDIO is just a command to run, and Langflow passed the user's command field straight to bash -c with no validation, allowlist or sandbox. The vulnerability advisory describes the attack like this:

  1. Log in as any regular, non-admin user.
  2. Register a "server" whose command is a reverse shell.
  3. Load the server list, which runs it.
  4. It's saved in project settings, so it runs again every time the list loads, and it doesn't show up in a normal review of the flows.

What attackers actually did, on Previdian's honeypots: they checked the Langflow version, tried /api/v1/auto_login (switched off on the honeypot), logged in with a common username and password, then tried to read LANGFLOW_SECRET_KEY and LANGFLOW_SUPERUSER_PASSWORD and send them to an outside server, and ran Docker commands to reach the host's files.

An MCP settings screen is an admin console that runs code. Most AI tools don't treat it like one.

Why it keeps happening. In April, OX Security found the same pattern across the AI ecosystem: MCP STDIO configurations whose command and args reach the operating system unchecked. It listed critical or high-severity CVEs in more than a dozen products, including:

Allowlists didn't help. Upsonic and Flowise allowed only python, npm and npx, but npx -c <command> runs anything. OX traces the root cause to Anthropic's MCP SDK, which hands STDIO configurations to the operating system as they are. Anthropic, LangChain, FastMCP and several others declined to change their code, with reasons including that the behavior is by design and that sandboxing limits the damage. (OX Security, 15 April)

And a quieter one. CVE-2026-45609 in Spring AI's mcp-security library (before 0.1.9) lets an unauthenticated attacker make the server fetch a URL of their choice, such as a cloud metadata address, but only when Dynamic Client Registration is switched on. Rated 6.5, Medium; no public exploit is known. (SentinelOne; NVD, 29 May)

✅ Do this week

🎯 Attack Vector Spotlight

The short version: guardrails are filters, not walls. Three recent pieces of research show three different ways around them.

1. Sockpuppeting: put words in the model's mouth. Many chat APIs let a developer "prefill" the start of the assistant's reply. Sockpuppeting abuses that: the attacker writes an assistant turn that starts as if the model has already agreed, and the model tends to keep going rather than reverse itself. TrendAI (Trend Micro) tested 11 models. (TrendAI, April)

Sockpuppeting success rate by model: Gemini 2.5 Flash 15.7%, Claude 4 Sonnet 8.3%, down to GPT-4o-mini 0.5%; three models at 0% because their API rejects prefill

Every model that accepted a prefill was at least partly vulnerable. The ones that held at 0% never saw the attack: Claude 4.6 Opus (Anthropic removed prefill in Claude 4.6), and DeepSeek-R1 and Llama 3.1 8B on AWS Bedrock, which returns an error if the last turn isn't from the user. Self-hosted servers such as Ollama, vLLM and TGI don't enforce that by default.

2. RepMism: the guardrail and the model read different things. Researchers at Harbin Institute of Technology (Shenzhen) and Pengcheng Laboratory found that a small character-level change can throw off an input guardrail while the model behind it still understands the request. Their attack combines character injection with chain-of-thought hijacking, and they report high success rates against four commercial models and five state-of-the-art guardrails. (ACM Web Conference 2026)

3. The field guide. For everything else (roleplay, crescendo, many-shot, encoding, low-resource languages, fake system prompts) the security firm Wraith's 2026 guide is a handy catalog. Wraith sells training on this, so read it as a vendor's guide. (Wraith)

A rule added to the prompt is "just more text in the same context window". Assume the guardrail will be bypassed, and limit what a bypass gets.

✅ Do this week

⚖️ Compliance & Governance

The short version: the EU AI Act is being enforced now, but the high-risk rules were pushed back to late 2027. Check the date on any guidance you're relying on.

EU AI Act timeline as of October 2026: enforced since 2 August 2026; high-risk rules moved to 2 December 2027 and 2 August 2028

In the US it's pulling two ways, according to Collibra's June overview. A December 2025 executive order pushed agencies toward one national AI policy, and a March 2026 White House framework asked Congress to override state laws. Meanwhile laws in Colorado, California, Texas, Utah and Illinois are on the books. Collibra, which sells AI governance software, suggests planning to the strictest regime (usually the EU's), keeping one inventory of every model, use case and agent, and enforcing the rules as controls with audit trails. (Collibra, June)

From NIST: a draft quick-start guide, SP 1353, with ready-made prompts for using AI to review governance and draft Cybersecurity Framework 2.0 profiles. Comments closed on 15 October; the prompts are usable now.

✅ Do this week

🧰 Defensive Tooling

The short version: a simple trick from new research may protect a RAG system's documents with better answers than earlier privacy methods.

RAG (retrieval-augmented generation, an AI that answers from your own documents) can leak those documents: the paper's authors note that it can expose sensitive information from the retrieval store. Earlier defenses used differential privacy, a formal privacy guarantee.

Random projection for private RAG: documents and questions pass through the same random matrix R before storage and search

Dixi Yao, Tahseen Rabbani and Tian Li propose applying the same random projection to both the stored document embeddings and the query embeddings. Similar things stay similar, so retrieval still works, and the authors say it mitigates extraction attacks on the store. They report better retrieval and answers than earlier differential-privacy methods, with comparable privacy against strong attacks. (arXiv:2610.22297, 15 October)

It's a research result, not a product, and the abstract doesn't discuss its limits. But if you run RAG over sensitive documents, it's a cheap idea to test against your own extraction red-team.

✅ Ship today

🔭 Threat Horizon

None of this week's attacks needed a cleverer prompt. They went for the plumbing around the model: the MCP settings, the API that accepts a pre-written reply, the gap between how a filter and a model read the same text. As agents get more tools and more autonomy, expect the plumbing to be where the serious incidents come from.

Don't ask "can the model be tricked?" It can. Ask "what can it reach when it is?"

SecureLLM.ai is a weekly briefing on LLM security from Moves and Measures. Every fact links to its source. If we got something wrong, reply and we'll correct it.

Get the next one

A weekly briefing on LLM security. Free.