Hijacking Cursor’s Agent: How We Took Over an EC2 Instance
We broke Cursor's Background Agent and took over an EC2 instance. How did we do this, what are the implications and what's next?
What Happened?
Two weeks ago, Cursor Background Agents were released to the public, designed to allow users to run complex tasks in the background. Cursor, a unique self-hosted SaaS application, offers deep integration with an organization's identity infrastructure and performs critical background operations. However, our recent security investigation revealed a concerning vulnerability within these agents, demonstrating how even common desktop SaaS applications can expose underlying infrastructure to significant risk.
This incident underscores the critical importance of securing all SaaS applications, particularly those with elevated system access, and highlights the cascading risks when such applications become attack targets. Attackers are now exploiting the interconnected nature of SaaS to erode decades of carefully architected security boundaries.
This is the story of how we did it.
Cursor Background Agent - The Attack Flow
It Looks Like Docker!
Upon examining the Cursor Background Agents, we observed a curious behavior during spin-up: the execution of automated processes that strongly resembled Docker operations. Interesting!
Upon examining the Cursor Background Agents, we observed curious behavior during spin-up: the execution of automated processes that strongly resembled Docker operations. This immediately caught our attention and warranted deeper investigation.
Show Terminal
We watched and watched. And then we saw it: a "Show Terminal" button within the Cursor UI.
This feature, initially designed for debugging and transparency, provided us with direct command-line access to what we soon discovered was an unknown remote machine — not our local environment.
Now We Can Run Commands
This feature, initially designed for debugging and transparency, allowed us to run commands on an unknown remote machine, not our local one.
Privilege Escalation By-Design
We quickly determined that the ubuntu user on this machine was highly privileged by design, a necessity for Cursor's agent to pull packages and install dependencies. This inherent privilege allowed for a straightforward escalation to root access using the sudo -i command. At this point, we realized we had gained significant control over the infrastructure. The question became: Where are we? What machine is this? What's the scope of our access?
What We Discovered
Once we achieved root access, we began comprehensive enumeration of the machine to understand its environment. Using standard penetration testing tools like Linpeas.sh, we uncovered fascinating details about how Cursor's background agent orchestration works.
Server-to-Server Token
The agent utilized a Server-to-Server token to authenticate with GitHub, performing actions like commits and identifying itself as "Cursor Agent." This token, scoped to the user's repositories, presented potential abuse vectors for unauthorized repository access.
Node.js Server and Client
Cursor uses Node.js server and client components to perform required actions as part of the Agent functionality, including crawling operations. During this analysis, we also discovered the underlying network subnet configuration.
We Found a Data Exfiltration Vector
Our testing revealed that while external communication was restricted (only HTTP/HTTPS traffic was permitted), data exfiltration remained possible through two primary methods:
- Creating commits directly to GitHub repositories
- Moving relevant files to the
/workspace/directory and downloading them directly from the Cursor UI, as this folder is accessible from the local machine
Large Storage
The instance was provisioned with substantial 1TB storage capacity, indicating significant resource allocation for agent operations.
AWS Infrastructure
Instance provisioning occurred within AWS, utilizing a custom Docker image artifactory to orchestrate the process.
We Got the Host Machine Specs
Using Linpeas.sh, we confirmed the complete specifications of the host machine running in AWS, providing us with a clear picture of the underlying infrastructure.
Stuck in an Orchestrated Docker Instance - What Now?!
So we found ourselves with root access within an orchestrated Docker instance, access to large storage capacity, running on an AWS machine. The next challenge: How could we escape back to the host machine?
Docker escape techniques are notoriously complex, typically relying on instance enumeration and success depending on vulnerable kernels, packages, or misconfigurations. We focused on the latter approach, searching for misconfigurations within the Docker instance that would allow host machine access.
Volume Mounting Discovery
One by one, we started mounting each of the available volumes. We discovered that the host machine shares its own volumes with the Docker instance. And since we had root privileges - we could write to any location within these shared volumes.
The host machine utilized two primary accounts:
- Devuser
- Debug
The Docker Folder
When we mounted the second drive's main partition, we found the Docker folder containing the complete configuration of the Docker instance: images, network settings, and volumes. This gave us insight into the entire containerization setup.
Since the overlay filesystem was mounted and accessible, we explored potential cron jobs and file persistence mechanisms. However, we identified a more direct approach.
What’s the Host Machine’s IP Address?
Through network enumeration, we determined the host machine's IP address: 172.17.0.1.
Can We Gain Access to the Root Machine?
Without knowing the passwords for the devuser or debug accounts, we needed an alternative access method. The solution: SSH key injection.
Since we had root access from the Docker instance and write access to shared storage, we could:
- Generate our own SSH key pair
- Write the public key to
/root/.ssh/authorized_keys - SSH directly to the host machine at
172.17.0.1
But How Do We Get Our Private Key into the Docker Instance?
How did we get our private key back to the docker instance? Simple! We copied our private key to the Cursor UI's folder, which automatically uploaded it to /workspace/ within the Docker instance.
And Then What?
Success! We achieved direct SSH access to the host machine, effectively escaping the Docker container and gaining control over the underlying EC2 instance.
Important Lessons Learned
This is not a typical Reco threat report. We immediately reached out to Cursor's security team to report the entire flow, and Cursor confirmed that relevant safeguards were in place to prevent misuse.
It's important to stress that the machine's permissions, AWS roles, and VPC configurations were well-defined and heavily restricted. We were unable to perform any lateral movement or see other Docker instances (i.e., other agents). Cursor's security team confirmed this is by-design functionality and that relevant safeguards are in place to prevent misuse. Additionally, the GitHub token is scoped to the user's repositories, and the EC2 instances are single-tenant per user.
But this incident highlights several critical vulnerabilities that need to be considered, even for desktop applications:
- Third-Party Risk Amplification: An application like Cursor, though seemingly a desktop tool, runs agents with significant underlying infrastructure access. This demonstrates how SaaS security extends far beyond the applications you directly manage, as a compromised agent can provide a gateway to your cloud environment.
- Privilege Escalation Through Trust: The ability to escalate from a privileged user within a Docker container to root on the underlying EC2 instance showcases how the default "by design" privileges of an agent can be abused to gain control over a host machine.
- Supply Chain Security: The Cursor agent, running on a user's behalf and with the ability to interact with cloud resources, becomes a critical component in your security supply chain. When such an agent is compromised, the blast radius can be significant.
- Potential for Abuse: The full control over the AWS EC2 machine, coupled with the scoped GitHub Server-to-Server token, presents potential for malicious activities, including resource-intensive tasks like cryptocurrency mining, or unauthorized data exfiltration through user repositories.
The Bottom Line
The threat is real!
This incident, following close on the heels of other major SaaS security events, reinforces the urgent message that attackers are exploiting the interconnected nature of SaaS. Organizations can no longer afford to treat SaaS security as an afterthought or assume that their SaaS providers have security entirely covered.
Every SaaS application in your environment, including seemingly innocuous desktop apps with underlying agents, represents a potential entry point for attackers, and every third-party integration creates additional risk vectors. The question isn't whether you'll face a SaaS security incident, but whether you'll be prepared when it happens.
Reco and Cursor: Comprehensive SaaS Security Coverage
Reco supports integration with Cursor as part of your comprehensive SaaS security strategy, with future plans to enhance threat detection and response on business tiers as part of minimizing potential threats from this app.
Reco and Cursor: Comprehensive SaaS Security Coverage
The Cursor incident demonstrates that modern SaaS security requires visibility and control over applications that extend far beyond traditional boundaries. With Reco's Dynamic SaaS Security approach, you gain:
- Complete Visibility: See all SaaS applications and their underlying infrastructure risks
- Proactive Protection: Detect and respond to threats before they become incidents
- Automated Governance: Ensure consistent security policies across all SaaS applications
- Contextual Intelligence: Understand the business impact of security findings
Organizations using Cursor can immediately benefit from Reco's SaaS security platform by:
- Enabling Cursor discovery and monitoring through our App Factory integration
- Implementing automated posture management and compliance monitoring
- Establishing identity governance controls for Cursor access
- Preparing for enhanced threat detection capabilities as they become available
Dvir Sasson
%201.svg)
ABOUT THE AUTHOR
Dvir is the Director of Security Research Director, where he contributes a vast array of cybersecurity expertise gained over a decade in both offensive and defensive capacities. His areas of specialization include red team operations, incident response, security operations, governance, security research, threat intelligence, and safeguarding cloud environments. With certifications in CISSP and OSCP, Dvir is passionate about problem-solving, developing automation scripts in PowerShell and Python, and delving into the mechanics of breaking things.
Dvir is the Director of Security Research Director, where he contributes a vast array of cybersecurity expertise gained over a decade in both offensive and defensive capacities. His areas of specialization include red team operations, incident response, security operations, governance, security research, threat intelligence, and safeguarding cloud environments. With certifications in CISSP and OSCP, Dvir is passionate about problem-solving, developing automation scripts in PowerShell and Python, and delving into the mechanics of breaking things.
