What the payload did​

The Phorion write-up is detailed and worth reading in full. The short version:

1. It appended an attacker's Ed25519 public key (comment svc-telemetry) to ~/.ssh/authorized_keys.
2. It opened an outbound reverse SSH tunnel so the operator could reach your local port 22 without any inbound firewall rule.
3. It set up persistence: a user LaunchAgent named com.apple.sysmond.plist on macOS, an @reboot cron entry on Linux, a SysMon task or Startup script on Windows.
4. It sent a beacon with your hostname, git email, public IP, and the names (not values) of up to 40 environment variables matching KEY|TOKEN|SECRET|PASS|AWS|GCP.

That last one is the tell. The operator wanted a shopping list of which machines hold cloud credentials. On a big company laptop that list is long and mostly guarded by SSO. On a founder's laptop it's often STRIPE_SECRET_KEY, AWS_ACCESS_KEY_ID and a long-lived GitHub token, all in one .env.

Phorion also found a bug: on macOS, as a standard user, the check for Remote Login reads an admin error instead of "Off", so the script never tries to turn SSH on. If Remote Login was already enabled, that doesn't help you. Don't plan around an attacker's typo.

Check this today​

If anyone on your team used Cursor with that extension in late October, uninstalling it is not enough. The cleanup list from the advisory, condensed:

• Look for svc-telemetry in ~/.ssh/authorized_keys, and compare key fingerprints too, since the comment is easy to change.
• Look for ~/.config/.smt, ~/.config/.smtk, and $TMPDIR/.stk_* files.
• On macOS, check ~/Library/LaunchAgents/ for com.apple.sysmond.plist. Apple doesn't put its own agents in your home folder.
• Check crontab -l for an @reboot line you didn't write.
• Check System Settings for Remote Login, and SSH logs for logins from 127.0.0.1 with that key.
• If SSH was on or you see a login, rotate everything that user could read. Start with payment keys and cloud credentials.

Habits that make the next one boring​

This won't be the last poisoned extension. Marketplaces are a distribution channel, and distribution channels get attacked. A few cheap habits shrink the blast radius without buying anything.

Keep secrets out of your shell environment. The beacon only read variable names, but those names were the targeting data. Load secrets per command (op run, doppler run, aws-vault exec) so they exist for the process that needs them and not for every extension host.

Use restricted keys wherever the provider lets you. Stripe restricted keys, scoped GitHub fine-grained tokens, short-lived cloud sessions. A read-only key that leaks is an incident report. A full secret key that leaks is a very bad week. This is the same reason Dealpuffin asks founders for a read-only restricted key and never a secret key.

Pin and slow down extension updates. Turn off auto-update for extensions that can execute code, and let a new version sit for a few days before you take it. Most marketplace compromises get caught by someone else within 48 hours. Being a few days behind is a fair trade.

Give agents their own keys. If you run coding or ops agents, give each one a separate token with only the tools it needs, so you can revoke one without rotating everything. Our API keys and OAuth page shows how we split scopes per agent, and the pattern works anywhere.

Treat the laptop as a server. Disable Remote Login if you don't use it. Watch for new files in ~/Library/LaunchAgents. If you have a fleet of three, a weekly five-minute check is enough.

Frequently asked questions​

Which versions were affected?​

Claude Code for VS Code 2.1.312 and 2.1.313 as distributed on the Cursor Marketplace, per Phorion's advisory and Cursor's notice. Cursor removed both.

Did the malware steal secret values?​

The beacon sent environment variable names, not values. But an operator with an SSH shell on your machine can read anything your user can, so if the tunnel was usable, assume the values are exposed too.

Is uninstalling the extension enough?​

No. The SSH key, persistence script and LaunchAgent or cron entry survive uninstalling. Remove each one and then decide on rotation.

Related on Dealpuffin​

How we think about permissions when founders connect billing: Connect Stripe and Proof points. For agent setups: Install the skill.

Prefer a live code over a screenshot​

