Security Apr 21, 2026 6 min read 1,141 words 111 views Updated Sep 2026

Why UAE Firms Are Exposed to Cursor AI Vulnerabilities

Cursor's agent mode reads your repo, browses the web and runs shell commands: here is how prompt injection turns that into a UAE breach risk.

Table of Contents
Why UAE Firms Are Exposed to Cursor AI Vulnerabilities – cybersecurity guide by Basim Ibrahim


Cursor is an AI coding assistant that reads your codebase, browses the web, runs terminal commands and installs its own tool integrations. The exposure is not one CVE: giving an agent write access to a repository and a shell turns every piece of untrusted text it reads, a README, a dependency's docstring, a scraped web page, into a potential instruction. UAE firms are exposed because most switch on agent mode faster than they switch on the controls that contain it.



  • Indirect prompt injection is the underlying risk class, not a single exploit

  • Auto run ("YOLO mode") is what turns an injected instruction into command execution

  • MCP servers extend the agent's reach to whatever that server can touch

  • Cursor's Business and Enterprise tiers offer admin controls the free and Pro tiers do not

  • Data residency and the model provider's training terms matter more here than for most other tools



What Cursor Actually Does With Your Code

Cursor is a fork of VS Code with an agent layered on top. In agent mode it indexes the workspace, reads files across the repository, calls a language model backend for completions and edits, and, when permitted, runs terminal commands directly. It can fetch documentation pages mid task and connect to Model Context Protocol (MCP) servers that give it tools beyond the editor: database clients, browser automation, ticketing systems.

Two things matter for an AI security review. A .cursorrules or .cursor/rules file sits in the repository and loads into every session automatically, so anyone who opens a pull request against it can change agent behaviour for the whole team. And the agent's context includes whatever files it opens, so a credentials file in the workspace is as available to it as any other file.

The Vulnerability Class Vendors Do Not Like To Name

The recurring problem across Cursor and every agentic coding tool is indirect prompt injection. A language model cannot reliably tell an instruction from the user apart from text it is merely reading. If an attacker gets text in front of the agent, a comment in a dependency, an issue fetched through an MCP integration, a paragraph on a page the agent was told to summarise, the model may treat that text as a command. This is a property of how the model processes context, not a bug in one release, so it cannot be patched away with a single fix. It can only be contained by limiting what the agent may do once it has been fed something malicious.

Where It Turns Into Code Execution

Containment is exactly what auto run removes. Cursor's auto run setting lets the agent execute terminal commands without a human approving each one. With it on, a successful injection stops being a bad suggestion in a chat window and becomes a command that runs on a developer laptop holding SSH keys and cloud tokens. Even with auto run off, confirmation dialogs fail against alert fatigue: a developer clicking "allow" fifty times a day stops reading the fifty-first command before approving it.

MCP Servers Are the New Supply Chain

MCP servers are how Cursor talks to anything outside the editor. Installing a community MCP server is the same decision as installing an unreviewed package, except it does not just end up in a build artifact: it runs live inside the agent's session with whatever permissions its author wrote in, often broad filesystem or network access by default. A registry listing with a plausible name is not a security review. Teams that would never add a dependency without a scan routinely add MCP servers because a blog post recommended one.

Why This Lands Harder in Regulated UAE Entities

For a bank or government entity under CBUAE or NESA oversight, an AI coding assistant is a third party processor the moment it reads source code, and it should go through the same vendor risk process as any SaaS tool: where does the code go, does the provider train on it, where do logs sit, is there a data processing agreement covering UAE PDPL obligations. Organisations that already track this, the territory covered in vibe coding inside UAE banks, often have no equivalent inventory for coding assistants, because engineering teams adopt them without procurement. The finding an assessor writes up is usually the missing risk assessment, not a flaw in the model itself.

What Goes Wrong in Practice

  • .env files and cloud credentials sit inside the indexed workspace, so one injected instruction can ask for their contents.
  • Auto run gets switched on team-wide "to move faster" and is never revisited.
  • MCP servers get installed from a GitHub README with no review of what hosts or paths they can reach.
  • A shared .cursor/rules file gets merged like a comment, when it actually changes agent behaviour for every teammate who opens the project.
  • Security teams learn the tool is in use during a source code review as part of penetration testing, not before rollout.

What Assessors Actually Ask For

  • An inventory of AI coding tools, tied to an agreement stating whether submitted code trains the model.
  • Evidence that agent execution is scoped: a command allow list, no unattended execution against production, auto run off by default.
  • An approved MCP server list, reviewed like any other dependency, not left to individual choice.
  • Secrets scanning that runs regardless of whether code was AI generated, since an assistant reads a stray .env file as readily as a person would.
  • AI suggested commits going through the same review and branch protection as any other commit.

The Honest Tradeoff

Banning agent mode outright does not remove the risk, it moves it somewhere you cannot see: developers switch to personal accounts or unmonitored channels for the same gain. Turning auto run off and curating the MCP server list keeps most of the value of an agentic coding tool while capping what an exploited instruction can reach. There is no configuration that gives an agent repository write access and a shell while also making prompt injection impossible, because the model cannot fully separate instructions from data. Every control here limits the blast radius. None of them stop the instruction from arriving.

Before You Approve Cursor, or Any AI IDE, for a Regulated Team

Four things decide whether this goes well: auto run off by default and enabled per project only where the blast radius is accepted in writing, MCP servers restricted to an approved list reviewed like any other dependency, secrets excluded from the indexed workspace rather than just from git history, and data processing terms confirmed with the model provider before rollout. Fold coding agent activity into the next cycle of the vulnerability management programme and the third party risk register. It is not a personal productivity tool exempt from either.

Basim Ibrahim, Senior Cybersecurity Presales Consultant Dubai
Basim Ibrahim OSCP CEH CySA+ Pentest+
Senior Cybersecurity Presales Consultant, Dubai, UAE

5+ years delivering enterprise cybersecurity presales, VAPT assessments, and security advisory across the UAE and GCC. Currently Senior Presales & Technical Consultant at iConnect IT, Dubai.

Connect on LinkedIn

Was this article helpful?


Comments

Leave a Comment

Comments are moderated before appearing.

Related Articles

Weekly Cyber Insights

One email per week. UAE/GCC focused. No spam, unsubscribe any time.