This Week In Security: State Malware, State Hardware Bans, And Stuxnet Before Stuxnet Was Cool

Making headlines everywhere is the CopyFail Linux kernel vulnerability, which allows local privilege escalation (LPE) from any user to root privileges on most kernels and distributions.

Local privileges escalations are never good, but typically are not “Internet-melters”: they are significantly less dangerous than remote vulnerabilities, but are often combined with a remote vulnerability to gain complete access to a system.

This time, the vulnerability is in the Linux kernel handling of cryptographic functions used in IPSec. The mistake allows writing into the in-memory cache of file data; this allows modifying what the system thinks a file contains, without ever touching the contents of the actual file. Coupled with a suid binary — a binary configured to always run as root, no matter what user starts it — the binary can be modified to run any code as root. In this case, that means launching a new interactive shell. Nearly every distribution includes several standard suid binaries, such as the command su which requires root privileges to switch users.

The bug is pervasive, impacting kernels from 2017, and can be triggered on any distribution where the IPSec kernel modules are enabled and loaded, which is the vast majority of them. Kernel patches are available, and most distributions should have them at this point. For the average home user, you’ll want to upgrade as soon as is practical; for services with untrusted users or containerized systems which might run untrusted workloads, if updating immediately is not practical, Theori has mitigation suggestions on the blog post. Continue reading “This Week In Security: State Malware, State Hardware Bans, And Stuxnet Before Stuxnet Was Cool”

This Week In Security: The Supply Chain Has Problems

The biggest story of the week is a new massive supply chain breach, which appears to be unrelated to the previous massive supply chain breaches, this time of the Axios HTTP project.

Axios was created as a more developer-friendly Javascript HTTP interface for node.js, giving a promise-based API instead of the basic callback API. (Promise-based programming allows for simpler coding workflows, where a program can wait for a promise to be fulfilled, instead of the developer having to manage the state of every request manually.) Javascript has since provided a modern Fetch API that provides similar functionality, but Axios remains one of the most popular packages on the node.js NPM repository, with 100 million weekly downloads.

The lead developer of Axios believes he was compromised by a collaboration request – a common tactic for phishing specific targets: a project for an IDE like VS Code can include code that executes on the developers system when the project is run. Even outside a traditional IDE, common development tools like configure scripts and makefiles can easily run commands.

Socket.dev breaks down the attack in detail. Once the attackers had credentials to publish to the Axios NPM, they inserted malware as a new dependency to Axios, instead of modifying Axios itself. This likely helped the attack bypass other security checkers. The dependency – plain-crypto-js – is itself simply a copy of a popular encryption utility library, but one which executes additional code during the post-installation process available to all NPM packages. Continue reading “This Week In Security: The Supply Chain Has Problems”

This Week In Security: Second Verse, Worse Than The First

Isn’t there some claim events come in threes? After the extremely rare leak of the iOS Coruna exploit chain recently, now we have details from Google on a second significant exploit in the wild, dubbed Darksword.

Like Coruna, Darksword appears to have followed the path of government security contractors, to different government actors, to crypto stealer. It appears to focus on exploits already fixed in modern iOS releases, with most affecting iOS 18 and all patched by iOS 26.3.

Going from almost no public examples of modern iOS exploits to two in as many weeks is wild, so if mobile device security is of interest, be sure to check out the Google write-up.

Another FBI Router Warning

The second too early to be retro – but too important to ignore – repeat security item is a second alert by the FBI cautioning about end-of-life consumer network hardware under active exploitation, with the FBI tracking almost 400,000 device infections so far.

Like the warning two weeks ago, the FBI calls out a handful of consumer routers – but this time they’re devices that may actually still be service in some of our homes (or our less cutting edge friends and family), calling out devices from Netgear, TP-Link, D-Link, and Zyxel:

  • Netgear DGN2200v4 and AC1900 R700
  • TP-Link Archer C20, TL-WR840N, TL-WR849N, and WR841N
  • D-Link DIR-818LW, 850L, and 860L
  • Zyxel EMG6726-B10A, VMG1312-B10D, VMG1312-T20B, VMG3925-B10A, VMG3925-B10C, VMG4825-B10A, VMG4927-B50A, VMG8825-T50K

While many of these devices are over ten years old, they still support modern networking – some of them even supporting 802.11ac (also called Wi-Fi 5).  Unfortunately, since support has been ended by the manufacturers, publicly disclosed vulnerabilities have not been patched (and now never will be, officially) Continue reading “This Week In Security: Second Verse, Worse Than The First”

A grim reaper knocking on a door labelled "open source"

What About The Droid Attack On The Repos?

You might not have noticed, but we here at Hackaday are pretty big fans of Open Source — software, hardware, you name it. We’ve also spilled our fair share of electronic ink on things people are doing with AI. So naturally when [Jeff Geerling] declares on his blog (and in a video embedded below) that AI is destroying open source, well, we had to take a look.

