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

March 27, 2026 by Mike Kershaw 16 Comments

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” →

Electric Motorcycles Don’t Have To Be Security Nightmares, But This One Was

March 25, 2026 by Tyler August 31 Comments

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.

This Week In Security: Linux Flaws, Python Ownage, And A Botnet Shutdown

March 20, 2026 by Mike Kershaw 12 Comments

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.

Python Projects Compromised

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” →

Google Unveils New Process For Installing Unverified Android Apps

March 20, 2026 by Maya Posch 93 Comments

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.

This Week In Security: Plenty Of Patches, Replacing Old Gear, And Phrack Calls For Papers

March 13, 2026 by Mike Kershaw 7 Comments

When Friday the Thirteenth and Patch Tuesday happen on the same week, we’re surely in for a good time.

Anyone who maintains any sort of Microsoft ecosystem knows by now to brace for impact come Patch Tuesday; March brings the usual batch of “interesting” issues, including:

Two high-risk Microsoft Office vulnerabilities (CVE-2026-26110 and CVE-2026-26113), both of which allow execution of arbitrary code with no user interaction other than opening a hostile file. Vulnerabilities like these are especially dangerous in environments where transferring Office documents is considered normal, such as (unsurprisingly) offices, but also for home users who may not be savvy enough to avoid opening hostile files. Arbitrary code execution allows the attacker to run essentially any commands the user would be able to run themselves, typically leveraging it to install remote access or keyboard logging malware.
Excel gets a different vulnerability, CVE-2026-26144, which allows leaking of data through a cross-site scripting vulnerability. Coupled with CoPilot Agent, this can be used to leak contents of spreadsheets, again with no direct user interaction.

On the server and container side, this month includes a fairly typical collection of patches for SQL Server, and vulnerabilities in the Microsoft-hosted device pricing and payment orchestrator services, which have been automatically patched by Microsoft. Continue reading “This Week In Security: Plenty Of Patches, Replacing Old Gear, And Phrack Calls For Papers” →

Secure Communication, Buried In A News App

March 9, 2026 by Lewin Day 28 Comments

Cryptography is a funny thing. Supposedly, if you do the right kind of maths to a message, you can send it off to somebody else, and as long as they’re the only one that knows a secret little thing, nobody else will be able to read it. We have all sorts of apps for this, too, that are specifically built for privately messaging other people.

Only… sometimes just having such an app is enough to get you in trouble. Even just the garbled message itself could be proof against you, even if your adversary can’t read it. Enter The Guardian. The UK-based media outlet has deployed a rather creative and secure way of accepting private tips and information, one which seeks to provide heavy cover for those writing in with the hottest scoops.

Continue reading “Secure Communication, Buried In A News App” →

This Week In Security: Getting Back Up To Speed

March 6, 2026 by Mike Kershaw 11 Comments

Editor’s Note: Over the course of nearly 300 posts, Jonathan Bennett set a very high bar for this column, so we knew it needed to be placed in the hands of somebody who could do it justice. That’s why we’re pleased to announce that Mike Kershaw AKA [Dragorn] will be taking over This Week In Security! Mike is a security researcher with decades of experience, a frequent contributor to 2600, and perhaps best known as the creator of the Kismet wireless scanner.

He’ll be bringing the column to you regularly going forward, but given the extended period since we last checked in with the world of (in)security, we thought it would be appropriate to kick things off with a review of some of the stories you may have missed.

Hacking like it’s 2009, or 1996

Hello all! It’s a pleasure to be here, and it already seems like a theme of the new year so far has bringing in the old bugs – what’s old is new again, and 2026 has seen several fixes to some increasingly ancient bugs.

Telnet

Reported on the OpenWall list, the GNU inetd suite brings an update to the telnet server (yes, telnet) that closes a login bug present since 2015 linked to environment variable sanitization.

Under the covers, the telnet daemon uses /bin/login to perform user authentication, but also has the ability to pass environment variables from the client to the host. One of these variables, USER, is passed directly to login — unfortunately this time with no checking to see what it contains. By simply passing a USER variable of “-froot”, login would accept the “-f” argument, or “treat this user as already logged in”. Instant root!

If this sounds vaguely familiar, it might be because the exact same bug was found in the Solaris telnetd service in 2007, including using the “-f” argument in the USER variable. An extremely similar bug targeting other variables (LD_PRELOAD) was found in the FreeBSD telnetd service in 2009, and other historical similar bugs have afflicted AIX and other Unix systems in the past.

Of course, nobody in 2026 should be running a telnet service, especially not exposed to the Internet, but it’s always interesting to see the old style of bugs resurface.

Glibc

Also reported on the OpenWall list, glibc — the GNU LibC library which underpins most binaries on Linux systems, providing kernel interfaces, file and network I/O, string manipulation, and most other common functions programmers expect — has killed another historical bug, present since 1996 in the DNS resolver functions which could be used to expose some locations in the stack.

Although not exploitable directly, the getnetbyaddr resolution functions could still ease in breaking ASLR, making other exploits viable.

Address Space Layout Randomization (ASLR) is a common method of randomizing where in memory a process and its data are loaded, making trivial exploits like buffer overflows much harder to execute. Being able to expose the location of the binary in memory by leaking stack locations weakens this mechanism, possibly exposing a vulnerable program to more traditional attacks.

MSHTML

In February, Microsoft released fixes under CVE-2026-21513 for the MSHTML Trident renderer – the one used in Internet Explorer 5. Apparently still present in Windows, and somehow still accessible through specific shortcut links, it’s the IE5 and Active-X gift that keeps giving, being actively exploited.

Continue reading “This Week In Security: Getting Back Up To Speed” →