Category: CyberSecurity

Can a tool connection setting run code?

When you connect an AI agent to a tool, are you just filling in a form, or are you telling a server which program to run? Langflow is a tool for building AI agents and workflows. For one type of connection, the answer turned out to be the second.

MCP (Model Context Protocol) connects AI applications to outside tools and data. With the stdio transport, the MCP server is a local program that the host launches and talks to through standard input and output. So setting up a stdio connection means naming a command for the host to run. If anyone who can edit that setting can name any command, the setting becomes a remote control for the server.

What did the first advisory describe?

On 10 September 2026, Langflow published advisory GHSA-7w94-79vh-5mr2. It was rated Critical, with a CVSS score of 9.9 out of 10. It described remote code execution, meaning someone could make the server run commands they chose. Any authenticated user, not only administrators, could add a stdio MCP server. Its command went to a shell with no validation, no allowlist and no sandboxing. The advisory lists 1.9.0 as the patched version.

The command ran every time the server list loaded, so a stored configuration could fire again whenever someone opened the MCP settings page, administrators included. These configurations lived in project settings, so normal flow review did not show them. The weakness is classified as CWE-78, OS command injection: outside input shapes an operating-system command.

Why wasn't the first fix the end?

On 28 September 2026, a second advisory, GHSA-w794-rj3p-xv45, covered versions from 1.1.2 up to but not including 1.10.3. It explained that the fix came in two steps. The first step added a command allowlist and argument and environment checks to the settings API's data model. But the code that actually launched the process still had no validation and still used a shell. A configuration could arrive another way, for example as an MCP Tools component value embedded in a flow. Then it never passed through those checks and could still run arbitrary commands.

Picture a guard at the front desk while the loading dock stays unlocked. Version 1.10.3 changed the design: one shared policy enforced at the API, at flow execution and right before the process starts, with no shell. The advisory also notes that the command ran before any MCP handshake. That is why it could execute even when the interface reported that the server had failed to start.

A hypothetical example

In this hypothetical example, a team upgrades to a release that contains only the first fix. They confirm that the settings page now rejects unfamiliar commands and conclude the issue is closed. Later, someone imports a shared flow that carries its own MCP tool configuration. That configuration never touches the settings form, so the check the team tested never sees it. The test was real. It just covered only one way in.

What can defenders take from it?

The second advisory supports a few practical steps:
– Run 1.10.3 or later. The advisory describes the issue as fully fixed there and in 1.11.0+.
– Disable LANGFLOW_AUTO_LOGIN, which defaults to true. It hands out a token without credentials and is documented as a development-only setting.
– Do not expose Langflow directly to untrusted networks, and give accounts only to trusted users.
– On multi-tenant deployments (one installation shared by several separate users or groups), consider the hardening settings the advisory lists, such as LANGFLOW_MCP_SERVER_ALLOWED_PACKAGES, which names exactly which packages may run.

Where should you look next?

When you review a fix for an injection flaw, a useful question is where the dangerous action finally happens, and whether the check sits there too. A protected form can still leave other routes to the same command. A concrete next step: list every Langflow instance you run, note its version and whether auto-login is on, and review its stored MCP server configurations for commands nobody recognises. The first advisory showed that these configurations persist and stay hidden from normal flow review.

References

1. Authenticated RCE via MCP Stdio transport allows any user to execute arbitrary OS commands on the server · Advisory · langflow-ai/langflow · GitHub pip
2. Langflow < 1.10.3: OS command injection (RCE) via arbitrary command in MCP stdio server configuration · Advisory · langflow-ai/langflow · GitHub pip pip pip

What changes when attackers get faster?

Imagine that a weakness in one of your systems could be found and exploited in hours instead of weeks. On 7 July 2026, the three European Supervisory Authorities (the ESAs: EBA, EIOPA and ESMA) backed a warning from the European Systemic Risk Board (ESRB). The warning says frontier AI models have become far better at finding and exploiting high-severity vulnerabilities in IT systems within very short timeframes.

A frontier AI model is one of the most capable general-purpose AI systems available at a given time. The ESAs still described the EU framework, including DORA and the AI Act, as a solid foundation. However, they warned that the speed and scale of these tools could weaken the operational resilience of financial entities.

Is the frontier AI statement a new law?

No. On 31 July 2026, the ESAs published a statement calling for a cross-sectoral, risk-based and consistent supervisory approach to ICT (information and communication technology) risks from frontier AI models. It builds on existing regulatory requirements and recent publications from the ESRB, ENISA and other authorities.

