Can you remotely unlock an encrypted hard disk? [Jyn] needed to unlock their home server after it rebooted even if they weren’t home. Normally, they used Tailscale to remote in, but you can’t use tailscale to connect to the machine before the hard drive decrypts, right? Well, you can, sort of, and [Jyn] explains how.

The entertaining post points out something you probably knew, but never thought much about. When your Linux box boots, it starts a very tiny compressed Linux in RAM. On [Jyn’s] machine using Arch, this is the initramfs.

That’s not news, but because it is an actual limited Linux system (including systemd), you can add tools to it. In this case, adding dropbear (an ssh server) and Tailscale to the limited boot-time Linux.

Doing this in the most straightforward way presents several issues related to security. However, using a few configuration items, you can limit it to showing the unlock screen and nothing else.

The only limitation is that the setup, as written, will only work with an Ethernet interface. WiFi should be possible, but getting the wireless network up in this environment would likely be challenging.

You could probably set this up with WireGuard or even an ssh tunnel if you were adventurous.

hackaday.com/2026/03/06/remote…

Usage of an automatic stoker. (Source: Claymills Pumping Station, YouTube)
Hacks are of all ages, with the Victorian-era Claymills Pumping Station being no exception. When its old Lancashire boilers from the 19th century were finally replaced with modern 1930s boilers, the 1920s-era automatic stokers were bodged onto the new boilers with a rather ill-fitting adapter plate, as there was no standard Lancashire boiler design. Nearly a hundred years later it was up to the volunteers at this Victorian-era pumping station to inspect and refurbish this solution, before fitting it back onto the boiler.

Lancashire boilers have two flue channels in which the coal is burned, which used to be done purely by hand. The automatic stokers are belt-driven devices that continuously add fresh fuel and massively lighten the workload. The 1920s stokers are still in place at this pumping station and a feature that they would love to retain.

Thus, after previously pressure-testing this #1 boiler to well beyond its operating pressure, the refurbished adapter plate was mounted back on with some percussive persuasion of the ‘very large beam’ variety.

Before the stokers could be mounted again, however, the boiler inspector had to give his OK to put the brickwork around the boiler back in place which helps to insulate it, among other functions. Once this is completed the boiler can finally see a fire again since it was last used in the 1970s. Whether these vintage stokers will work flawlessly will remain a surprise until then, but it’ll be a treat to see them operate.

youtube.com/embed/KKDtXg3Fr1w?…

hackaday.com/2026/03/06/how-an…

When thinking of humanity’s ability to harness wind energy, many people will conjure images of windmills from places like The Netherlands or Persia. But people have been using wind energy for far longer than that in the form of sailing ships. Using the wind for transportation goes back another four thousand years or so, but despite our vast experience navigating the seas with wind alone there is still some room for improvement. Many modern sailboats use a number of different pulleys to manage all of the rigging, but this new, open-source pulley can replace many of them.

The pulley, or “block” as they are sometimes called, is built with a polymer roller made out of a type of nylon, which has the benefit of being extremely durable and self-lubricating but is a bit expensive. Durability and lack of squeakiness is important in sailing applications, though. The body is made from CNC-machined aluminum and is composed of two parts, which pivot around the pulley’s axis to allow various ropes (or “lines”) to be inserted without freeing one end of the rope. In testing, this design outperformed some proprietary stainless steel pulleys of similar size.

Another perk of this design is that it can be set up to work in many different applications on a sailboat, whether that’s for hoisting a mainsail or pulling in a jib or any other task a pulley could be used for. It can also be stacked with others in many different configurations to build custom pulleys of almost any type, and can support up to 14 mm lines. For a sailor this could be extremely valuable, because as it stands each pulley on a ship tends to be used in only certain applications, and might also be proprietary from a specific company. This pulley is being released into the open-source world, allowing anyone to create them who wants one.

Thanks to [Keith] for the tip!

youtube.com/embed/2efa3epOGgY?…

hackaday.com/2026/03/06/one-sa…

Clocks come in many styles and sizes, with perhaps the most visually pleasing ones involving marbles. Watching these little spheres obey gravity and form clearly readable numbers on a clock has strong mesmerizing qualities. If you’re not into really big marble clocks, or cannot quite find the space for a desk-sized clock, then the tiny marble clock by [Jens] may be an option.

While he totally loved the massive marble clock that [Ivan Miranda] built, it is a massive contraption that’s hard to justify as a permanent installation. His take on the concept thus makes it as small as possible, by using a pick-and-place style arm to place the marbles instead. Although the marbles don’t do a lot of rolling this way, it’s decidedly more quiet, and replace the rumbling and click-clacking of marbles with the smooth motion of a robotic arm.