[Jeff]’s article highlights a problem he and many others who manage open source projects have noticed: they’re getting flooded with agenetic slop pull requests (PRs). It’s now to the point that GitHub will let you turn off PRs completely, at which point you’ve given up a key piece of the ‘hub’s functionality. That ability to share openly with everyone seemed like a big source of strength for open source projects, but [Jeff] here is joining his voice with others like [Daniel Stenberg] of curl fame, who has dropped bug bounties over a flood of spurious AI-generated PRs.

It’s a problem for maintainers, to be sure, but it’s as much a human problem as an AI one. After all, someone set up that AI agent and pointed at your PRs. While changing the incentive structure– like removing bug bounties– might discourage such actions, [Jeff] has no bounties and the same problem. Ultimately it may be necessary for open source projects to become a little less open, only allowing invited collaborators to submit PRs, which is also now an option on GitHub.

Combine invitation-only access with a strong policy against agenetic AI and LLM code, and you can still run a quality project. The cost of such actions is that the random user with no connection to the project can no longer find and squash bugs. As unlikely as that sounds, it happens! Rather, it did. If the random user is just going to throw their AI agent at the problem, it’s not doing anybody any good.

First they came for our RAM, now they’re here for our repos. If it wasn’t for getting distracted by the cute cat pictures we might just start to think vibe coding could kill open source. Extra bugs was bad enough, but now we can’t even trust the PRs to help us squash them!

Continue reading “What About The Droid Attack On The Repos?”

This Week In Security: Anthropic, Coinbase, And Oops Hunting

Anthropic has had an eventful couple weeks, and we have two separate write-ups to cover. The first is a vulnerability in the Antropic MCP Inspector, CVE-2025-49596. We’ve talked a bit about the Module Context Protocol (MCP), the framework that provides a structure for AI agents to discover and make use of software tools. MCP Inspector is an Open Source tool that proxies MCP connections, and provides debugging information for developers.

MCP Inspector is one of those tools that is intended to be run only on secure networks, and doesn’t implement any security or authentication controls. If you can make a network connection to the tool, you can control it. and MCP Inspector has the /sse endpoint, which allows running shell commands as a feature. This would all be fine, so long as everyone using the tool understands that it is not to be exposed to the open Internet. Except there’s another security quirk that intersects with this one. The 0.0.0.0 localhost bypass.

The “0.0.0.0 day exploit” is a bypass in essentially all the modern browsers, where localhost can be accessed on MacOS and Linux machines by making requests to 0.0.0.0. Browsers and security programs already block access to localhost itself, and 127.0.0.1, but this bypass means that websites can either request 0.0.0.0 directly, or rebind a domain name to 0.0.0.0, and then make requests.

Continue reading “This Week In Security: Anthropic, Coinbase, And Oops Hunting”

Track Your GitHub Activity With This E-Ink Display

If you’re a regular GitHub user you’ll be familiar with the website’s graphical calendar display of activity as a grid. For some of you it will show a hive of activity, while for others it will be a bit spotty. If you’re proud of your graph though, you’ll want to show it off to the world, and that’s where [HarryHighPants]’ Git Contributions E-Ink Display comes in. It’s a small desktop appliance with a persistent display, that shows the current version of your GitHub graph.

At its heart is an all-in-one board with the display and an ESP32 on the back, with a small Li-Po cell. It’s all put in a smart 3D printed case. The software is the real trick, with a handy web interface from which you can configure your GitHub details.

It’s a simple enough project, but it joins a growing collection which use an ESP32 as a static information display. The chip is capable of more though, as shown by this much more configurable device.

The Billionth Repository On GitHub Is Really Shitty

What’s the GitHub repository you have created that you think is of most note? Which one do you think of as your magnum opus, the one that you will be remembered by? Was it the CAD files and schematics of a device for ending world hunger, or perhaps it was software designed to end poverty? Spare a thought for [AasishPokhrel] then, for his latest repository is one that he’ll be remembered by for all the wrong reasons. The poor guy created a repository with a scatalogical name, no doubt to store random things, but had the misfortune to inadvertently create the billionth repository on GitHub.

At the time of writing, the 💩 repository sadly contains no commits. But he seems to have won an unexpectedly valuable piece of Internet real estate judging by the attention it’s received, and if we were him we’d be scrambling to fill it with whatever wisdom we wanted the world to see. A peek at his other repos suggests he’s busy learning JavaScript, and we wish him luck in that endeavor.

We think everyone will at some time or another have let loose some code into the wild perhaps with a comment they later regret, or a silly name that later comes back to haunt them. We know we have. So enjoy a giggle at his expense, but don’t give him a hard time. After all, this much entertainment should be rewarded.