The legal anchor is still DORA, the Digital Operational Resilience Act, which is Regulation (EU) 2022/2554. It entered into force on 16 January 2023, applies from 17 January 2025, and covers more than 20 types of EU financial entities. The ESAs encourage firms and supervisors to use the statement as a basis for supervisory dialogue. A reasonable reading is that AI-driven threats belong within DORA's existing obligations, not in a separate legal regime.

How do DORA's pillars apply to AI-assisted attacks?

As ESMA lists them, DORA's main topics include ICT risk management, ICT third-party risk management, digital operational resilience testing, ICT-related incidents, and oversight of critical ICT third-party providers (CTPPs). CTPPs are technology providers the ESAs designate as critical for the financial sector. The 31 July statement places particular emphasis on preventing, detecting and managing frontier AI cyber risks, supported by robust governance and risk management frameworks.

One way to use this is to ask a question for each pillar. For risk management: does the time you assume between a flaw becoming known and being exploited still hold? For testing: do your exercises, including threat-led penetration testing (authorised tests that imitate real attackers' tactics), allow for faster adversaries? For third parties: the ESAs say they are engaging with CTPPs on how those providers are adapting.

A hypothetical example: the patch window that shrank

In this hypothetical example, an EU financial entity schedules a high-severity flaw in an internet-facing system for its next monthly patch cycle, assuming attackers need weeks to use it. After reading the supervisors' warning, its risk team questions that assumption. The team shortens the patch window for such flaws, checks whether monitoring would catch exploitation attempts before the fix is applied, and asks its key ICT providers how they are adapting.

What can you do next?

The ESAs have already encouraged financial entities, in their first annual report on major ICT-related incidents under DORA, to strengthen cybersecurity measures as AI-driven tools evolve quickly. A practical next step is to find one written speed assumption in your ICT risk documentation, such as a patch deadline, a detection threshold or an incident escalation trigger. Test it against the 31 July 2026 statement and record whether it still holds. That record is a concrete starting point for supervisory dialogue.

References

1. EBA, EIOPA and ESMA call for enhanced governance and consistent supervision to mitigate ICT risks from frontier AI models in the EU financial sector | European Banking Authority
2. The ESAs support ESRB warning on systemic cyber risks from frontier AI models | European Banking Authority
3. Digital Operational Resilience Act (DORA)

What are you really scanning?

Would you sign in to an account because an unexpected email asks you to scan a QR code? Phishing is deceptive electronic communication that appears legitimate to steal sensitive information. QR-code phishing, sometimes called quishing, disguises a link to a malicious website inside a scannable image. Think of it as a link inside an envelope: the familiar format does not establish whether the destination deserves your trust.

The image can also create a gap in email filtering. The UK National Cyber Security Centre explains that some phishing detection tools do not scan images, allowing a malicious QR link to slip through. That is a limitation of some tools, not evidence that every QR code is fraudulent.

Scanning and sharing details are different steps

In this hypothetical example, an unexpected email asks you to scan a code to view a document. Your phone opens a page requesting your email password. Scanning brought you to the destination; submitting your password would disclose account information. The scan alone does not establish that someone has taken over your account.

Where should you pause?

Before entering information, consider whether you expected the request and whether the destination belongs to the service. If uncertain, contact the business through a known channel. Requests for excessive information, including suspicious follow-up calls, are reasons to pause. The NCSC also recommends your phone’s built-in QR scanner; using it does not establish that the destination is legitimate.

If account access is compromised

Use the affected provider’s recovery route. For personal Microsoft accounts, its guidance includes checking a PC for malware before changing the password, changing or resetting the password, and reviewing account settings. Those instructions concern that account service. The concrete takeaway: treat an unexpected QR code as an unfamiliar link, and pause before handing the destination your sign-in details.

References

1. Microsoft Sway abused in massive QR code phishing campaign
2. QR Codes – what's the real risk? | National Cyber Security Centre icons/chevron/16px/black
3. How to protect against phishing attacks – Microsoft Defender for Endpoint | Microsoft Learn
4. How to recover a hacked or compromised Microsoft account | Microsoft Support Your Privacy Choices Opt-Out Icon Your Privacy Choices Opt-Out Icon

Why would an update interrupt access?

Why would a security update make a legitimate website stop working? Your browser relies on certificates—digital credentials that help establish a website’s identity. A certificate authority (CA) issues those credentials. If the browser stops trusting an authority behind a website’s certificate, access can be interrupted even when the website itself remains legitimate.

Microsoft’s October 2026 eMudhra changes illustrate this tradeoff. Microsoft reported eight recoverable intermediate CA private keys: secret signing keys belonging to authorities within eMudhra’s certificate hierarchy. Someone with those keys could create apparently legitimate certificates or sign malicious software as though it came from a trusted publisher.

Revocation and root removal are different

Revocation withdraws a certificate’s validity. eMudhra revoked the affected intermediate certificates, while Microsoft separately blocked the affected authorities. An intermediate authority sits within a certificate chain: a sequence connecting a certificate to a trusted root, the authority accepted as the chain’s foundation.

Removing a root from a trust list is a broader decision about which foundations the software accepts. Microsoft released a Windows update on October 26 removing seven certificates associated with the affected hierarchies, then removed the same seven from Edge’s trust list on October 27. That decision extends beyond blocking the identified compromised intermediate keys.

A legitimate service can lose its trusted chain

In this hypothetical example, you visit a booking website whose certificate depends on a removed root. After the trust update reaches your device, that chain is no longer trusted by default. The interruption does not, by itself, establish that the booking website was compromised; its certificate dependency needs attention.

Consider replacement before restoring trust

For service administrators, consider identifying dependent certificates and arranging replacements or an alternative trusted chain. Restoring trust locally deserves care: Microsoft warns that software which does not reliably check revocation or its blocked-certificate list could still accept certificates associated with the compromised intermediates. The useful takeaway is to address the certificate dependency before restoring the trust that made the connection possible.

References

1. Microsoft’s response to compromised eMudhra certificate authority keys Your Privacy Choices Opt-Out Icon Your Privacy Choices Opt-Out Icon
2. Microsoft releases Windows OOB updates to distrust eMudhra certificates

What is Strix?

Strix is a public GitHub project whose authors describe it as an open-source AI penetration testing tool. Penetration testing means deliberately probing software for security weaknesses and demonstrating whether they can be exploited. Strix aims to automate that work through AI agents: software workers that use tools to investigate an application and carry out tests.

The interesting idea is coordination. Instead of presenting a single automated checker, the documentation describes a team of specialized agents working together. Think of a group of investigators sharing different parts of an investigation: some explore the application, while others investigate weaknesses and validate findings. That is the project’s stated design, rather than an independently established measure of effectiveness.

Looking at code and running applications

The documented capabilities combine static analysis, which examines source code, with dynamic analysis, which examines software while it runs. Strix accepts local code, GitHub repositories and deployed applications as testing targets. Its documentation also describes testing a repository and its deployed application together, bringing those two views into one assessment.

For you as a curious reader, that combination makes the project more interesting than a code-only scanner. Its stated purpose includes observing application behavior and investigating whether a suspected weakness is usable. The documented testing areas include authentication, meaning how an application checks identity, and access control, meaning what an identified user is allowed to access.

Strix’s authors emphasize findings supported by a proof of concept: a working demonstration of a vulnerability. This connects a reported weakness to observable behavior. It describes the evidence the tool aims to produce; it does not establish that every weakness in an application will be found.

What does the project produce?

The documentation lists findings in Markdown, JSON, CSV and SARIF formats. These provide outputs for people to read and for software to process. SARIF is a structured format for security findings; Strix documents it as an output for GitHub code scanning. Local assessments also save run artifacts for subsequent inspection.

The project describes a self-hosted option running on your machine with Docker, a container environment for its testing tools, and your own language-model key—an access credential for the AI model service. A managed cloud service is also documented. For development workflows, the repository describes GitHub Actions integration that can initiate security testing when a proposed code change is submitted for review.

Takeaway

Strix illustrates how AI agents can connect source inspection, application testing and documented evidence. Consider it a project to understand within an explicitly authorized testing scope: its documentation calls for written permission and warns that agents can modify supplied local code, making a clean, disposable checkout a sensible starting point.

References

1. usestrix/strix — GitHub repository metadata
2. GitHub – usestrix/strix: Open-source AI penetration testing tool to find and fix your app’s vulnerabilities. · GitHub
3. strix/skills/penetration-testing-with-strix/SKILL.md at main · usestrix/strix · GitHub

Can leaders just hand cybersecurity to the experts?

When an organisation has a security team, its leaders can easily assume cybersecurity is taken care of. The work can be delegated, but responsibility for whether it is done well stays with the leaders. That lasting responsibility is called accountability: being answerable for the results, even when other people carry out the tasks.

The UK's Cyber Governance Code of Practice compares good cyber governance to financial oversight. Directors rarely do the bookkeeping themselves, but they are still expected to understand the accounts and question them.

Law, framework or code: what does each one ask?

In the EU, NIS2 (Directive (EU) 2022/2555) is law. A directive is EU law that each Member State must write into its own national law, with a deadline of 17 October 2024, so duties and penalties for leaders differ by country. The European Commission says NIS2 introduces accountability of top management for non-compliance with cybersecurity risk-management measures, bringing cybersecurity to the boardroom. The Commission has also proposed targeted amendments to make the rules clearer, so some details may change.

The NIST Cybersecurity Framework (CSF) 2.0 is guidance, not law. Version 2.0 added a Govern function, which covers how organisations make and carry out informed decisions on cybersecurity strategy. NIST stresses that cybersecurity is a major source of enterprise risk, and that senior leaders should weigh it alongside other risks such as finance and reputation.

In the UK, the government's Code sets out the governance actions directors should take ownership of. It is built on five principles: risk management; strategy; people; incident planning, response and recovery; and assurance and oversight. It was designed for medium and large organisations, and it is not meant for the people who run security day to day.

What does weak oversight look like?

In this hypothetical example, the board of a mid-sized company receives a quarterly slide that simply says "security status: green". Nobody asks what green means, which risks were accepted, or whether the incident plan has ever been tested. When a supplier outage stops operations, the plan turns out to rely on a backup provider that was never contracted. The specialists did what they were asked to do. The gap was that leadership never questioned the plan, approved it properly or funded it.

What does active oversight look like?

Oversight depends less on technical detail and more on asking good questions regularly. The UK National Cyber Security Centre's Cyber Security Toolkit for Boards is organised around the Code. It includes a set of questions, with possible answers, that boards can use to judge how well their organisation is doing. In the example above, useful questions would have included: which cyber risks matter most to the organisation, and who accepted them? When was the incident plan last rehearsed? Do the people doing the work have the resources they need?

Where are the limits?

None of these documents turns a board into a security team. Following a framework does not, on its own, guarantee compliance with NIS2 or with any national law. Whether individual leaders can face personal consequences depends on how each Member State has written the directive into its own law.

Your next step

At the next leadership meeting, consider replacing any single status colour with three named items: the top cyber risk, who accepted it, and the date the incident plan was last tested. Ask for the same three items every time, so leaders can see whether the answers change.

References

1. NIS2 Directive: securing network and information systems | Shaping Europe’s digital future
2. NIST Releases Version 2.0 of Landmark Cybersecurity Framework | NIST Lock
3. Cyber Security Toolkit for Boards | National Cyber Security Centre icons/chevron/16px/black
4. Overview | Cyber Governance Code of Practice | National Cyber Security Centre icons/chevron/16px/black

What if nobody hijacked the agent?

An AI agent is a system that does more than answer questions. It takes actions, such as reading files, calling services or changing records, with varying amounts of human involvement. Discussions of agent security often focus on attackers tricking agents. The UK's National Cyber Security Centre (NCSC) also points to a quieter problem: an agent can malfunction unexpectedly with no attacker involved at all.

The NCSC's reasoning is simple. An agent is not human. It has no common sense and may read instructions and goals in literal or unexpected ways. So a harmful action is not always a sign of compromise. Sometimes the agent did exactly what it understood, using access it had been given.

Why can't better instructions fix it?

The obvious response is to write a stricter prompt. The NCSC does suggest writing prompts carefully. On longer tasks it also suggests repeating critical constraints, because some agents compress their context window (the working memory of the task) to save resources, and earlier rules can drop out. Its advice is still direct: do not rely on prompting alone.

Safeguards built into the model have limits too. The NCSC describes them as a baseline that should not be treated as holistic, and notes they may be bypassed. Where the consequences of failure are more than an organisation can tolerate, it recommends extra safeguards around the agent rather than relying only on protections inside the model or the software that runs it.

A hypothetical example: the tidy-up that went too far

In this hypothetical example, a small firm asks an agent to "clean up outdated files" in a project folder. The agent runs under an employee's account, and that account can also reach a shared archive. Taking "outdated" literally, the agent deletes old contract records in the archive too. Nobody injected anything. The instruction was ambiguous and the access was wide.

What the agent could reach largely decided how much damage it could do. This potential impact is sometimes described as the agent's blast radius, and the NCSC notes that wider access means greater potential impact, whether an agent malfunctions or is compromised.

What does containment look like?

The NCSC recommends always running agents in a sandbox, a controlled environment that decides what the agent can communicate with, both locally and over a network. Inside it, restrict access to what the task needs, and watch for attempts to reach further.

Credentials need special attention. An agent running directly on a host may be able to use any credentials held by the user account it runs under. The NCSC suggests granting only the permissions the task needs and making credentials as short-lived as possible. For some uses, it suggests a proxy that adds credentials to requests without ever showing them to the agent.

Finally, plan how to stop it. The NCSC advises treating agent activity as user activity in security monitoring, and being able to "pull the plug" immediately. That can mean cutting the agent's network access and its connection to the model's inference infrastructure (the systems that run the AI model and return its responses), not just stopping a process.

How much oversight is enough?

Controls should grow with autonomy. The NCSC contrasts human-on-the-loop, where people monitor actions and can step in, with human-out-of-the-loop, where the agent acts without human review. For higher-risk uses, it recommends human oversight alongside technically enforced controls. It adds that "judge" AI models used to check an agent should be evaluated independently, because they have limitations of their own.

In May 2026, CISA announced a joint guide with US and international partners, including Australia's ASD ACSC. The announcement names related risks such as privilege creep and behavioural misalignment without defining them. In general terms, privilege creep usually describes a system gradually gaining more access than it needs, and misalignment describes behaviour drifting from what its operators intended. The announcement also recommends starting with low-risk, non-sensitive use cases. Both documents are guidance, not law. The NCSC describes its blog as interim advice that formal guidance will eventually replace.

Your next step

Pick one agent you use or plan to deploy and write two short lists: what its task actually needs, and everything its account, network and credentials can reach. Anything on the second list that isn't on the first adds to the blast radius, and you can remove it. Then ask yourself: if the agent misbehaved at 2 a.m., who would notice, and how would they stop it?

References

1. Managing the cyber risk of agentic AI | National Cyber Security Centre icons/chevron/16px/black
2. CISA, US and International Partners Release Guide to Secure Adoption of Agentic AI | CISA Lock

What exactly did you approve?

If you approve an AI agent deleting one file, have you also approved it deleting another? An AI agent is an AI system that can plan and take actions toward a goal. OWASP recommends binding approval to the exact action: changing the target or other action details requires new approval. Think of permission as a ticket for a particular journey, with a destination and an expiry.

Authorization means deciding whether an actor is allowed to perform an action. For an agent, that decision should happen in the execution component—the part of the system that actually carries out the request—outside the agent’s reasoning. An agent saying that the user agreed is insufficient evidence of permission.

What should the approval cover?

OWASP recommends recording who is acting, which operation will run, its target, its parameters—the details controlling the operation—and when approval expires. Before execution, the system should check that approval matches the current request, remains valid and has not already been used. A general “user confirmed” flag cannot establish all of those facts.

The check and the act of marking approval as used should happen together, as one indivisible step. Otherwise, simultaneous requests could reuse the same permission. This is replay protection: preventing an authorization from being accepted again after its intended use. OWASP also recommends short-lived authorization for irreversible operations.

One file, one decision

In this hypothetical example, an agent proposes deleting a particular draft file. You review the preview and approve that deletion. Before carrying it out, the execution component checks that the approval belongs to you and matches that file and operation. If the agent instead requests deletion of a folder, the earlier approval does not cover it.

If the original deletion request arrives again after approval has been consumed, that approval should not authorize another execution. A useful design question is whether the system can enforce both boundaries: changed requests need new approval, and repeated requests cannot reuse spent approval.

Why more prompts are not enough

In an August 27, 2026 blog post, NIST warned about consent fatigue: repeated approval requests can condition people to click “allow” without examining them. Human oversight therefore has limits. OWASP recommends setting autonomy boundaries according to action risk, alongside explicit approval and previews for high-impact actions.

Consider keeping an agent’s underlying permissions narrow and making consequential approvals specific enough to understand. When assessing an approval flow, ask: can this permission authorize a different target, changed details or another execution? For a single approved action, the useful boundary is concrete: one matching request, within its validity period, accepted once.

References

1. Back to the Future: Why Agentic AI Needs a Strong Identity Foundation | NIST Lock
2. AI Agent Security – OWASP Cheat Sheet Series