Another benefit of this clock is that it’s cheap to make, with a price tag of less than $23. A big part of this is the use of cheap SG90 micro servos, and a permanent magnet along with a mechanism that pushes the marble off said magnet. Perhaps the biggest issue with this clock is that the arm somewhat obscures the time while it’s moving around, but it’s definitely another interesting addition to the gallery of marble clocks.

We have previously seen such clocks built out of wood and brass as well as 3D-printed using pendulum mechanisms, which can be made pretty compact as well, albeit with a more analog vibe.

Thanks to [Hari] for the tip.

youtube.com/embed/aYX8qytpilQ?…

hackaday.com/2026/03/06/the-wo…

Out of all of Batman’s massive array of tools which turn a relatively ordinary person into a superhero, perhaps his most utilitarian is his grappling gun — allowing him the ability to soar around his city like Spiderman or Superman. [John Boss] isn’t typically fighting crime, but he did develop his own grappling gun of sorts which gives him another superpower: the ability to easily scale snowy hills to quickly get back to the top.

The grappling gun takes inspiration from a commonly used tool called a power ascender, which is often used in industry applications where climbing is required. This one is held in the hand and uses a brushless motor with a belt-driven 3:1 reduction for increased torque. The pulley system, bearings, and motor are all housed in a 3D printed enclosure and are powered by rechargeable Milwaukee power tool batteries. During prototyping the rope intake and output feed locations had to be moved to increase the pulley’s grabbing ability, and with a working prototype he swapped a lot of the plastic 3D printed parts out for metal to increase the sturdiness of the device.

The grappling gun was originally designed for a smaller child to get hoisted up a hill on a sled, but when stress testing the device [John] found out that it actually has more than enough capability to haul even an adult up a hill on skis. As an added bonus, the outfeed for the rope can be put into a bag and used to automatically coil the rope up when he’s done at the hill. Although this is a great solution for a portable rope tow, for something more permanent and more powerful take a look at this backyard rope tow that was built from spare parts.

youtube.com/embed/osh5q5kJruU?…

hackaday.com/2026/03/06/portab…

An early print of the linoleum block that Kristina started carving during the podcast. (It’s the original Cherry MX patent drawing, re-imagined for block printing.)
This week, Hackaday’s Elliot Williams and Kristina Panos met up over assorted beverages to bring you the latest news, mystery sound results show, and of course, a big bunch of hacks from the previous seven days or so.

In the news, we’ve launched a brand-new contest! Yes, the Green-Powered Challenge is underway, and we need your entry to truly make it a contest. You have until April 24th to enter, so show us what you can do with power you scrounge up from the environment around you!

On What’s That Sound, Kristina was leaning toward some kind of distant typing sounds, but [Konrad] knew it was our own Tom Nardi’s steam heat radiator pinging away.

After that, it’s on to the hacks and such, beginning with an exploration of all the gross security vulnerabilities in a cheap WiFi extender, and we take a look inside a little black and white pay television like you’d find in a Greyhound station in the 80s and 90s.

We also discuss the idea of mixing custom spray paint colors on the fly, a pen clip that never bends out of shape, and running video through a guitar effects pedal. Finally, we discuss climate engineering with disintegrating satellites, and the curse of everything device.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

html5-player.libsyn.com/embed/…

Download in DRM-free MP3 and savor at your leisure.

Where to Follow Hackaday Podcast

Places to follow Hackaday podcasts:

• iTunes
• Spotify
• Stitcher
• RSS
• YouTube
• Check out our Libsyn landing page

Episode 360 Show Notes:

News:

• Get Your Green Power On!

What’s that Sound?

• Congrats to [Konrad] who knew this was Tom Nardi’s radiator!

Interesting Hacks of the Week:

• Exploring Security Vulnerabilities In A Cheap WiFi Extender
• Vend-o-Vision: Trading Quarters For Watching TV In Public
• Using A Solid-State Elastocaloric Cooler To Freeze Water
  
  • A Refrigerator Cooled By Rubber Bands

  
  

• Color Mixing Spray Paint On The Fly
• NASA Uses Mars Global Localization As GNSS Replacement For The Perseverance Rover
  
  • Censible: A Robust and Practical Global Localization Framework for Planetary Surface Missions

  
  

• Designing A Pen Clip That Never Bends Out Of Shape

Quick Hacks:

