This Week In Security: Docker Auth, Windows Tools, And A Very Full Patch Tuesday

CVE-2026-34040 lets attackers bypass some Docker authentication plugins by allowing an empty request body. Present since 2024, this bug was caused by a previous fix to the auth workflow. In the 2024 bug, the authentication system could be tricked into passing a zero-length request to the authentication handler. In the modern vulnerability, the system can be tricked into removing a too-large authentication request and passing a zero-length request to the authentication handler.

In both cases, the authentication system may not properly handle the malformed request and allow creation of docker images with access to stored credentials and secrets.

Bugs like these are increasing in visibility because AI agents running in Docker, like OpenClaw, may be tricked via prompt injection into leveraging the vulnerability.

Windows CPU Tools Compromised

videocardz.com notes that the popular Windows monitoring software Cpu-Z and HWMonitor appear to have been compromised. Reports indicate that the download site was compromised, not the actual packages, but that it was redirecting update requests to packages including malware. While the site has been repaired, unfortunately it looks like there is no warning to users that the downloads were compromised for a period of time.

Anecdotally, there has been a rash of Discord account takeovers in the past week, where long-standing accounts in multiple servers have been compromised and turned into spambots. While there is no evidence these events are linked, clearly a new credential or authentication stealing malware is in play, which involves stealing credentials from Discord.

X.Org and XWayland Updated

The X.Org and XWayland servers saw security updates this week, fixing a handful of vulnerabilities involving uninitialized memory use, use-after-free, and reading beyond the end of a buffer.

The vulnerabilities are generally classified as “moderate”, but of course, don’t leave known vulnerabilities when you can avoid it! Fixed releases should find their way into distributions soon.

Continue reading “This Week In Security: Docker Auth, Windows Tools, And A Very Full Patch Tuesday”

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”

SUPERCON 2022: Kuba Tyszko Cracks Encrypted Software

[Kuba Tyszko] like many of us, has been hacking things from a young age. An early attempt at hacking around with grandpa’s tractor might have been swiftly quashed by his father, but likely this was not the last such incident. With a more recent interest in cracking encrypted applications, [Kuba] gives us some insights into some of the tools at your disposal for reading out the encrypted secrets of applications that have something worth hiding.  (Slides here, PDF.)

There may be all sorts of reasons for such applications to have an encrypted portion, and that’s not really the focus. One such application that [Kuba] describes was a pre-trained machine-learning model written in the R scripting language. If you’re not familiar with R, it is commonly used for ‘data science’ type tasks and has a big fan base. It’s worth checking out. Anyway, the application binary took two command line arguments, one was the encrypted blob of the model, and the second was the path to the test data set for model verification.

The first thing [Kuba] suggests is to disable network access, just in case the application wants to ‘dial home.’ We don’t want that. The application was intended for Linux, so the first port of call was to see what libraries it was linked against using the ldd command. This indicated that it was linked against OpenSSL, so that was a likely candidate for encryption support. Next up, running objdump gave some clues as to the various components of the binary. It was determined that it was doing something with 256-bit AES encryption. Now after applying a little experience (or educated guesswork, if you prefer), the likely scenario is that the binary yanks the private key from somewhere within itself reads the encrypted blob file, and passes this over to libssl. Then the plaintext R script is passed off to the R runtime, the model executes against the test data, and results are collated.

[Kuba]’s first attack method was to grab the OpenSSL source code and drop in some strategic printf() function calls into the target functions. Next, using the LD_PRELOAD ‘trick’ the standard system OpenSSL library was substituted with the ‘fake’ version with the trojan printfs. The result of this was the decryption function gleefully sending the plaintext R script direct to the terminal. No need to even locate the private key!

Continue reading “SUPERCON 2022: Kuba Tyszko Cracks Encrypted Software”

This Week In Security: OpenSSL Fizzle, Java XML, And Nothing As It Seems

The security world held our collective breaths early this week for the big OpenSSL vulnerability announcement. Turns out it’s two separate issues, both related to punycode handling, and they’ve been downgraded to high severity instead of critical. Punycode, by the way, is the system for using non-ASCII Unicode characters in domain names. The first vulnerability, CVE-2022-3602, is a buffer overflow that writes four arbitrary bytes to the stack. Notably, the vulnerable code is only run after a certificate’s chain is verified. A malicious certificate would need to be either properly signed by a Certificate Authority, or manually trusted without a valid signature.

A couple sources have worked out the details of this vulnerability. It’s an off-by-one error in a loop, where the buffer length is checked earlier in the loop than the length variable is incremented. Because of the logic slip, the loop can potentially run one too many times. That loop processes the Unicode characters, encoded at the end of the punycode string, and injects them in the proper place, sliding the rest of the string over a byte in memory as a result. If the total output length is 513 characters, that’s a single character overflow. A Unicode character takes up four bytes, so there’s your four-byte overflow. Continue reading “This Week In Security: OpenSSL Fizzle, Java XML, And Nothing As It Seems”

