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

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

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

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

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

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”

Exploring Security Vulnerabilities In A Cheap WiFi Extender

If all you want is just a basic WiFi extender that gets some level of network connectivity to remote parts of your domicile, then it might be tempting to get some of those $5, 300 Mbit extenders off Temu as [Low Level] recently did for a security audit. Naturally, as he shows in the subsequent analysis of its firmware, you really don’t want to stick this thing into your LAN. In this context it is also worrying that the product page claims that over a 100,000 of these have been sold.

Starting the security audit is using $(reboot) as the WiFi password, just to see whether the firmware directly uses this value in a shell without sanitizing. Shockingly, this soft-bricks the device with an infinite reboot loop until a factory reset is performed by long-pressing the reset button. Amusingly, after this the welcome page changed to the ‘Breed web recovery console’ interface, in Chinese.

Here we also see that it uses a Qualcomm Atheros QCA953X SoC, which incidentally is OpenWRT compatible. On this new page you can perform a ‘firmware backup’, making it easy to dump and reverse-engineer the firmware in Ghidra. Based on this code it was easy to determine that full remote access to these devices was available due to a complete lack of sanitization, proving once again that a lack of input sanitization is still the #1 security risk.

In the video it’s explained that it was tried to find and contact a manufacturer about these security issues, but this proved to be basically impossible. This leaves probably thousands of these vulnerable devices scattered around on networks, but on the bright side they could be nice targets for OpenWRT and custom firmware development.

Continue reading “Exploring Security Vulnerabilities In A Cheap WiFi Extender”

Removing The BIOS Administrator Password On A ThinkPad Takes Timing

This would be a bad time to slip. (Credit: onionboots, YouTube)
This would be a bad time to slip. (Credit: onionboots, YouTube)

In the olden days, an administrator password on a BIOS was a mere annoyance, one quickly remedied by powering off the system and pulling its CMOS battery or moving a jumper around. These days, you’re more likely to find a separate EEPROM on the mainboard that preserves the password. This, too, is mostly just another annoyance, as [onionboots] knew. All it takes is shorting out this EEPROM at the right time to knock it offline, with the ‘right time’ turning out to be rather crucial.

While refurbishing this laptop for a customer, he thought it’d be easy: the guide he found said he just had to disassemble the laptop to gain access to this chip, then short out its reset pin at the right time to make it drop offline and keep it shorted. Important here is that you do not short it when you are still booting the system, or it won’t boot. This makes for some interesting prodding of tiny pins with a metal tool.

Continue reading “Removing The BIOS Administrator Password On A ThinkPad Takes Timing”