Get AI summaries of any video or article — Sign up free
How To Gain Code Execution | Prime Reacts thumbnail

How To Gain Code Execution | Prime Reacts

The PrimeTime·
5 min read

Based on The PrimeTime's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

The Cursor installer led to two desktop’s infrastructure, and the compromise path centered on two desktop’s Firebase-backed deployment workflow.

Briefing

A security researcher traced a chain of weaknesses in the Electron app bundling and deployment workflow behind two desktop—an installer for the Cursor AI editor redirected to two desktop’s infrastructure—and demonstrated how it could lead to remote code execution (RCE) on end-user machines. The core finding wasn’t a single bug; it was the way multiple components—Firebase-backed storage, a non-open-source deployment CLI, source maps, and a deployment pipeline—combined into a practical path from reconnaissance to full compromise.

The investigation began with basic recon: the Firebase-backed site exposed source maps, making it easier to enumerate Firestore paths and identify an insecure collection tied to application data. From there, attention shifted to the two desktop CLI (distributed via npm) that handled deployments, source uploads, and related build logic. Using source maps again, the researcher extracted the CLI’s internal structure and then looked for ways to hijack the deployment process. A key step involved an arbitrary S3 upload vulnerability reachable through a Firebase Cloud Function that generated signed URLs. Even without direct S3 credentials, the researcher kept probing and found a high-impact weakness in the deployment pipeline via a post-install script—described as unusually large and risky—allowing a reverse-shell payload to run during installation.

Once inside the build container environment, the researcher located where the application build code lived and uncovered an encrypted prod config.json. The “encryption” was implemented in JavaScript and, crucially, the decryption logic and keys were present in the code itself, meaning the secrets were effectively recoverable. Further digging revealed a hardcoded Firebase admin key with full scope. With those credentials, the researcher could deploy an auto-update to any app managed through two desktop, pushing changes to clients immediately upon restart—turning the pipeline compromise into RCE.

Impact was framed in terms of scale: auto-updates could reach widely used apps such as ClickUp, Cursor, Linear, and Notion, potentially affecting hundreds of millions of tech users if exploited broadly. The researcher reported the issue through coordinated contact with two desktop, and a fix arrived quickly. Compensation was also part of the outcome: the researcher received $5K from two desktop and later $50K from Cursor for an affected customer.

The broader takeaway emphasized operational security failures rather than blaming any single product. The chain highlighted risks of closed-source third-party deployment tooling, reliance on Firebase with exposed artifacts like source maps, and the danger of shipping “encrypted” configuration where decryption keys are available to attackers. The incident also drew praise for responsible disclosure and rapid remediation, with Cursor and two desktop both described as responsive and willing to compensate the finder.

Cornell Notes

The investigation found that a Firebase-backed deployment workflow used by two desktop could be turned into remote code execution on client machines. Source maps exposed internal details, and a risky post-install script enabled a reverse shell during installation. Inside the build environment, “encrypted” prod config.json could be decrypted because the decryption logic and keys were present in JavaScript shipped with the system. A hardcoded, full-scope Firebase admin key then allowed the attacker to push auto-updates to apps managed by two desktop, reaching users when they restarted the app. The issue was reported and fixed quickly, with payouts from both two desktop and Cursor.

How did the researcher move from reconnaissance to a deployment compromise?

Recon started by noticing Firebase usage and then opening developer tools to find source maps. Source maps made it easier to enumerate Firestore paths and identify an insecure collection. The next pivot targeted the deployment mechanism: most logic ran in the two desktop CLI distributed via npm. With source maps for the CLI, the researcher mapped how deployments and source uploads worked, then searched for ways to hijack that pipeline.

What role did Firebase and signed URLs play in the attack chain?

A Firebase Cloud Function called get signed URL was used to generate signed URLs, and the researcher identified an arbitrary S3 upload vulnerability reachable through that function. Even without direct S3 key material, the signed-url path provided a foothold for further exploitation of the deployment workflow.

Why was the post-install script considered a turning point?

The researcher found a hijack opportunity in the deployment pipeline via a post install script in package.json. Because post-install scripts execute during installation, it enabled running a reverse-shell payload. That execution allowed navigation inside the container and discovery of where the real build code and configuration handling lived.

How did “encrypted” configuration fail to protect secrets?

The build environment contained a prod config.json marked as encrypted. The researcher located the JavaScript code responsible for decrypting it, and the decryption keys were present in that code. That meant an attacker could recover the secrets rather than being blocked by encryption.

How did stolen credentials translate into remote code execution for users?

A hardcoded Firebase admin key with full scope was found in the container. With those credentials, the researcher could deploy auto-updates to any app managed through two desktop. Clients would receive changes immediately when they restarted the app, and the update capability was sufficient to achieve RCE.

What was the response and why did it matter?

The researcher contacted two desktop through secure channels and reported the exploit chain. A fix arrived quickly, and the researcher received compensation: $5K from two desktop and $50K from Cursor for an affected customer. The incident was used to argue that rapid, cooperative remediation and fair disclosure incentives reduce the chance of prolonged exposure.

Review Questions

  1. What specific weaknesses made source maps and the two desktop CLI especially dangerous in this incident?
  2. Explain how a post-install script can turn a deployment system into a path for reverse shells and later RCE.
  3. Why does encryption of configuration fail when the decryption keys and logic ship with the client-side or build-side code?

Key Points

  1. 1

    The Cursor installer led to two desktop’s infrastructure, and the compromise path centered on two desktop’s Firebase-backed deployment workflow.

  2. 2

    Exposed source maps accelerated discovery of Firebase paths and internal CLI deployment logic.

  3. 3

    An arbitrary S3 upload vulnerability was reachable through a Firebase Cloud Function generating signed URLs (get signed URL).

  4. 4

    A risky post-install script in package.json enabled reverse-shell execution during installation, letting the attacker reach the build container.

  5. 5

    A “encrypted” prod config.json was effectively decryptable because the JavaScript decryption logic and keys were present in the shipped code.

  6. 6

    A hardcoded, full-scope Firebase admin key allowed attackers to deploy auto-updates to apps managed by two desktop, enabling RCE when clients restarted.

  7. 7

    Two desktop and Cursor responded quickly and compensated the researcher, illustrating effective vulnerability disclosure and remediation.

Highlights

The attack chain combined source-map leakage, a deployment CLI, and a post-install script to reach the build environment and extract usable secrets.
“Encrypted” prod config.json was recoverable because the decryption code and keys were included in JavaScript available to attackers.
A full-scope Firebase admin key enabled auto-updates to apps managed through two desktop, turning a pipeline breach into RCE.

Topics

Mentioned