• Elliot’s Picks:
  
  • Running Video Through A Guitar Effects Pedal
  • Neither Android Nor IOS: DIY Smartphone Runs On ESP32!
  • SNES Controllers Are (Almost) SPI-Compatible
  • Making A 286 Think It’s Alive Again

  
  

• Kristina’s Picks:
  
  • Why Peeling Adhesive Tape Is So Unreasonably Noisy
  • Computer Terminal Replica Inspired By 70s Hardware
  • Fish Drives Tank

  
  

Can’t-Miss Articles:

• Accidental Climate Engineering With Disintegrating Satellites
• The Curse Of The Everything Device

hackaday.com/2026/03/06/hackad…

The SGI O2 was SGI’s last-ditch attempt at a low-end MIPS-based workstation back in 1996, and correspondingly didn’t use the hottest parts of the time, nor did it offer much of an upgrade path. None of which is a concern to hobbyists who are more than happy to work around any hardware- and software limitations to e.g. install much faster CPUs. While quite a few CPU upgrades were possible with just some BGA chip reworking skills, installing the 900 MHz RM7900 would require some PROM hacking, which [mattst88] recently took a shake at.

The initial work on upgrading SGI O2 systems was done in the early 2000s, with [Joe Page] and [Ian Mapleson] running into the issue that these higher frequency MIPS CPUs required a custom IP32 PROM image, for which they figured that they’d need either SGI’s help or do some tricky reverse-engineering. Since SGI is no longer around, [mattst88] decided to take up the torch.

After downloading a 512 kB binary dump of the last version of the O2’s PROM, he set to work reverse-engineering it, starting by dissembling the file. A big part of understanding MIPS PROM code is understanding how the MIPS architecture works, including its boot process, so much of what followed was a crash-course on the subject.

With that knowledge it was much easier to properly direct the Capstone disassembler and begin the arduous process of making sense of the blob of data and code. The resulting source files now reassemble into bit-identical ROM files, which makes it likely that modifying it to support different CPUs is now possible with just a bit more work.

For those who want to play along, [mattst88] has made his ip32prom-decompiler project available on GitHub.

Thanks to [adistuder] for the tip.

Top image: Silicon Graphics 1600SW LCD display and O2 workstation. (Source: Wikimedia)

hackaday.com/2026/03/06/revers…

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.

Back in the modern era…

After that bit of computing nostalgia, let’s look at some interesting stories involving slightly more contemporary subjects.

Server-side JS

It’s easy to think of JavaScript as simply a client-side language, but of course it’s also used in server frameworks like node.js and React, the latter being used heavily in the popular Next.JS framework server components.

Frameworks like React blur the lines between client and server, using the same coding style and framework conventions in the browser and in the server-side engine. React and NextJS allow calling server-side functions from the client side, mixing client and server side rendering of content, but due to a deserialization bug, React allowed any function to be called from a non-privileged client.

Cleverly named React2Shell, it has rapidly become a target for bulk exploitation, with Internet-scale monitoring firm GreyNoise reporting 8 million logged attempts by early January 2026. At this point, it’s safe to assume any Internet-exposed vulnerable service has been compromised.

Too much AI

As previously covered by Hackaday, the Curl project is officially ending bug bounties due to the flood of bogus submissions from AI tools. The founder and project lead, Daniel Sternberg, has been critical of AI-generated bug bounties in the past, and has finally decided the cost is no longer worth the gains.

In many ways this calls to mind the recent conflict between the ffmpeg team and Google, where Google Project Zero discovered a flaw in the decoding of a relatively obscure codec, assigning it a 90-day disclosure deadline and raising the ire of the open source volunteer team.

The influx of AI-generated reports is the latest facet of the friction between volunteer-led open source projects, and paid bug bounties or other commercial interests. Even with sponsorship backing, the reach of popular open-source libraries and tools like Curl, OpenSSL, BusyBox, and more is often far, far greater than the compensation offered by the biggest users of those libraries — often trillion dollar multinational companies.

Many open source projects are the passion project of a small set of people, even if they become massively popular and critical to commercial tools and infrastructure. While AI tooling may generate actionable reports, when it is deployed by users who may not themselves be programmers and are unable to verify the results, it puts the time drain of determining the validity, and at times, arguing with the submitter, entirely on the project maintainers. As the asymmetry increases, more small open source teams may start rejecting clearly AI generated reports as well.

OpenSSL, Again

The OpenSSL library, another critical component of Internet infrastructure with a very small team, suffers from a vulnerability in PKCS12 parsing which appears to be a relatively traditional memory bug leaning to null pointers, stack corruption, or buffer overflows, which in the best case causes a crash and the worst case allows for arbitrary code execution. (Insert obligatory XKCD reference here.)

