Live data from Hacker News

Microsoft's open source tools were hacked to steal passwords of AI developers

techcrunch.com

131–140 of 211 posts

Re: Microsoft's open source tools were hacked to steal passwords of AI developers

#131

Please, someone explain how it's possible to add obfuscated file to so many repositories? Do they don't have any code reviews? Also, the title is misleading, setup adds config to be auto executed by people who work on the repo. They would have to use vscode/cursor/claude/gemini. People who use codex / opencode / other harnesses are safe I guess. Details: https://www.stepsecurity.io/blog/miasma-worm-hits-microsoft-...

Many of the malicious commits show as an author `github-actions `. Which means that they are authenticating as internal github CI/CD stuff and that there are so many of those that no possible automated tool can find the poison in the mountain of chaff.

So this is related to the Sept 2025 security breach of Github.

> The five repos carry 1,459 GitHub stars between them, mantine-datatable alone accounting for 1,225. Stars are a rough proxy for how many developers have the source checked out locally, which is the population this attack targets.

> Every commit: unsigned, github-actions identity, chore: update dependencies [skip ci], the same six-file footprint. A 49-second sweep across five repos is automation, not a human committing. This matches Shai-Hulud self-propagation: harvest a GitHub token with write access from a prior infection, then push the persistence payload into every repo the token can reach.

https://safedep.io/miasma-worm-ai-coding-agent-config-inject...

What it is doing: https://safedep.io/config-files-that-run-code/

I'm not related to those guys. That's the simplest detailed explanation of what is happening that I've found.

Re: Microsoft's open source tools were hacked to steal passwords of AI developers

#133
post #45

Earlier quoted context omitted.

You can vibe code safely for sure. I am not saying vibe coding is the issue. The issue is that a typical developer might be working on a lot more projects that run concurrently then they used to. And because of the various nature of the project the risk is significantly increased. Scale this across the workforce and you not just doubled the problem.

You can vibecode docs and tests also but I'm truly not seeing more of those. In the end it can just be a culture thing. A dev who was going to write docs and tests before is going to have a LLM generate docs and tests today. Same with safe practices and defensive coding. The machine does whatever you want from it, for most that's "just get the job done I don't care". So that's the output.

If I vibe code a project, that involves docs and tests as well. Obviously I do not, at any point, do anything blindly and there are some iterations for everything. I always double-check, and I do not use "agents", I do everything manually. I always check what the LLM is thinking, in real-time. I might be old school, but that allows me to write code that is not a pile of shit. :P I am still conscious about quality.

Re: Microsoft's open source tools were hacked to steal passwords of AI developers

#134
post #20

I strongly suspect this is a case of classic personal access tokens being used in an unclean way. If you are going to be handing tokens to AI agents on weird openclaw contraptions, you should try to use the fine grained variants. My GitHub account spans 3 organizations with wildly differing policies. The fact that classic tokens are even still allowed blows my mind a bit. You should be required to manually opt in eac…

You are correct but the issue is permission management with finegrained tokens is nighmare. It is not easy to decide what is correct and what is needed for some operation. Furthermore, often software devs think it is important to focus on code rather than permissions - as it is for someone else's responsibility....

Sometimes the basic things missing in the programming world just shock me. How is anyone supposed to know what permissions to give in these systems that have literally hundreds of fine-grained permissions, many of which can also have scope? Even if they're "documented" we all know from experience that some textual descriptions of a permissions won't capture when it is actually used in the code.

Why isn't it standard to have a security log that shows what permissions were requested, with what scope, so we can at least create a minimal set of permissions by trying an operation, seeing what permissions are necessary, and then setting just the needed permissions? If you're worried about that log itself becoming a compromise, make it something that is off by default, and maybe automatically turns off after some period of time, or make me use a burner token for this operation, or something, but the alternative is the world of excessively-broad permissions that we live in now. Why isn't there a helper mode that a dev can use to point at an interaction and say "now give me minimal permissions for those interactions", not only to configure a given key but so we can learn what permissions actually mean in practice?

