Cursor and Amazon Bedrock expose enterprises to silent, catastrophic budget drain.
TL;DR:
A new developer on our team accidentally spent our monthly Cursor budget in hours, then discovered he could change team spending limits to over $1M without admin approval or notification. This revealed critical vulnerabilities in Cursor and AWS Bedrock where non-admins can modify budget controls and leaked API tokens provide unlimited access. We built proof-of-concepts showing how attackers can exploit these flaws through malicious deep links or stolen tokens to drain enterprise budgets silently. Organizations using these platforms should immediately review billing settings, enable admin-only controls, and implement spending caps.
We notified Cursor on December 3, 2025 and are awaiting response. AWS: “customers who want to manage spending in Amazon Bedrock can do so through AWS Service Quotas and cost controls like AWS Budgets”.
Here, You Dropped $1M
Recently, a new developer joined our research team at OX and accidentally revealed a critical vulnerability in Cursor and Amazon Bedrock that could cost organizations a fortune and enable malicious actors.
In just a few hours, he had spent our team’s monthly Cursor budget. When he got notified of exceeding the limit, he wandered off to his user settings and found out he could simply change the organization’s budget limitations (to over $1M!) – even though he wasn’t the admin. The admin received no notification.
This wasn’t just a configuration oversight. It exposed a systemic problem: AI platforms prioritize speed and access over protection, creating an environment where a single leaked token or malicious link can trigger unbounded usage – silently driving costs into the millions before any alert fires.
The Problem: Insecure Defaults, Silent Financial Risk
AI development platforms bring enormous productivity gains, and their soaring popularity reflects that value. However, as our Cursor bill will attest, in some of these platforms – enterprise usage is extremely sensitive to financial exploitation: A single leaked token, misconfigured setting, or malicious deeplink can trigger unbounded AI usage – silently driving costs into the millions before any alert fires.
AI platforms prioritize speed and access over protection. This creates three critical failure points:
- No mandatory spend caps – Usage can grow unbounded
- Delayed cost visibility – Bills appear hours or days later
- Overly permissive access – Non-admins can modify critical settings
Both Amazon Bedrock and Cursor technically offer ways to limit spend, but these protections:
- Are not enabled by default
- Are reactive, not preventive
- Depend entirely on manual configuration
When these align, a single error or malicious action can drain your budget before anyone notices.
The Evolution of Digital Theft
Every technology era creates new “digital currency” for criminals. In the 2000s, stolen passwords provided access to financial accounts. In 2010-2015, encrypted data led to ransomware payments. During the last decade, computing power was hijacked for free cryptocurrency mining. And now, AI tokens can handle expensive workloads on someone else’s bill.
These keys are even sold at underground forums.
- Cursor: When Anyone Can Edit Your Budget
Cursor’s usage-based pricing has a critical flaw: any team member can edit spending limits without admin approval.
A non-admin user can:
- Change team limits to “unlimited”
- Set caps to $1,000,000+
- Save changes with zero friction
Most teams assume these controls are admin-only. Cursor’s documentation reinforces this false security by stating “admins can increase the limit”—implying protection that doesn’t exist by default.
Users have complained – multiple times, but the issue persists.
- AWS Bedrock: Same Problem, Different Platform
AWS Bedrock has no built-in spend caps by default.
AWS acknowledges this risk in their documentation, noting that “Amazon Bedrock offers a pay-as-you-go pricing structure that can potentially lead to unexpected and excessive bills if usage is not carefully monitored” and that “traditional methods help spot high usage, but only after costs are incurred.”
AWS recommends Budgets, CloudWatch Alarms, and anomaly detection – but these are all reactive.
If a Bedrock API key leaks:
- Attackers flood requests immediately
- Costs grow silently for hours
- You see the damage only after it’s done
The problem is so widespread that entire AWS guides exist on mitigating it. AWS even suggests third-party tools like LiteLLM – proof the defaults aren’t sufficient.
Not just an internal misuse
This isn’t only an admin’s headache. We built a proof-of-concept showing how attackers can exploit this to drain millions of dollars in value – in compute power.
Scenario 1: Social Engineering Attack via Malicious Links
1- Attacker sends a malicious Cursor deeplink:
When clicked, it automatically:
- Injects a prompt into the user’s Cursor chat
- Opens the Command Palette
- Navigates to the team Usage & Billing modal
- Edits the usage limit to an extremely high value
- Saves it – without requiring admin permissions
2- Team budget silently becomes $1M+ per month. At this point, any team member – even those with no usage limits – can incur massive costs. At this stage – the attacker still has no access to the Team’s AI account.
3- Attacker sends a second deeplink, which triggers an infinite requests loop to flood cursor with high usage
This link:
- Runs code in the name of the team member
- Injects a prompt that triggers infinite requests
- Floods Cursor with high-cost model usage
- Burns through tokens at scale
- And costs the company up to the modified limit ($1M+)
Attack Diagram :
Below is a POC of the attack demonstrated in a video:
But malicious deeplinks aren’t the only threat vector.
Scenario 2: Exploiting Leaked or Stolen API Tokens
When developer accounts are compromised or API tokens leak online, attackers gain direct access to AI compute resources. These stolen tokens can be:
- Used directly by attackers for their own AI workloads or exploited at scale across multiple compromised accounts simultaneously
- Sold on dark web marketplaces where AI access is increasingly valuable
Unlike Scenario 1, this doesn’t require social engineering – just a single exposed token can provide immediate, silent access to drain enterprise budgets.
Responsible Disclosure
AWS Response: “This is not a security issue with Amazon Bedrock or AWS. AWS customers who want to manage spending in Amazon Bedrock can do so through AWS Service Quotas and cost controls like AWS Budgets. Access to Bedrock APIs and the ability to modify service quotas are governed by IAM permissions, which customers configure based on their security requirements”.
We notified Cursor of these vulnerabilities on December 3. As of publication, we are still awaiting their responses.
Kudos to Vendors Who Got This Right
Claude & Claude Code (Anthropic) – Claude Code avoids this entire class of vulnerabilities by design. In our testing, regular (non-admin) users could neither view nor change billing or spend-limit settings; those controls live only in the Anthropic Console and are restricted to admins. Even when creating an API key, Claude requires the admin to explicitly pre-fund a credit amount before any usage can begin, adding an extra safeguard against accidental or malicious cost explosions.
OpenAI – OpenAI combines strict role separation with a hard credit balance. Non-admin users cannot access billing, adjust spend limits, or manage workspace members, and if the credit balance is, say, $10, no one can spend above that amount—requests simply stop once the balance hits zero.
Windsurf – With Windsurf, regular team members are confined to usage, not billing. In our checks, non-admin users couldn’t view or change payment details or team-wide limits, keeping financial controls in the hands of workspace owners and reducing the blast radius of a compromised user account.
Recommendations
User Organizations
Cursor Teams:
- Review billing settings immediately
- Enable “Admin-only usage control”
- Brief teams on usage policies
AWS Bedrock Users:
- Deploy AWS Budgets with enforced actions
- Set CloudWatch alarms
- Rotate and secure API keys
- Consider AWS Generative AI Gateway (LiteLLM)
Vendors
- Enable admin-only controls by default
- Require confirmation for budget increases (MFA, warnings, approval workflows)
- Fix documentation to explicitly state that protection isn’t automatic