PKCS12 is a certificate storage format which bundles multiple certificates and private keys in a single file – similar to a zip or tar for certificate credentials. Fortunately PKCS12 files are typically already trusted, and methods to upload them are not often exposed to the Internet at large, unfortunately, potential code execution even when limited to a trusted network interface is rarely a positive thing.

Notepad++

The Notepad++ team has released a write-up about the infrastructure compromise which appears to have enabled a state-level actor to deliver infected updates to select customers.

Notepad++ is a fairly popular alternative to the classic Notepad app found on Windows, with support for syntax highlighting, multiple programming languages, and basic IDE functionality. According to the write-up by the team based on findings by independent researchers, in June 2025 the shared hosting service which served updates to Notepad++ was compromised, and remained so until September of 2025.

The root of the issue lies in the update library WinGUp, used by Notepad++, which did not validate the downloaded update, leaving it vulnerable to redirection and modification. With control of the update servers, the attackers were able to send specific customers to modified, trojaned updates.

An important take-away for all developers: if your project can self-update, make sure that the update process is secure against malicious actors. Which can mean the complex issues of not only validating the certificate chain, but sometimes embedding trusted certificates in your software (or firmware) and using them to validate that the update file itself has not been modified.

WiFi Isolation

Finally, we have a new paper on WiFi security, with a new attack dubbed “AirSnitch”. From a team of collaborators including Mathy Vanhoef (a frequent publisher of modern WiFi attacks including the WPA2 KRACK attacks, and a driving force behind deprecating WPA2), AirSnitch defeats a protection in wireless networks known as “client isolation”.

Client isolation acts essentially as a firewall mechanism, which attempts to offer wireless clients an additional layer of security by preventing communication between clients on the same network. Optimally, this would prevent a hostile or infected client from communicating with other clients, despite being on the same shared network.

On a WPA encrypted WiFi network, each client has an individual key used for encryption, and a shared group key used by all clients for broadcast and multicast communication. For one client to communicate with another, the access point must decrypt the traffic from the first and re-encrypt it to the second. Preventing communication between clients should be as simple as not performing the encryption between clients, however by cloning the MAC address of the target client and establishing a second connection to the access point, and further manipulating the internal state of the access point with injected packets, a hostile device can cause the access point to share the data of the target, essentially converting the behavior of the network to a legacy Ethernet hub.

How significantly this might impact you will vary wildly, and likely the full impacts of the attack will take some time to be understood. An attacker still needs access to the network – for a WPA network this means the PSK must be known, and for an Enterprise network, login credentials are still required. Typically home networks don’t use client isolation at all – most home users expect devices to be able to communicate directly, and most public access networks use no encryption at all, leaving clients exposed to the same level of risk by default. Networks with untrusted clients, like educational campus networks or business bring-your-own-device networks, are likely at the greatest risk, but time will tell.

hackaday.com/2026/03/06/this-w…

There was a time when Linux was much simpler. You’d load a driver, it would find your device at boot up, or it wouldn’t. That was it. Now, though, people plug and unplug USB devices all the time and expect the system to react appropriately. [Arcanenibble] explains all “the gory details” about what really happens when you plug or unplug a device.

You might think, “Oh, libusb handles that.” But, of course, it doesn’t do the actual work. In fact, there are two possible backends: netlink or udev. However, the libusb developers strongly recommend udev. Turns out, udev also depends on netlink underneath, so if you use udev, you are sort of using netlink anyway.

If netlink sounds familiar, it is a generic BSD-socket-like API the kernel can use to send notifications to userspace. The post shows example code for listening to kernel event messages via netlink, just like udev does.

When udev sees a device add message from netlink, it resends a related udev message using… netlink! Turns out, netlink can send messages between two userspace programs, not just between the kernel and userspace. That means that the code to read udev events isn’t much different from the netlink example.

The next hoop is the udev event format. It uses a version number, but it seems stable at version 0xfeedcafe. Part of the structure contains a hash code that allows a bloom filter to quickly weed out uninteresting events, at least most of the time.

The post documents much of the obscure inner workings of USB hotplug events. However, there are some security nuances that aren’t clear. If you can explain them, we bet [Arcanenibble] would like to hear from you.

If you like digging into the Linux kernel and its friends, you might want to try creating kernel modules. If you get overwhelmed trying to read the kernel source, maybe go back a few versions.

hackaday.com/2026/03/06/linux-…

The fourth quarter of 2025 went down as one of the most intense periods on record for high-profile, critical vulnerability disclosures, hitting popular libraries and mainstream applications. Several of these vulnerabilities were picked up by attackers and exploited in the wild almost immediately.