We're given these super complicated knobs, but all we get for using them is a few textual blurbs about the settings and the blame if we don't configure them exactly correctly, and also the blame if something breaks because we were too tight with the permissions.

This seems such a basic tool to use these super complicated systems yet I've never seen them anywhere on the web.

Perhaps ironically, perhaps just because it was already complicated enough and needed a way to approach usable, the notoriously difficult to use SELinux uses this as the more-or-less standard way of setting permissions. I can't believe I'm missing SELinux.

Re: Microsoft's open source tools were hacked to steal passwords of AI developers

#135
post #127
post #66

Earlier quoted context omitted.

> Do they don't have any code reviews? I have a good friend that works for one of the giants(I can't say which one for obvious reasons but S&P 500). He's been working there for quite a while now, so far he hasn't seen what the project he works on looks like, has the repo cloned and knows what language is used but nothing beyond that. Everything is slopped together. His project is the authentication and authorization…

Maybe the company or the CEO are invested in AI companies. Half of this tokenmaxxing is ordered by legitimately insane people, the other half has vested interests. When that boost disappears after the IPOs, everything will crash.

> When that boost disappears after the IPOs, everything will crash.

Don't threaten me with a good time(also unironically).

Re: Microsoft's open source tools were hacked to steal passwords of AI developers

#136
post #53
post #51

Nobody should do 'npm install' or 'pip install' on their machine. Using a proper sandboxing( https://github.com/ashishb/amazing-sandbox ) regularly will drastically limit the blast radius of these attacks.

> Nobody should do 'npm install' or 'pip install' on their machine. What alternative do you suggest? Do you mean not install outside a sandbox?

I've been playing around with declarative container configurations: https://github.com/AdrianVollmer/ContainerConductor (It's not ready, don't use it!)

It will always introduce friction, though.

Modern software development is simply too fast to be reviewed properly.

Re: Microsoft's open source tools were hacked to steal passwords of AI developers

#137
post #48

Earlier quoted context omitted.

I argued for years that we had too few workers for our total project count and management argued that most projects were idle and so it was fine to have so many per worker. Welp.

I think web-based IDEs like GitHub Codespaces (but even VSCode with tunnels) is part of the solution because at the very least you can get an isolated dev environment per project. I've been advocating for this for as long as I remember. Unfortunately, most developers don't like them so it is a though sell.

> I think web-based IDEs like GitHub Codespaces (but even VSCode with tunnels) is part of the solution

I am against proprietary SAAS online in browser dependencies.

Re: Microsoft's open source tools were hacked to steal passwords of AI developers

#139
post #59

Earlier quoted context omitted.

In this scenario the malware will not be on the device but in an isolated dev environment on a remote machine. So it will have access to whatever was configured in that repo but hopefully the project is isolated enough to ensure containment and prevent cross-pollination.

I don't think the cloud (someone else's computer) is the best solution. The sanitation problem can be mitigated by compartimentization but the cloud aspect also adds brittleness and new attack vectors. Why not set up proper containers (or VMs) locally? And why not wait a little till local LLMs catch up? Maybe just a personal itch, but having your dev environment elsewhere feels so gross to me..

That is the problem. You outline perfectly how a developer sees the situation.

On the other hand ephemeral cloud environment with proper security controls makes a lot of sense if the goal is to isolate and control.

If everyone was following the protocol we wouldn't have had the problem to begin with.

Re: Microsoft's open source tools were hacked to steal passwords of AI developers

#140
post #58

Earlier quoted context omitted.

But now he needs to develop, test and maintain that code. Left pad is easily hand coded, react framework not so much.

his projects were GUIs for machines (HMI)

That’s not really my point. My point is some libraries are easily replaced and others are massive, complex and need ongoing support.

By the same logic, he could avoid system dependencies by writing his own OS. But it obviously doesn’t scale.

I’m all for an anti-library ethos, as long as the pros and cons are carefully considered and wheels are only reinvented when the cost/risk ratio is right.

Post reply on HN