Someone bought 30 WordPress plugins and planted a backdoor in all of them

saltyoldman

I see a future where there are LLM vetted repos for Java, Python, Go, etc... And it will cost $1 to submit a release candidate (even for open source) edit: The idea is the $1 goes towards the tokens required to scan the source code by an LLM, not simply cost a dollar for no other reason that raising the bar. First submission is full code scan, incremental releases the scanner focuses on the diffs.

bradley13

Whenever I look at a web project, it starts with "npm install" and literally dozens of libraries get downloaded. The project authors probably don't even know what libraries their project requires, because many of them are transitive dependencies. There is zero chance that they have checked those libraries for supply chain attacks.

meteyor

So how was this attack gonna generate "revenue" for the attacker? What kind of info did they get hold of?

ValentineC

This somehow reminds me of the irony that was Secure Custom Fields: https://news.ycombinator.com/item?id=41821336

spankalee

I really wish that the FAIR package manager project had been successful, but they recently gave up after the WordPress drama died down. https://fair.pm/ FAIR has a very interesting architecture, inspired by atproto, that I think has the potential to mitigate some of the supply-chain attacks we've seen recently. In FAIR, there's no central package repository. Anyone can run one, like an atproto PDS. Packages have DIDs, routable across all repositories. There are aggregators that provide search, front-ends, etc. And like Bluesky, there are "labelers", separate from repositories and front-ends. So organizations like Socket, etc can label packages with their analysis in a first class way, visible to the whole ecosystem. So you could set up your installer to ban packages flagged by Socket, or ones that recently published by a new DID, etc. You could run your own labeler with AI security analysis on the packages you care about. A specific community could build their own lint rules and label based on that (like e18e in the npm ecosystem. Not perfect, but far better than centralized package managers that only get the features their owner decides to pay for.

chromacity

This is a perfect illustration of what cracks me up about the hyperbolic reactions to Mythos. Yes, increased automation of cutting-edge vulnerability discovery will shake things up a bit. No, it's nowhere near the top of what should be keeping you awake at night if you're working in infosec. We've built our existing tech stacks and corporate governance structures for a different era. If you want to credit one specific development for making things dramatically worse, it's cryptocurrencies, not AI. They've turned the cottage industry of malicious hacking into a multi-billion-dollar enterprise that's attractive even to rogue nations such as North Korea. And with this much at stake, they can afford to simply buy your software dependencies, or to offer one of your employees some retirement money in exchange for making a "mistake". We know how to write software with very few bugs (although we often choose not to). We have no good plan for keeping big enterprises secure in this reality. Autonomous LLM agents will be used by ransomware gangs and similar operations, but they don't need FreeBSD exploit-writing capabilities for that.

shevy-java

Well - that kind of shows that WordPress is still popular. :)

ChuckMcM

I don't think companies appreciated just how much they gave up when they outsourced "IT".

toniantunovi

The supply chain attack surface in WordPress plugins has always been particularly dangerous because the ecosystem encourages users to install many small single-purpose plugins from individual developers, most of whom aren't security-focused organizations. Buying out an established plugin with a large install base is a clever approach because you inherit years of user trust that took the original developer a long time to build. The deeper structural issue is that plugin update notifications function as an implicit trust signal. Users see "update available" and click without questioning whether the author is still the same person. A package signing and transfer transparency system similar to what npm has been working toward would help here, but the WordPress ecosystem has historically moved slowly on security infrastructure.

EGreg

I used to think that HN is full of enlightened open minded people who are open to correcting misconceptions if presented with new evidence, and adopting better practices. But I have encountered a lot of groupthink, brigading downvotes etc. So I stopped having high expectations over the years. In the case of Wordpress plugins, it’s bloody obvious that loading arbitrary PHP code in your site is insecure. And with npm plugins, same thing. Over the years, I tried to suggest basic things… pin versions; require M of N signatures by auditors on any new versions. Those are table stakes. How about moving to decentralized networks, removing SSH entirely, having a cryptocurrency that allows paying for resources? Making the substrate completely autonomous and secure by default? All downvoted. Just the words “decentralized” and “token” already make many people do TLDR and downvote. They hate tokens that much, regardless of their necessity to decentralized systems. So I kind of gave up trying to win any approval, I just build quietly and release things. They have to solve all these problems. These problems are extremely solvable. And if we don’t solve them as an industry, there’s going to be chaos and it’s going to be very bad.