In this report, we dive into the statistics on published vulnerabilities and exploits, as well as the known vulnerabilities leveraged with popular C2 frameworks throughout Q4 2025.

Statistics on registered vulnerabilities

This section contains statistics on registered vulnerabilities. The data is taken from cve.org.

Let’s take a look at the number of registered CVEs for each month over the last five years, up to and including the end of 2025. As predicted in our last report, Q4 saw a higher number of registered vulnerabilities than the same period in 2024, and the year-end totals also cleared the bar set the previous year.

Total published vulnerabilities by month from 2021 through 2025 (download)

Now, let’s look at the number of new critical vulnerabilities (CVSS > 8.9) for that same period.

Total number of published critical vulnerabilities by month from 2021 to 2025< (download)

The graph shows that the volume of critical vulnerabilities remains quite substantial; however, in the second half of the year, we saw those numbers dip back down to levels seen in 2023. This was due to vulnerability churn: a handful of published security issues were revoked. The widespread adoption of secure development practices and the move toward safer languages also pushed those numbers down, though even that couldn’t stop the overall flood of vulnerabilities.

Exploitation statistics

This section contains statistics on the use of exploits in Q4 2025. The data is based on open sources and our telemetry.

Windows and Linux vulnerability exploitation

In Q4 2025, the most prevalent exploits targeted the exact same vulnerabilities that dominated the threat landscape throughout the rest of the year. These were exploits targeting Microsoft Office products with unpatched security flaws.

Kaspersky solutions detected the most exploits on the Windows platform for the following vulnerabilities:

• CVE-2018-0802: a remote code execution vulnerability in Equation Editor.
• CVE-2017-11882: another remote code execution vulnerability, also affecting Equation Editor.
• CVE-2017-0199: a vulnerability in Microsoft Office and WordPad that allows an attacker to assume control of the system.

The list has remained unchanged for years.

We also see that attackers continue to adapt exploits for directory traversal vulnerabilities (CWE-35) when unpacking archives in WinRAR. They are being heavily leveraged to gain initial access via malicious archives on the Windows operating system:

• CVE-2023-38831: a vulnerability stemming from the improper handling of objects within an archive.
• CVE-2025-6218 (formerly ZDI-CAN-27198): a vulnerability that enables an attacker to specify a relative path and extract files into an arbitrary directory. This can lead to arbitrary code execution. We covered this vulnerability in detail in our Q2 2025 report.
• CVE-2025-8088: a vulnerability we analyzed in our previous report, analogous to CVE-2025-6218. The attackers used NTFS streams to circumvent controls on the directory into which files were being unpacked.

As in the previous quarter, we see a rise in the use of archiver exploits, with fresh vulnerabilities increasingly appearing in attacks.

Below are the exploit detection trends for Windows users over the last two years.

Dynamics of the number of Windows users encountering exploits, Q1 2024 – Q4 2025. The number of users who encountered exploits in Q1 2024 is taken as 100% (download)

The vulnerabilities listed here can be used to gain initial access to a vulnerable system. This highlights the critical importance of timely security updates for all affected software.

On Linux-based devices, the most frequently detected exploits targeted the following vulnerabilities:

• CVE-2022-0847, also known as Dirty Pipe: a vulnerability that allows privilege escalation and enables attackers to take control of running applications.
• CVE-2019-13272: a vulnerability caused by improper handling of privilege inheritance, which can be exploited to achieve privilege escalation.
• CVE-2021-22555: a heap overflow vulnerability in the Netfilter kernel subsystem.
• CVE-2023-32233: another vulnerability in the Netfilter subsystem that creates a use-after-free condition, allowing for privilege escalation due to the improper handling of network requests.

Dynamics of the number of Linux users encountering exploits, Q1 2024 – Q4 2025. The number of users who encountered exploits in Q1 2024 is taken as 100% (download)

We are seeing a massive surge in Linux-based exploit attempts: in Q4, the number of affected users doubled compared to Q3. Our statistics show that the final quarter of the year accounted for more than half of all Linux exploit attacks recorded for the entire year. This surge is primarily driven by the rapidly growing number of Linux-based consumer devices. This trend naturally attracts the attention of threat actors, making the installation of security patches critically important.

Most common published exploits

The distribution of published exploits by software type in Q4 2025 largely mirrors the patterns observed in the previous quarter. The majority of exploits we investigate through our monitoring of public research, news, and PoCs continue to target vulnerabilities within operating systems.

