Nobody reads their issues anymore

There’s a new type of attack targeting engineers lately, and I just wanted to share some of my experience with how these attacks are coordinated.

First, if you’re a developer from before AI, there’s a very high chance you’ve contributed to, as well as created, a large number of open source projects.

And if your contributions still hold, you might even be a lead maintainer or core contributor on some of these projects.

Now, what usually happens is that because of the advent of harness engineering and loop engineering, most developers don’t even read their issues anymore.

Because an agent can read the issue, synthesize the problem, and then write a PR for it.

But you might think the issue is with the PR.

It’s not necessarily about the PR itself.

So this is how an attacker would target you.

They would first of all reach out to you and say:

Hey, you built this infrastructure. We like it, and we want to use your infrastructure to build our app. And this is our app, and it’s also open source.

Unknown to you, the attacker’s open source repo is just a web of links, READMEs, and documents that each contain an instruction.

If for some reason you respond to their issue as a human being, you might be able to catch how deeply nested the references are.

But you know that with GitHub, it’s kind of hard.

So if, however, you skip that part and you tell your agent:

Take this issue this person reported, try to reproduce it.

Deep down within that nested web of links, as they reference their pull request or their GitHub repo, you’ll find your agent spiraling and getting deeper into those links.

And eventually, it could get compromised.

Because somewhere in that GitHub repo is malicious code or an injected instruction designed to compromise your harness.

And in many cases, this compromise has already been planned out.

They know you use Cursor. They know you use Claude Code.

And so somewhere down the line, the attack may already be targeting a vulnerable configuration or extension in your Claude Code or Cursor environment, waiting for the right conditions to be invoked.

And this is not even hypothetical anymore.

On October 29, 2026, Cursor disclosed that a malicious version of the Claude Code extension had been distributed through its extension marketplace.Cursor, “Security notice: malicious version of Anthropic.claude-code (2.1.313) identified in the Cursor Extension Marketplace.” Cursor states the build “was not developed by Anthropic,” and that it has no evidence other versions or the official distribution were affected. The window was roughly 2:27am to 1:35pm PT. Reporting at BleepingComputer, The Hacker News, and a technical breakdown at Ox Security.

For almost 11 hours.

An extension developers already trusted, sitting inside an environment they already used, was attempting to install an SSH backdoor, collect machine information, and establish persistent access.The payload collected host and user information, added an attacker-controlled SSH key named svc-telemetry to authorized_keys, installed persistence, and attempted to enable the local SSH service and open a reverse tunnel. Enabling SSH requires admin rights the extension lacks on most Mac and Windows hosts, so the tunnel would fail there, but the key and persistence could still land. Help Net Security. Researchers note that uninstalling the extension does not remove the backdoor.

Cursor estimated that at most 5,000 users were affected.

Now think about that.

You don’t even need to be interacting with an attacker’s GitHub repo for this particular attack to happen.

You could simply be using an extension you already trust.

And while this was happening, Binance separately reported a security incident, with its initial investigation pointing to a compromised DevOps engineer’s laptop.BleepingComputer, “Binance links $6.3 billion crypto theft to compromised DevOps laptop.” Roughly $6.36 billion moved across ten blockchains, most of it inside about 20 minutes; around $3 billion was frozen on-chain. Binance has since said the attacker did not rely on a single engineer’s permissions alone, and that further points of breach were found, so the laptop may have been one entry point rather than the only one. Binance has said it will publish a technical post-mortem once the facts are verified; at the time of writing it had not, so every figure here comes from press reporting of Binance’s statements rather than a Binance-hosted document.

There’s no confirmed connection between these two incidents.

But this is exactly why I keep emphasizing the access engineers have on their personal machines.

Because sometimes the real target isn’t even the library you’re maintaining.

It’s the environment you’re maintaining it from.

And this is how these exploits can unfold.

Because if for some reason your harness runs on your personal computer or your personal machine, you could eventually become a victim of the attack.

And in some cases, there are so many honeypots they set for you.

One could be their actual app, where they’re using your project, your infrastructure, your library.

And you’d be like, you might be tempted to try out their app.

Don’t do that.

Other parts might not even be the app itself.

Other parts might just be a web of links in how they’ve weaved the entire GitHub repo.

It’s hard for the human eye to scan, but in each MD, in each file, there could be a comment. There could be a link to another line in another piece of code.

And because you’re not the human interacting with this project directly, when your AI agent interacts with their reports, those instructions could potentially compromise your environment.

And if you’re now an engineer who does relevant work for a big company, you’re a DevOps engineer, you’re a senior software engineer, you have access to servers.

Eventually, your compromise could become the compromise of people around you, and potentially the company as well.

And this is how a large-scale compromise can happen.

Because an AI agent interacted with untrusted content on your computer, simply because you were trying to scan through an issue without having to read everything yourself.

And eventually, that vulnerability in an extension you’re already using could become part of the attack chain.

It scans stuff.

It wakes up.

It runs through and, if the permissions and security controls allow it, gets authorized to send them your information.

And that’s how you have your config files flying, your ENV, your GitHub credentials, and all of it just out there.