pluc

Was it Automattic again?

ramon156

Same day that I submit my own plug-in :( hopefully doesn't interfere with anything.

ashishb

WordPress was great because of the plugins. WordPress is now a dangerous ecosystem because of the plugins and their current security model. I moved to Hugo and encourage others to do so - https://ashishb.net/tech/wordpress-to-hugo/

gonesilent

Rinse repeat. Same thing happens with plugins.

cold_tom

The scariest part isn’t even the backdoor itself, it’s how normal the acquisition looked.Buying a trusted plugin and pushing an update is basically indistinguishable from legitimate maintenance. There’s no real signal for users to question it

aksss

I can foresee a modern code-signing regimen with paid gatekeepers coming to mitigate the risk of supply chain attacks. Imagine the purported strength of mythos automating scans of PRs or releases with some manner of indelible and traceable certification. There's some industrious company - a modern verisign of old - that will attempt to drop in a layer of $250-500 per year fees for that service, capture the app stores to require it. Call me a cynical bastard, but "I was there, Gandalf".

0xbadcafebee

This is interesting, because not only was this not a hack (someone bought the plugin and changed its operation), it's something that would be solved by a separate solution I have to security vulnerabilities in general. A software building code could provide a legal framework to hold someone liable for transferring ownership of a software product and significantly altering its operation without informing its users. This is a serious issue for any product that depends on another product to ensure safety, privacy, financial impact, etc. It could add additional protections like requiring that cryptographic signature keys be rotated for new owners, or a 30-day warning period where users are given a heads up about the change in ownership or significant operation of the product. Or it could require architectural "bulkheads" that prevent an outside piece of software from compromising the entire thing (requiring a redesign of flawed software). The point of all this would be to prevent a similar attack in the future that might otherwise be legal. But why a software building code? Aren't building codes slow and annoying and expensive? Isn't it impossible to make a good regulation? Shouldn't we be moving faster and cheaper? Why should I care? You should care about a building code, because: 1. These major compromises are getting easier, not harder. Tech is big business, and it isn't slowing down, it's ramping up. AI makes attacks easier, and attackers see it's working, so they are more emboldened. Plus, cyber warfare is now the cheaper, more effective way to disrupt operations overseas, without launching a drone or missile, and often without a trace. 2. All of the attacks lately have been preventable. They all rely on people not securing their stacks and workflows. There's no new cutting-edge technology required; you just need to follow the security guidelines that security wonks have been going on and on about for a decade. 3. Nobody is going to secure their stack until you force them to. The physical realm we occupy will never magically make people spontaneously want to do more effort and take more time just to prevent a potential attack at some random point in the future. If it's optional, and more effort, it will be avoided, every time. "The Industry" has had decades to create "industry" solutions to this, and not only haven't they done this, the industry's track record is getting worse. 4. The only thing that will stop these attacks is if you create a consequence for not preventing them. That's what the building code does. Hold people accountable with a code in law. Then they will finally take the extra time and money necessary to secure their shit. 5. The building code does not have to be super hard, or perfect. It just has to be better than what we have now. That's a very low bar. It will be improved over time, like the physical world's building code, fire code, electrical code, health & safety code, etc. It will prevent the easily preventable, standardize common practice, and hold people accountable for unnecessarily putting everyone at risk. I keep saying it again and again. I get downvoted every time, but I don't care. I'll keep saying it and saying it, until eventually, years from now, somebody who needs to hear it, will hear it.

fblp

Hear me out. Mergers and acquisitions that substantially lesson market competition can be blocked by governments, or even require approval in certain jurisdictions. https://en.wikipedia.org/wiki/Mergers_and_acquisitions Maybe mergers or acquisitions that substantially impact security should require approval by marketplaces (industry governance), and notification and approval by even governments?

tap-snap-or-nap

Accepting unknown packages is just another form of vibe coding.

Projectiboga

So how should everyday users attempt to avoid this risk? And how to stay vigilant?