Distribution of published exploits by platform, Q1 2025 (download)

Distribution of published exploits by platform, Q2 2025 (download)

Distribution of published exploits by platform, Q3 2025 (download)

Distribution of published exploits by platform, Q4 2025 (download)

In Q4 2025, no public exploits for Microsoft Office products emerged; the bulk of the vulnerabilities were issues discovered in system components. When calculating our statistics, we placed these in the OS category.

Vulnerability exploitation in APT attacks

We analyzed which vulnerabilities were utilized in APT attacks during Q4 2025. The following rankings draw on our telemetry, research, and open-source data.

TOP 10 vulnerabilities exploited in APT attacks, Q4 2025 (download)

In Q4 2025, APT attacks most frequently exploited fresh vulnerabilities published within the last six months. We believe that these CVEs will remain favorites among attackers for a long time, as fixing them may require significant structural changes to the vulnerable applications or the user’s system. Often, replacing or updating the affected components requires a significant amount of resources. Consequently, the probability of an attack through such vulnerabilities may persist. Some of these new vulnerabilities are likely to become frequent tools for lateral movement within user infrastructure, as the corresponding security flaws have been discovered in network services that are accessible without authentication. This heavy exploitation of very recently registered vulnerabilities highlights the ability of threat actors to rapidly implement new techniques and adapt old ones for their attacks. Therefore, we strongly recommend applying the security patches provided by vendors.

C2 frameworks

In this section, we will look at the most popular C2 frameworks used by threat actors and analyze the vulnerabilities whose exploits interacted with C2 agents in APT attacks.

The chart below shows the frequency of known C2 framework usage in attacks against users during Q4 2025, according to open sources.

TOP 10 C2 frameworks used by APTs to compromise user systems in Q4 2025 (download)

Despite the significant footprints it can leave when used in its default configuration, Sliver continues to hold the top spot among the most common C2 frameworks in our Q4 2025 analysis. Mythic and Havoc were second and third, respectively. After reviewing open sources and analyzing malicious C2 agent samples that contained exploits, we found that the following vulnerabilities were used in APT attacks involving the C2 frameworks mentioned above:

• CVE-2025-55182: a React2Shell vulnerability in React Server Components that allows an unauthenticated user to send commands directly to the server and execute them from RAM.
• CVE-2023-36884: a vulnerability in the Windows Search component that allows the execution of commands on a system, bypassing security mechanisms built into Microsoft Office applications.
• CVE-2025-53770: a critical insecure deserialization vulnerability in Microsoft SharePoint that allows an unauthenticated user to execute commands on the server.
• CVE-2020-1472, also known as Zerologon, allows for compromising a vulnerable domain controller and executing commands as a privileged user.
• CVE-2021-34527, also known as PrintNightmare, exploits flaws in the Windows print spooler subsystem, enabling remote access to a vulnerable OS and high-privilege command execution.
• CVE-2025-8088 and CVE-2025-6218 are similar directory-traversal vulnerabilities that allow extracting files from an archive to a predefined path without the archiving utility notifying the user.

The set of vulnerabilities described above suggests that attackers have been using them for initial access and early-stage maneuvers in vulnerable systems to create a springboard for deploying a C2 agent. The list of vulnerabilities includes both zero-days and well-known, established security issues.

Notable vulnerabilities

This section highlights the most noteworthy vulnerabilities that were publicly disclosed in Q4 2025 and have a publicly available description.

React2Shell (CVE-2025-55182): a vulnerability in React Server Components

We typically describe vulnerabilities affecting a specific application. CVE-2025-55182 stood out as an exception, as it was discovered in React, a library primarily used for building web applications. This means that exploiting the vulnerability could potentially disrupt a vast number of applications that rely on the library. The vulnerability itself lies in the interaction mechanism between the client and server components, which is built on sending serialized objects. If an attacker sends serialized data containing malicious functionality, they can execute JavaScript commands directly on the server, bypassing all client-side request validation. Technical details about this vulnerability and an example of how Kaspersky solutions detect it can be found in our article.

CVE-2025-54100: command injection during the execution of curl (Invoke-WebRequest)

This vulnerability represents a data-handling flaw that occurs when retrieving information from a remote server: when executing the curl or Invoke-WebRequest command, Windows launches Internet Explorer in the background. This can lead to a cross-site scripting (XSS) attack.

CVE-2025-11001: a vulnerability in 7-Zip

