Supply chain attacks continue, with Microsoft’s own open source Azure repositories being automatically disabled by GitHub following a compromise of the packages by the Miasma worm.
OpenSourceMalware reports that the infection resulted in 73 Microsoft-related package repositories being flagged and taken offline in a little over a minute by the GitHub automated security system, with over 40 repositories being related to Azure and the rest distributed across the Microsoft organization.
The center of the infection appears to be the Microsoft Durabletask package, which was previously compromised in May and used to push infected packages to PyPi. Considering that all of the supply chain worms also steal credentials for every service they can find in the build or developer environment they infect, it seems likely that credentials stolen in the original attack were never properly disabled.
Disabling the repositories can help stem the infected packages and GitHub actions from spreading and infecting more organizations, but of course any build processes depending on those packages will not function. In May, the Durabletask package showed over 400,000 downloads per month.
The OpenSourceMalware report includes a full list of the impacted repositories.
Microsoft Fixes GitHub Token Exploit
Microsoft has finally fixed a bug in GitHub which could steal a GitHub authentication token with access to all of an accounts repositories via the embedded web-based VSCode editor which is part of GitHub itself.
Ammar Askar discovered the bug and discusses it on their blog; by manipulating the sandboxed VS Code into treating an embedded web view as user keyboard strokes, it is possible to to cause it to install a VS Code extension which is then used to exfiltrate the GitHub authentication tokens of the user using the embedded VS Code instance.
TP-Link Takeover via Unregistered Domain
Julian B demonstrates capturing traffic from TP-Link routers and access points thanks to an unregistered domain name in the firmware.
After finding an archive of the firmware releases for every TP-Link product, Julian simplified the list to the latest versions, and ran a custom scraper tool to extract domain names referenced in the firmware and search for matching domain names.
After registering an available domain, Julian began receiving requests from TP-Link devices checking in to a server which had lapsed, likely years ago. Fortunately, Julian reported the issue to TP-Link and was able to transfer the domain.
It’s unclear what the risks of the unregistered domain name were in the context of the TP-Link devices, however unregistered domain names can lead to all sorts of issues in the wrong situations.
A Pile of OpenSSL Vulns
The OpenSSL library has a new collection of vulnerabilities which range from low-severity flaws in message verification in functions which aren’t used in any of the OpenSSL implemented protocols to a high-severity use-after-free bug in PKCS7 handling which could be used to run arbitrary code.
Use-after-free bugs occur when a chunk of memory is dynamically allocated, then freed and returned to the memory pool, but a later piece of code re-uses the memory that is no longer claimed. In the meantime, this memory could have been assigned to another variable or otherwise restructured, leading to memory corruption. In the case of OpenSSL, the memory associated with a PKCS7 container (a certificate storage method) or a S/MIME message (usually used in secure email) can be manipulated into using freed memory.
The advisory warns that applications processing PKCS7 or S/MIME are affected; fortunately most uses of OpenSSL are unlikely to be directly impacted (neither of those functions are common in web servers or similar), but as always, update as soon as possible!
NightmareEclipse is Back
The researcher previously identified as NightmareEclipse, known for releasing advanced Windows vulnerabilities with working proof of concept code, has returned as MSNightmare releasing several new exploits after previously being removed from GitHub. Despite a strongly worded (and poorly received) public statement by Microsoft threatening criminal investigations, the researcher returns with the RoguePlanet vulnerability.
RoguePlanet exploits race conditions in Windows Defender under Windows 10 and Windows 11 to gain a system-level shell, a fairly common trend in the vulnerabilities found by this researcher.
Additionally, another BitLocker bypass has been released, called GreatXML, which unlocks BitLocker protected drives if a Windows Defender offline scan has ever been run.
Of course, these releases coincide with Patch Tuesday, so they’re unlikely to be addressed before the July patch day.
It appears Microsoft has backed down from their initial press release which appeared to claim that vulnerability research and development outside of the guidelines Microsoft decided would be treated as criminal behavior; this was not well received by much of the security industry. At the start of the modern security industry in the late 1990s, public release of vulnerabilities was common. Companies had no way to reach a security contact to get it fixed, simply did not care to fix it, or were actively hostile to researchers. Through years and decades of community programs, it is now normal to reach out to a company with security flaws and have an expectation they will be fixed, and often rewarded either monetarily through structured bounty programs like HackerOne or through public credit to the researchers who found the flaws (nobody wants to be paid in exposure, but security is now an industry, and having a well-known name and track record can be valuable.)
Unfortunately, recently, it seems Microsoft may have forgotten that while disclosure to the vendor has become the norm, it is simply a social contract. Having already publicly alienated one skilled researcher (NightmareEclipse), the company seems to be doing the best it can to alienate others by burning community good will. Expect more publicly released vulnerabilities in the wake.
Linux Arm Fixes
Phoronix reports that the Linux kernel has patched a critical-severity flaw on Arm CPUs in the memory allocation logic. The list of processors affected continues to grow, including some NVIDIA embedded platforms.
The flaw lies in specific ordering requirements for accessing memory via the TLB, or “Translation Lookaside Buffer”, a critical part of the virtual memory and memory protection system. The TLB is a cache of recently resolved lookups of physical memory locations, so any corruption of the TLB can cause invalid memory reads, leading to almost the same results as recent kernel vulnerabilities in the Linux page cache system which allowed binaries to be replaced in RAM.
The bug was found thanks to advisories from Arm themselves clarifying that additional protections were needed around modifications to the TLB cache on these chips. The real-world impact remains to be seen, but now that the bug and patches are public, I’d expect proof of concept code to follow soon after. It’s also safe to assume that this flaw affects other operating systems on Arm platforms, as well, but there is no public information yet.
FreeBSD Gets a Page-Cache Bug
FreeBSD racks up another kernel bug this week, the amusingly named Bumsrakete (“Bum Rocket” or “Bang Rocket”), complete with a well-crafted troll of an announcement, right down to the use of Comic Sans for the announcement site.
Beneath the crap-posting exterior lies a legitimate CVE (CVE-2026-45257) where any user with access to the PMAP_HAS_DMAP system (the standard configuration) can overwrite the disk page cache in memory. This is the FreeBSD flavor of the kernel cache flaws in Linux used by CopyFail, DirtyPipe, and friends, and even involves decryption primitives in the kernel similar to the original CopyFail process.
It’s not surprising that following the multiple disk cache corruption bugs in Linux disclosed this spring, other operating systems with similar functionality are being examined and new flaws showing up.
NPM to Block Auto Install Scripts
NPM is introducing major changes in NPM 12 to attempt to stem the flood of supply-chain vulnerabilities by removing the automatic execution of commands from the install phase of packages and disabling the use of remote URLs as dependencies.
Most of the NPM-based worms infecting packages at record rates use the install script process, hooking either pre-install, install, or post-install scripts to run commands automatically as a package dependency is included. Since the install script runs as the user (or build service) pulling the dependencies, it has direct access to any credentials or files that user and service has. Under the new model an infected package could still perform malicious actions inside a compiled application or site, but a major mechanism for automatic spreading of malicious packages will be addressed.
It’s good to see progress made towards addressing the underlying weaknesses in the package ecosystem which aid in spreading malicious packages.
Libinput Security Fix
The libinput library sees a pair of security fixes this week, centered around the handling of device names for uinput and uhid devices. Maliciously named devices could execute commands as root.
To be able to exploit this, a user needs to already be on the system and have the ability to create new uinput devices. This is normally restricted to root, however if steam-devices, antimicrox, or kdeconnectd packages are installed, the permissions to create a device are modified and any user logged into the system can create a uinput device.
Go forth, and update!
Mini Shai-Hulud Hides in Censorship
The Shai-Hulud, Mini Shai-Hulud, and Miasma worms have been prolifically infecting packages on NPM and PyPi as well as VS Code extensions and GitHub actions. Using a combination of captured worm code and publicly released versions of the worms, researchers have been reverse engineering the behavior of the worm using the decrypted payloads.
Amusingly, they have discovered that the Mini Shai-Hulud worm attempts to hide from automatic analysis and detection via AI prompt injection. The payload file executed during a NPM package install contains a block of comment text referencing biological and nuclear weapons, topics many AI models refuse to allow.
Interpreting the comment as a banned request, the AI models may immediately stop processing the rest of the file, either blocking further analysis by researchers or disabling AI-based malware detection tools scanning for malicious payloads.
Another Record Patch Tuesday
For the second time this year, Microsoft has a record-breaking number of fixes included in Patch Tuesday with more than 200 security fixes, including fixes for two vulnerabilities released by NightmareEcllipse in recent weeks, however none of the fixes specifically reference the conflict between Microsoft and the researcher.
Outside of the Patch Tuesday fixes, Microsoft also fixed 360 browser vulnerabilities.
With the increasing automatic bug finding via AI tools, this may become the new normal for Patch Tuesday fix counts.
Python Linter Blocks Shai-Hulud
Sometimes pedantry pays off. StepSecurity brings the tale of a supply chain infection of the popular Pythagoria-io GPT Pilot package, an AI coding assistant tool. After one of the developers was infected by the Miasma supply chain worm, the worm performed the typical trick of attempting to reversion and push compromised versions of all accessible packages.
This time, the commits containing the trojaned were rejected by the Python linter, Ruff, for not matching the style guidelines of the project. Linters analyze code for style, comments, and syntax (think the pretty printing in a code editor that highlights incorrect tabs and spaces or deprecated functions.)
The developer will still need to clean up their system and make sure to revoke all tokens the worm has access to, but the project itself was spared infection by a humble syntax styler.
Deep Dive into Miasma
Finally, we have a dive into the Miasma worm thanks to SafeDep.
The payload source for Miasma has been open sourced, apparently by some of the developers of the malware. Previously the payload was heavily encrypted, however progress was made in decoding it during the initial wave of attacks. By open sourcing the worm, the developers likely hope to muddy the waters by creating copy-cat worms using modified techniques and signatures.
SafeDep takes a deep look into the capabilities of the payload, noting several unusual abilities including disabling GitHub environment protections, a full list of the credential harvesting capabilities, and more. Be sure to check out the full write up for an extremely detailed breakdown of each major component of the worm and the actions it takes, if that sort of thing is interesting to you!
https://www.gamingonlinux.com/2026/06/the-arch-linux-aur-had-over-400-packages-compromised-with-malware/
Oof. Excuse me while I go blacklist the npm package on my system…
Supply chains will always be the achilleas heel.
How are you even supposed to set up a reasonably secure dev workstation (especially if it pulls double duty as your main gaming desktop)?
Packages for building are getting infected left and right, okay move to using something like devcontainers.
VSCode plugins are also getting infected and Microsoft has shown signs elsewhere of infections, VM the entire thing?
Problems with that are now if you are doing any work with GPUs you either need multiple ones (expensive) or one that supports sr-iOV (so basically just an Intel).
Also as much as I’m loving Bazzite, the downsides of an atomic distro really gets shown off when you need to mess around in getting all the packages you need together.
As dumb as it sounds, the best way I’ve Found it to use separate machines. I’d love to have everything in a separate virtual machine, container, etc. but that’s hard to do without very performant hardware.
Depends on what your needs are, on one hand $600 can get you started with B860 and Ultra 270K and some (~32GB) RAM.
On the other hand $600 goes a good way toward a few 6-core machines of varying ages (if your needs are fairly low something like Coffeetime BIOS mod can get a $45 Xeon E3 chip runnin on a DDR3 consumer motherboard. Performs between an 8700 and an 8700K).
I used to physically switch sata ssd… but anything new is nvme and stopped doing that.
Maybe after an attack I’ll go back to sata.
HBA Zoning on SAS.
After looking at it, seems costly when you have sata already and only need a boot drive swap.
You could run OS on Thunderbolt? Shouldn’t be too much of a performance hit. Alternatively you can get NVMe bays and enclosures. Yeah it’s a bit expensive. I’ve got some Thunderbolt enclosures because I shucked a drive and also was building a Nano eGPU.
D’oh, I forgot about Oculink, there are M.2 to Oculink adapters. Although at that point couldn’t you just have the power to the adapter board on a single pole double throw switch, only one drive at a time?
Not terrible. Looks to be around $120 for two enclosures, a cable and an adapter.
https://www.phoronix.com/news/AMD-GIM-Open-Source
Should be already there.
No solution including entirely separate machines is a complete safety net, as presumably they will all be on your home network, likely use some of the same USB peripheral (which may be purchased bad or polluted by bad actors – for instance the Logitech unifying receivers are so common as are relatively normal hobby micro’s running qmk, making a large enough user pool that it could be worth targeting their upgrade mechanisms) etc. So unless you have really insane attention to all the details there is always a vector for the bad guys.
But practically it isn’t that bad to do well enough on a single computer, if you have a Linux host machine and VM’s you can use VirGL to share the one GPU between them all at once if you must which will help with isolation of your varied uses and the budget for real performance from both. But ultimately I’d suggest just get a CPU with onboard, for 99% of folks that do want a ‘real’ GPU on both the ‘secure’ host and the ‘dirty’ guests you still only need 1 really performant GPU so any onboard graphics capability is probably good enough. Though if you are building a new system Strix Halo like the framework desktop might be the right choice – that onboard GPU is a monster, the RAM allocation between CPU and GPU is flexible and can come from a pretty huge pool, though Rampocalipse has driven the prices up heaps. But even then its actually really good value – a GPU that is more flexible than any consumer one able to address way more RAM if LLM etc is part of you use case and still in the modern rather high end discrete GPU performance bracket, its no 5090 by all accounts, probably not quite a 4090 but you didn’t pay 4090 prices for a complete working system with performant CPU cores and lots of RAM too…
Or and this is the choice I effectively made do just have separate computers, and external boot drives (or perhaps network boot from the ‘secure’ machine) for some uses – as likely your secure isolated ones and/or riskier tasks don’t all need anything hugely performant and you don’t need to be quite so paranoid that the BIOS level sort of bug can make the external SSD/SD card insufficient isolation when you boot into a whole new filesystem on a new drive etc. So Pi4 upward, steamdeck, older system that isn’t up to the games you play, perhaps a 2nd hand surplus business machine can all provide a pretty cheap better than virtualiseation type methods level of safety.
Is it possible to configure (or, if they’re open-source and no easier option exists, modify) your systems to wait a few days between a new version coming out and them installing it? Obviously, that would also impact actual urgent security updates, but you could manually approve those after an out-of-band notification, such as a post on the project’s blog.
Sooner or later someone might come up with a code signing scheme where two (or some other plural number) separate developers of a project have to sign each release with keys (or parts of a common key—I don’t remember exactly how this works or what it’s called to be able to look it up) they each uniquely hold. Actually, maybe that already exists?
There is much more worrying security news, playing out slowly enough not to be so easily noticed, which everyone seems to be ignoring, see here: https://dailysceptic.org/2026/06/05/googles-new-captcha-plans-will-create-a-two-tier-internet-only-accessible-to-those-with-approved-devices/ https://grapheneos.social/@GrapheneOS/116550899908879585 https://www.dedoimedo.com/computers/qr-codes.html Mike K., please do take a look at that stuff.
I’m not Mike, and I haven’t looked at those yet, but from the first one’s slug it seems related to these:
https://blog.cloudflare.com/eliminating-captchas-on-iphones-and-macs-using-new-standard/
https://blog.cloudflare.com/end-cloudflare-captcha/
https://blog.cloudflare.com/introducing-cryptographic-attestation-of-personhood/
https://developer.apple.com/news/?id=huqjyh7k
https://www.fastly.com/blog/private-access-tokens-stepping-into-the-privacy-respecting-captcha-less
https://friendlycaptcha.com/insights/private-access-tokens-potential/
Those are just DuckDuckGo search results from a few weeks ago when I saw the term “Private Access Token” somewhere from Cloudflare and looked it up. They talk about how much better they are for UX and privacy, but my main feeling when I read the first one (which is the only one I’ve really read, the others just having been left open in background tabs waiting for me to get back to them) was terror.
Cloudflare already has an unhealthy amount of power over the web (and maybe the rest of the internet too, but IDK) due to the popularity and working principle of their DDoS protection service, which is only growing IME, and this seems likely to increase that popularity due to the better UX and first-mover advantage.
I, like many people around here, like to use unconventional devices and software at least occasionally, and I guess those are never going to work with PATs.
They talk about the data being separated between Cloudflare (or another security service provider)—who knows only what website you’re visiting—and your device’s manufacturer—who knows only a bunch of data about hardware usage that they use to calculate that it’s being operated by a human—but currently most hardware manufacturers presumably don’t collect most of that data, and almost certainly not several times per day. And if you choose not to send your manufacturer such data (if they even allow you to choose that), then I guess you don’t get to use PATs.
If PATs are actually a good thing for users (all users, not just those who have the most potential to give big companies more money), then they didn’t do a good job of explaining how.
And it’s no surprise that the first hardware partner is the company best known for walled-gardenism. (Apple is good on user privacy, though.)