You probably don’t think about it much, but your PC probably has a TPM or Trusted Platform Module. Windows 11 requires one, and most often, it stores keys to validate your boot process. Most people use it for that, and nothing else. However, it is, in reality, a perfectly good hardware token. It can store secret data in a way that is very difficult to hack. Even you can’t export your own secrets from the TPM. [Remy] shows us how to store your SSH keys right on your TPM device.
Rowhammer attacks have been around since 2014, and mitigations are in place in most modern systems, but the team at gddr6.fail has found ways to apply the attack to current-generation GPUs.
Rowhammer attacks attach the electrical characteristics of RAM, using manipulation of the contents of RAM to cause changes in the contents of adjacent memory cells. Bit values are just voltage levels, after all, and if a little charge leaks across from one row to the next, you can potentially pull a bit high by writing repeatedly to its physical neighbors.
The attack was used to allow privilege escalation by manipulating the RAM defining the user data, and later, to allow reading and manipulation of any page in ram by modifying the system page table that maps memory and memory permissions. By 2015 researchers refined the attack to run in pure JavaScript against browsers, and in 2016 mobile devices were shown to be vulnerable. Mitigations have been put in place in physical memory design, CPU design, and in software. However, new attack vectors are still discovered regularly, with DDR4 and DDR5 RAM as well as AMD and RISC-V CPUs being vulnerable.
The GDDR6-Fail attack targets the video ram of modern graphics cards, and is able to trigger similar vulnerabilities in the graphics card itself, culminating in accessing and changing the memory of the PC via the PCI bus and bypassing protections.
For users who fear they are at risk — most likely larger AI customers or shared hosting environments where the code running on the GPU may belong to untrusted users — enabling error correcting (ECC) mode in the GPU reduces the amount of available RAM, but adds protection by performing checksums on the memory to detect corruption or bit flipping. For the average home user, your mileage may vary – there’s certainly easier ways to execute arbitrary code on your PC – like whatever application is running graphics in the first place!
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”
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.
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:
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”
Once upon a time, they told us we wouldn’t download a car, and they were wrong. Later, Zero Motorcycles stated in their FAQ that you cannot hack an electric motorcycle, a statement which [Persephone Karnstein] and collaborator [Mitchell Marasch] evidently took issue with. Not only can you hack an electric motorcycle, it is — in [Persephone]’s words — a security nightmare.
You should absolutely go over to [Persephone]’s website and check out the whole write-up, which is adapted from a talk given at BSides Seattle 2026. There’s simply way more detail than we can get into here. Everything from “what horridly toxic solvents would I need to unpot this PCB?” to the scripts used in de-compiling and understanding code, it’s all there, and in a lively and readable style to boot. Even if you have no interest in security, or electric motorcycles, you should check it out.
The upshot is that not only were Zero Motorcycles wrong when they said their electric motorcycles could not be hacked, they were hilariously wrong. The problem isn’t the motorcycle alone: it has an app that talks to the electronics on the bike, which take over-the-air (OTA) updates. What about the code linked to the VIN alluded to in that screenshot? Well, it turns out you just need a code structured like a VIN, not an actual number. Oops. By the end of it, [Persephone] and [Mitchell] have taken absolute control of the bike’s firmware, an so have them full control over all its systems.
Why cut the brake lines when you can perform an OTA update that will do the same thing invisibly? And don’t think you can just reset the bike to factory settings to fix it: they thought of this, and the purely-conceptual, never-deployed malware has enough access to prevent that. Or they could just set the battery on fire. That was an option, too, because the battery management system gets OTA updates as well.
To be clear, we don’t have any problem with a motorcycle that’s dependent on electronics to operate. After all, we’ve seen many projects that would meet that definition over the years. But the difference is none of those projects fumbled the execution this badly. Even this 3 kW unicycle, which has a computer for balance control, doesn’t see the need to expose itself. It’s horribly unsafe in very different ways.
The ides of security March are upon us — Qualys reports the discovery by their threat research unit of vulnerabilities in the Linux AppArmor system used by SUSE, Debian, Ubuntu, and Kubernetes as an additional security mechanism and application firewall.
AppArmor was added to Linux in 2010, and the vulnerabilities Qualys discovered have been present since 2017, and allow unprivileged (non-root) local users to elevate privileges by executing arbitrary code in the kernel, gaining root access, or perform a denial-of-service attack across the entire system by replacing all AppArmor behavior with “deny all” rules.
All Linux kernels since Linux 4.11 are vulnerable. If your Linux distribution enables AppArmor, and quite a few do, you’ll want to be updating as soon as fixes are available from your distribution maintainers. On systems with untrusted users, such as shared environments, VPS server environments, and the like, this is even more critical and urgent. Even on single-user systems, vulnerabilities like these allow other exploits, like the Python attack below, mechanisms to elevate their access and persistence.
At the time of writing, the full details of the AppArmor vulnerability are limited until the Linux Kernel team releases a stable version with the fixes for distribution maintainers. Qualys has published the technical write-up with the currently public information.
StepSecurity reports on a new campaign to infect Python projects on GitHub with a complex malware that, once deployed, appears to be yet another crypto and login stealer.
The attacker first gains access to the GitHub credentials via another info stealing worm – the Glassworm stealer infects VSCode extensions with over 35,000 downloads of infected extensions in October of 2025. Glassworm harvests NPM, GitHub, and OpenVSX credentials and sends them to a remote command and control (C2) server. It also harvests a wide range of crypto currency wallet extensions to steal crypto directly. Continue reading “This Week In Security: Linux Flaws, Python Ownage, And A Botnet Shutdown”
It’s no secret that Google really doesn’t like it that people are installing Android applications from any other source than the Play Store. Last year they proposed locking everyone into their official software repository by requiring all apps to be signed by verified developers, an identity which would be checked against a Google-maintained list. After a lot of pushback a so-called ‘advanced flow’ for installing even unsigned APKs would be implemented, and we now know how this process is supposed to work.
Instead of the old ‘allow installing from unknown sources’ toggle, you are now going to have to dig deep into the Developer Options, to tap the Allow Unverified Packages setting and confirm that nobody is forcing you to do this. This starts a ‘security delay’ of twenty-four hours after you restart the device, following which you can finally enable the setting either temporarily or permanently. It would seem these measures are in place to make it more difficult for a scammer to coerce a user into installing a malicious app — whether or not that’s a realistic concern or not, we’re not sure.
When we last covered this issue this ‘advanced flow’ had just been introduced as an appeasement option. In addition to this a limited free developer account was also pitched, which now turns out to allow for up to only 20 device installations. If you want more than this, you have to pay the $25 fee and provide your government ID.
Although Google’s public pitch is still that this is ‘for user security’, it will also mean that third-party app stores are swept up in these changes, with developers who publish on these stores subject to the same verification rules. This means that Android users will have to learn quickly how to enable this new option as it will be rolled out to more countries over the coming months.
The reality is that scammers will simply work around this issue by buying up already verified developer accounts. At the same time, it’ll cripple third-party app stores and indie developers who had intended to distribute their Android app by simply providing an APK download.