This Week In Security: IOS, OpenSSL, And SQLite

Earlier this week, a new release of iOS rolled out, fixing a handful of security issues. One in particular noted it “may have been actively exploited”, and was reported anonymously. This usually means that a vulnerability was discovered in the wild, being used as part of an active campaign. The anonymous credit is interesting, too. An educated guess says that this was a rather targeted attack, and the security company that found it doesn’t want to give away too much information.

Of other interest is the GPU-related fix, credited to [Asahi Lina], the VTuber doing work on porting Linux to the Apple M1/M2 platform, and particularly focusing on GPU drivers. She’s an interesting case, and doing some very impressive work. There does remain the unanswered question of how the Linux Kernel will deal with a pull request coming from a pseudonym. Regardless, get your iOS devices updated.

Continue reading “This Week In Security: IOS, OpenSSL, And SQLite”

This Week In Security: Zimbra RCE, Routers Under Attack, And Old Tricks In WebAssembly

There’s a problem in the unrar utility, and as a result, the Zimbra mail server was vulnerable to Remote Code Execution by simply sending an email. So first, unrar is a source-available command-line application made by RarLab, the same folks behind WinRAR. CVE-2022-30333 is the vulnerability there, and it’s a classic path traversal on archive extraction. One of the ways this attack is normally pulled off is by extracting a symlink to the intended destination, which then points to a location that should be restricted. unrar has code hardening against this attack, but is sabotaged by its cross-platform support. On a Unix machine, the archive is checked for any symbolic links containing the ../ pattern. After this check is completed, a function runs to convert any Windows paths to Unix notation. As such, the simply bypass is to include symlinks using ..\ traversal, which don’t get caught by the check, and then are converted to working directories.

That was bad enough, but Zimbra made it worse by automatically extracting .rar attachments on incoming emails, in order to run a virus and spam check. That extraction isn’t sandboxed, so an attacker’s files are written anywhere on the filesystem the zimbra user can write. It’s not hard to imagine how this turns into a full RCE very quickly. If you have an unrar binary based on RarLab code, check for version 6.1.7 or 6.12 of their binary release. While Zimbra was the application specifically called out, there are likely to be other cases where this could be used for exploitation.
Continue reading “This Week In Security: Zimbra RCE, Routers Under Attack, And Old Tricks In WebAssembly”

This Week In Security: IoT In The Hot Tub, App Double Fail, And FreeBSD BadBeacon

[Eaton Zveare] purchased a Jacuzzi hot tub, and splurged for the SmartTub add-on, which connects the whirlpool to the internet so you can control temperature, lights, etc from afar. He didn’t realize he was about to discover a nightmare of security problems. Because as we all know, in IoT, the S stands for security. In this case, the registration email came from smarttub.io, so it was natural to pull up that URL in a web browser to see what was there. The page presented a login prompt, so [Eaton] punched in the credentials he had just generated. “Unauthorized” Well that’s not surprising, but what was very odd was the flash of a dashboard that appeared just before the authorization complaint. Could that have been real data that was unintentionally sent? A screen recorder answered that question, revealing that there was indeed a table loaded up with valid-looking data.

Digging around in the page’s JavaScript comes up with the login flow. The page uses the Auth0 service to handle logins, and that service sends back an access token. The page sends that access token right back to the Auth0 service to get user privileges. If the logged in user isn’t an admin, the redirect happens. However, we already know that some real data gets loaded. It appears that the limitations to data is all implemented on the client side, and the backend only requires a valid access token for data requests. What would happen if the response from Auth0 were modified? There are a few approaches to accomplish this, but he opted to use Fiddler. Rewrite the response so the front-end believes you’re an admin, and you’re in.

This approach seems to gain admin access to all of the SmartTub admin controls, though [Eaton] didn’t try actually making changes to see if he had write access, too. This was enough to demonstrate the flaw, and making changes would be flirting with that dangerous line that separates research from computer crime. The real problem started when he tried to disclose the vulnerability. SmartTub didn’t have a security contact, but an email to their support email address did elicit a reply asking for details. And after details were supplied, complete radio silence. Exasperated, he finally turned to Auth0, asking them to intervene. Their solution was to pull the plug on one of the two URL endpoints. Finally, after six months of trying to inform Jacuzzi and SmartTub of their severe security issues, both admin portals were secured.

Continue reading “This Week In Security: IoT In The Hot Tub, App Double Fail, And FreeBSD BadBeacon”