Researchers Exploit Cursor Background Agents to Take Over Amazon EC2 Instance

Security researchers have successfully exploited vulnerabilities in Cursor’s Background Agents to gain unauthorized access to an Amazon EC2 instance, demonstrating critical risks associated with SaaS applications that integrate deeply with cloud infrastructure.

The researchers immediately disclosed their findings to Cursor’s security team, who confirmed that safeguards were in place to prevent misuse.

Initial Discovery and Attack Vector

The researchers identified suspicious Docker operations during the Cursor Background Agents’ spin-up process, which immediately warranted deeper investigation.

The breakthrough came when they discovered a “Show Terminal” button within the Cursor UI, initially designed for debugging and transparency purposes.

This feature provided direct command-line access to what appeared to be a remote machine rather than the local environment.

Through this terminal access, the researchers executed commands on the remote infrastructure, establishing their first foothold into the underlying system architecture.

The ubuntu user on the compromised machine possessed elevated privileges by design, necessary for Cursor’s agent to pull packages and install dependencies.

Technical Infrastructure Analysis

Once root access was achieved, comprehensive enumeration using penetration testing tools like Linpeas.sh revealed fascinating details about Cursor’s background agent orchestration.

The researchers discovered that 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 user repositories, presented potential abuse vectors for unauthorized repository access.

The infrastructure analysis revealed Node.js server and client components performing required actions as part of the Agent functionality, including crawling operations.

The instance was provisioned with substantial 1TB storage capacity within AWS, utilizing a custom Docker image artifactory to orchestrate the process.

The researchers found themselves with root access within an orchestrated Docker instance running on an AWS machine.

Through volume mounting discovery, they determined that the host machine shared its own volumes with the Docker instance, and with root privileges, they could write to any location within these shared volumes.

Since they had root access from the Docker instance and write access to shared storage, the researchers could generate their own SSH key pair, write the public key to /root/.ssh/authorized_keys, and SSH directly to the host machine at IP address 172.17.0.1.

This incident highlights critical vulnerabilities in desktop applications with cloud infrastructure access.

The researchers emphasized that while Cursor’s machine permissions, AWS roles, and VPC configurations were well-defined and heavily restricted, the potential for privilege escalation through trust relationships remains concerning.

The full control over the AWS EC2 machine, coupled with scoped GitHub Server-to-Server tokens, presents potential for malicious activities including cryptocurrency mining or unauthorized data exfiltration.

Get Free Ultimate SOC Requirements Checklist Before you build, buy, or switch your SOC for 2025 - Download Now