This vulnerability reinforces the trend of exploiting security flaws found in file archivers. The core of CVE-2025-11001 lies in the incorrect handling of symbolic links. An attacker can craft an archive so that when it is extracted into an arbitrary directory, its contents end up in the location pointed to by a symbolic link. The likelihood of exploiting this vulnerability is significantly reduced because utilizing such functionality requires the user opening the archive to possess system administrator privileges.

This vulnerability was associated with a wave of misleading news reports claiming it was being used in real-world attacks against end users. This misconception stemmed from an error in the security bulletin.

RediShell (CVE-2025-49844): a vulnerability in Redis

The year 2025 saw a surge in high-profile vulnerabilities, several of which were significant enough to earn a unique nickname. This was the case with CVE-2025-49844, also known as RediShell, which was unveiled during a hacking competition. This vulnerability is a use-after-free issue related to how the load command functions within Lua interpreter scripts. To execute the attack, an attacker needs to prepare a malicious script and load it into the interpreter.

As with any named vulnerability, RediShell was immediately weaponized by threat actors and spammers, albeit in a somewhat unconventional manner. Because technical details were initially scarce following its disclosure, the internet was flooded with fake PoC exploits and scanners claiming to test for the vulnerability. In the best-case scenario, these tools were non-functional; in the worst, they infected the system. Notably, these fraudulent projects were frequently generated using LLMs. They followed a standardized template and often cross-referenced source code from other identical fake repositories.

CVE-2025-24990: a vulnerability in the ltmdm64.sys driver

Driver vulnerabilities are often discovered in legitimate third-party applications that have been part of the official OS distribution for a long time. Thus, CVE-2025-24990 has existed within code shipped by Microsoft throughout nearly the entire history of Windows. The vulnerable driver has been shipped since at least Windows 7 as a third-party driver for Agere Modem. According to Microsoft, this driver is no longer supported and, following the discovery of the flaw, was removed from the OS distribution entirely.

The vulnerability itself is straightforward: insecure handling of IOCTL codes leading to a null pointer dereference. Successful exploitation can lead to arbitrary command execution or a system crash resulting in a blue screen of death (BSOD) on modern systems.

CVE-2025-59287: a vulnerability in Windows Server Update Services (WSUS)

CVE-2025-59287 represents a textbook case of insecure deserialization. Exploitation is possible without any form of authentication; due to its ease of use, this vulnerability rapidly gained traction among threat actors. Technical details and detection methodologies for our product suite have been covered in our previous advisories.

Conclusion and advice

In Q4 2025, the rate of vulnerability registration has shown no signs of slowing down. Consequently, consistent monitoring and the timely application of security patches have become more critical than ever. To ensure resilient defense, it is vital to regularly assess and remediate known vulnerabilities while implementing technology designed to mitigate the impact of potential exploits.

Continuous monitoring of infrastructure, including the network perimeter, allows for the timely identification of threats and prevents them from escalating. Effective security also demands tracking the current threat landscape and applying preventative measures to minimize risks associated with system flaws. Kaspersky Next serves as a reliable partner in this process, providing real-time identification and detailed mapping of vulnerabilities within the environment.

Securing the workplace remains a top priority. Protecting corporate devices requires the adoption of solutions capable of blocking malware and preventing it from spreading. Beyond basic measures, organizations should implement adaptive systems that allow for the rapid deployment of security updates and the automation of patch management workflows.

securelist.com/vulnerabilities…

Light aircraft often use a heading indicator as a way to know where they’re going. Retired instrumentation engineer [Don Welch] recreated a heading indicator of his own, using cheap off-the-shelf hardware to get the job done.

The heart of the build is a Teensy 4.0 microcontroller. It’s paired with a BNO085 inertial measurement unit (IMU), which combines a 3-axis gyro, 3-axis accelerometer, and 3-axis magnetometer into a single package. [Don] wanted to build a heading indicator that was immune to magnetic disturbances, so ignored the magnetometer readings entirely, using the rest of the IMU data instead.

Upon startup, the Teensy 4.0 initializes a small round TFT display, and draws the usual compass rose with North at the top of the display. Any motion after this will update the heading display accordingly, with [Don] noting the IMU has a fast update rate of 200 Hz for excellent motion tracking. The device does not self-calibrate to magnetic North; instead, an encoder can be used to calibrate the device to match a magnetic compass you have on hand. Or, you can just ensure it’s already facing North when you turn it on.

Thanks to the power of the Teensy 4.0 and the rapid updates of the BNO085, the display updates are nicely smooth and responsive. However, [Don] notes that it’s probably not quite an aircraft-spec build. We’ve featured some interesting investigations of just how much you can expect out of MEMS-based sensors like these before, too.

youtube.com/embed/UoS7PKGJVlE?…