A percent off a plan means nothing if the code is expired, maxed out, or locked to one customer. The billing provider (Stripe, Paddle or Polar) enforces those rules at payment time. A listing that syncs from the provider can show only codes that still redeem. A static screenshot can't. Our caps and expiry page explains the two clocks a listed code runs on.

Check duration and what it applies to​

A 50% code for three months, 50% forever and $20 off the first invoice are three very different deals. Read the duration and the product or price the coupon attaches to before you rearrange your stack around it.

Know who is giving the discount​

Only the product that owns the billing account can honor the code. A directory that makes up its own codes is guessing. When Dealpuffin lists a coupon, the founder already created it in their billing provider and chose to publish it. Claim and checkout covers what happens when you use one.

Related on Dealpuffin​

How listings and proof points work: Introducing Dealpuffin and Proof points.

What actually changed​

Nothing broke on day one. Stripe's announcement talks about integrating Metronome's metering with Stripe Billing. Adyen says Orb keeps running under an "incubator model" and keeps supporting other processors during the first phase, with the stated long-term intent being "a single infrastructure experience for merchants across billing and payments." Orb's own post says customers can keep their preferred processor.

Read those together and the direction is clear. Billing is turning into a feature of your payment processor again. That's fine if you were going to stay on that processor anyway. It's a cost if you wanted the freedom to move.

The founder's version of the decision​

Most early teams don't need a metering engine yet. You need one when the thing you charge for is a volume (tokens, API calls, GB-months, minutes) and the numbers get big enough that summing them in your own database becomes a project. Before that, a flat plan plus a usage cap, or a few tiers, is easier to sell and easier to explain on a pricing page.

When you do need metering, the real choice is between three shapes:

• Processor-native. Stripe Billing with meters (and now Metronome behind it), or whatever your merchant of record ships. Fewest moving parts. Your pricing logic is coupled to that processor.
• Processor-owned but nominally neutral. Orb today. Strong engine, and the neutrality is a promise with an "initially" attached. Get the multi-processor terms in writing if you care.
• Independent or open source. Lago is the obvious one left. You own more of the plumbing, and some features you'll want for custom deals sit in paid tiers, so check the price page before you assume open source means free.

Questions to ask before you sign​

Can it model your hardest meter live? Storage billed per GB-month needs a time-weighted aggregation, not a sum. Ask every vendor to build your trickiest meter in the demo. Most of the pain in billing migrations comes from one meter that turned out to be special.

What does "credits" mean to them? Credits applied to an invoice and a prepaid balance that usage burns down are different features. If it's a balance, ask whether it draws down in real time or only when the invoice finalizes. The second one lets a customer blow past their balance mid-cycle.

How are customer-specific deals stored? A negotiated rate on the contract and a coupon stacked on list price produce different invoices and different revenue reports. Early on you'll do a lot of both, for design partners and launch-week signups.

How hard is leaving? Ask for an export of customers, plans, meters and invoice history in a format another system can import. If the answer is "talk to support", price that in.

Where discounts fit​

Whatever you pick, keep discounts as real objects in the billing system: a coupon or promotion code with a duration, a cap and an expiry. Don't make them a note in a spreadsheet or a manual credit. Real objects are auditable, they expire on their own, and other tools can read them. That's how Dealpuffin works: we read coupons from Stripe, Paddle or Polar, and the caps and expiry come from the provider, not from us. If your discounts live in your billing system, you can move them to any directory, marketplace or agent later.

Frequently asked questions​

Is Metronome still available on its own?​

Metronome is part of Stripe since January 2026. Check Stripe's current docs for how new integrations are routed between Stripe's native meters and Metronome before you build.

Does Orb still work with Stripe?​

Adyen and Orb say Orb continues to support other payment processors during the first phase after the acquisition. The long-term stated goal is convergence with Adyen's payments, so ask about multi-processor support in your contract.

Do I need usage-based billing at launch?​

Usually not. If your costs scale with usage, a flat plan with a clear cap protects your margin while you learn what customers actually use. Add metering when the cap starts costing you deals.

Related on Dealpuffin​

For founders pricing a launch offer: How to read a SaaS discount page and Why target early adopters.