Cursor Account Compromised? Do These 5 Things Now

Cursor's security guidance lists four signals. Any one of them justifies running the full recovery sequence below. The steps cost minutes and are safe to do on suspicion.

• Unexpected usage or charges on your billing page.
• Login notifications you don't recognize.
• Settings or preferences you didn't change.
• Team invitations you didn't send, if you're a team admin.

The four aren't equally useful, though. Settings you don't remember changing is the weakest of them, since you might have changed them yourself and forgotten. A team invitation you didn't send is, I think, the one to take most seriously, because revoking sessions doesn't remove a member somebody already added.

Work down the list in order. Only the first two are strictly sequential, which is the part worth knowing when you're doing this at speed. The rest can happen in whatever order you get to them.

1. 1Secure the login method itself. Cursor sign-in rides on Google, GitHub or an email magic link, so the compromise is usually upstream. Change the password on that provider immediately and enable two-factor authentication. For magic-link accounts, that means the email account's password and 2FA.
2. 2Revoke every session. Go to cursor.com/dashboard → My Settings → Active Sessions, and click Revoke next to each session. This severs any device the attacker still holds.
3. 3Rotate exposed API keys. If you stored provider keys in Cursor (OpenAI, Anthropic), revoke them on the provider's dashboard, generate new ones, and only then re-add them to Cursor settings.
4. 4Audit billing and team state. At cursor.com/dashboard/billing, check invoices and usage for anomalies; review team membership for members or invitations you didn't create.
5. 5Escalate to security@cursor.com if you see unauthorized charges, lost account access, unfamiliar team members or suspect key exposure. Include dates, the charges and screenshots. That shortcuts triage.

Revoking sessions before you've secured the login provider just hands the attacker a second sign-in. It costs you the sequence over again rather than anything permanent. Calling step one a password change undersells it, though. The password is the smaller half, and two-factor on that provider is what stops a stolen password working a second time, so turn it on before you go near the session list.

Steps three through five don't depend on each other. On a two-person team you'll probably just work down them yourself. With more people around, step three is the one to hand off, since the revoke happens on the provider's dashboard rather than anywhere in Cursor. Re-adding the replacement keys is the part that comes back to Cursor settings.

SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition.-managed accounts can't self-serve the recovery: session control lives in your identity provider. Cursor's guidance is to contact your IT administrator to revoke sessions in the IdP, review suspicious logins there, and reset corporate credentials if needed. Loop in whoever owns the Cursor team plan too. They can see team-level activity you can't.

What that costs you is time you don't control. The revoke itself is quick once somebody with identity-provider access runs it, and reaching that person at the wrong hour is, in practice, the whole of the delay. Mail IT and the team-plan owner at the same time rather than one after the other. On an SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. account your admin is effectively doing steps one and two for you.

Not both halves of the problem. Nothing in the identity provider reaches an OpenAI or Anthropic key, so rotate those yourself while you wait.

Every control below maps to how a hijacked account actually gets used: burned usage and spent API keys. Four habits close those doors.

Two of those four keep working without you, and two ask for a habit. Two-factor on the identity provider and a spend limit get set once. Periodic session review is the one I wouldn't build a plan around, since reviews you have to remember are the ones that stop happening. Check the list after you've signed in on a machine that wasn't yours, and otherwise leave it alone.

None of this needs to be policy on a small team.

Once you stop recognizing every name on the member list, the controls that matter move into the identity provider, and automated deprovisioning through SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. and SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition., which Cursor gates to Enterprise plans with SSO enabled, is what you set up instead.

Two things survive a session revoke: an API key the attacker copied, and a team member or invitation they added. If spend is still climbing once you've worked the list, I'd check those two before re-running anything else.

Losing access to the account altogether is a different case, and the one where writing in early actually pays. Cursor lists account lockout among the reasons to mail security@cursor.com instead of carrying on alone. Put the dates and the specific invoice in that first mail so triage doesn't have to come back and ask for them.