hackaday.com/2026/03/06/buildi…

Electric vehicles are everywhere these days, and with them comes along a whole slew of charging infrastructure. The fastest of these are high-power machines that can deliver enough energy to charge a car in well under an hour, but there are plenty of slower chargers available that take much longer. These don’t tend to require any specialized equipment which makes them easier to install in homes and other places where there isn’t as much power available. In fact, these chargers generally amount to fancy extension cords, and [Matt Gray] realized he could use these to do other things like charge his electric bicycle.

To begin the build, [Matt] started with an electric car charging socket and designed a housing for it with CAD software. The housing also holds the actual battery charger for his VanMoof bicycle, connected internally directly to the car charging socket. These lower powered chargers don’t require any communication from the vehicle either, which simplifies the process considerably. They do still need to be turned on via a smartphone app so the energy can be metered and billed, but with all that out of the way [Matt] was able to take his test rig out to a lamppost charger and boil a kettle of water.

After the kettle experiment, he worked on miniaturizing his project so it fits more conveniently inside the 3D-printed enclosure on the rear rack of his bicycle. The only real inconvenience of this project, though, is that since these chargers are meant for passenger vehicles they’re a bit bulky for smaller vehicles like e-bikes. But this will greatly expand [Matt]’s ability to use his ebike for longer trips, and car charging infrastructure like this has started being used in all kinds of other novel ways as well.

youtube.com/embed/i6IyukCIia8?…

hackaday.com/2026/03/05/ebike-…

Last year California’s Digital Age Assurance Act (AB 1043) was signed into law, requiring among other things that operating system providers implement an API for age verification purposes. With the implementation date of January 1, 2027 slowly encroaching this now has people understandably agitated. So what are the requirements, and what will its impact be, as it affects not only OS developers but also application stores and developers?

The required features for OS developers include an interface at account setup during which the person indicates which of the four age brackets they fit into. This age category then has to be used by application developers and application stores to filter access to the software. Penalties for non-compliance go up to $2,500 per affected child if the cause is neglect and up to $7,500 if the violation was intentional.

As noted in the Tom’s Hardware article, CA governor Newsom issued a statement when signing the unanimously passed bill, saying that he hopes the bill gets amended due to how problematic it would be to implement and unintended effects. Of course, the bigger question is whether this change requires more than adding a few input fields and checkboxes to an OS’ account setup and an API call or two.

When we look at the full text of this very short bill, the major questions are whether this bill has any teeth at all. From reading the bill’s text, we can see that the person creating the account is merely asked to provide their birth date, age or both. This makes it at first glance as effective as those ‘pick your age’ selection boxes before entering an age-gated part of a website. What would make this new ‘age-verification feature’ any more reliable than that?

Although the OS developer is required to provide this input option and an API feature of undefined nature that provides the age bracket in some format via some method, the onus is seemingly never put on the user who creates or uses the OS account. Enforcement as defined in section 1798.503 is defined as a vague ‘[a] person that violates this title’, who shall have a civil action lawsuit filed against them. What happens if a 9-year old child indicates that they’re actually 35, for example? Or when a user account is shared on a family computer?

All taken together, this bill looks from all angles to add a lot of nuisance and potential for catching civil lawsuit flak for in particular FOSS developers, all in order to circuitously reimplement the much beloved age dropdown selection widget that’s been around since at least the 1990s.

They could give this bill real teeth by requiring that photo ID is required for registering an (online-only) OS account, much like with the recent social media restrictions and Discord age-verification kerfuffle, but that’d run right over the ‘privacy-preserving’ elements in this same bill.

hackaday.com/2026/03/05/califo…

In theory HDMI’s CEC feature is great, as it gives HDMI devices the ability to do useful things such as turning on multiple HDMI devices with a single remote control. Of course, such a feature will inevitably feature bugs. A case in point is the Nvidia Shield which has often been reported to turn on other HDMI devices that should stay off. After getting ticked off by such issues one time too many, [Matt] decided to implement a network firewall project to prevent his receiver from getting messed with by the Shield.

The project is a Python-based network service that listens for the responsible rogue HDMI-CEC Zone 2 requests and talks with a Denon/Marantz receiver to prevent it from turning on unnecessarily. Of course, when you want these Zone 2 requests to do their thing you need to disable the script.

That said, HDMI-CEC is such a PITA that people keep running into issues like these over and over again, to the point where people are simply disabling the feature altogether. That said, Nvidia did recently release a Shield update that’s claimed to fix CEC issues, so maybe this is one CEC bug down already.

hackaday.com/2026/03/05/preven…