A commercial Delrama prism-based anamorphic lens for large cameras. (Source: Mathieu Stern, YouTube)
Although to the average person a camera lens is just that bit of glass you stick on the front of the camera to make stuff appear in focus, there’s a whole wide world out there of lens designs and modifications with enough variety to make your head spin. Some of these designs make a big impact, while others fade away again, sometimes at the whims of film makers and photographers. Prism-based anamorphic lenses are an oddity that recently [Mathieu Stern] got his hands on. (Video, embedded below.)

During the 1950s and 1960s there was a bit of a competition between anamorphic formats, which use special lenses that ‘squeeze’ a larger image so that widescreen movies could be recorded on standard 35 mm film. By using the same lens for recording and playback, the result was a mostly distortion-free image. Here the Technirama format by Technicolor who teamed up with Dutch company De Oude Delft (‘Old Delft’) to produce the prism-based Delrama lenses that fit on existing lenses for cameras and projectors.
The last gasp of the Delrama anamorphic lenses. (Credit: Mathieu Stern, YouTube)a
Despite having a clearly superior, distortion-free image than the cylindrical lenses of the competition, Technirama got pushed out of the commercial market, leaving De Oude Delft to try and interest the consumer market for Delrama with 8 and 16 mm adapters. These latter are the ones that [Mathieu] got his hands on and tried out with a DSLR camera.

Troublesome with these Delrama adapters is that their silver mirrors tend to degrade over time, and they also turned out to be rather fragile, which are both things that made consumers sour on them. Another challenge was the fixed four meter focus that’s great when you’re using it with a projector, but terrible for up-close shots. All of these issues resulted in Delrama fading from the market by the 1970s until all that remains are these remnants of a format that once was used to film some of the biggest Hollywood movies.

youtube.com/embed/jOMCzMHFhto?…

hackaday.com/2026/03/07/the-tr…

We were talking about [Maya Posch]’s rant on smartphones, “The Curse of the Everything Device”. Maya’s main point is that because the smartphone, or computer, can do everything, it’s hard for a person to focus down and do one thing without getting distracted, checking their whatever feed, or getting an important push notification about the Oscars. She was suggesting tying your hands to the mast by using a device that can only accommodate the one function, like a dedicated writing tool or word processor.

[Kristina Panos] compared the all-singing, all-dancing black rectangle to an everything-device of old: the all-in-one stereo receiver with built-in tape player, record player, and not just FM, but also AM radio receiver. The point being, the hi-fi device also does a whole lot of things but isn’t similarly cursed. The tape player never interrupts your listening to the AM radio station. When the record is over, it doesn’t swap over to FM. Your agency is required.

Similarly, it’s probably not intrinsically problematic that the smartphone has a camera, a web browser, text messages, and heck even a telephone built in. It’s how they interact with each other and the user, each vying for user attention, and interrupting with popups and alarms. It’s maybe a simple matter of software! (Says the hardware guy.)

Where would a distraction-free, but fully featured, phone begin? With the operating system? It would be perverse to limit you to one app at a time, or to make switching between them more cumbersome. How about turning off notifications, and relying on changing context only when you think about it? Maybe that’s a middle ground. How do you cope with the endless distractions offered to you by your smartphone? By your main computer?

This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter. Want this type of article to hit your inbox every Friday morning? You should sign up!

hackaday.com/2026/03/07/choice…

Instant photography is a miracle of the analog age, chemical photographs that develop in your hands moments after the shutter has been pressed. You can buy instant cameras and film from Fuji and the successor company to Polaroid, the originator of the technology, but they’re expensive. Fortunately [BoxArt] is here for those seeking a cheaper alternative, with an instant camera featuring a Raspberry Pi and a printer (Lithuanian language, Google Translate link).

It’s a fairly straightforward arrangement, with the Pi Zero and camera driving a receipt printer. There’s a nicely engineered 3D printed case, and the guts of a power bank to provide the volts for the thing. There are a set of status lights on top, and that’s it. Press the button, get a not-very-good grayscale image on curly paper.

You can of course buy off-the-shelf grayscale printing cameras from your favorite import site for much less than the cost of this camera, but we think this would probably take better pictures. Meanwhile if the original instant photography interests you, we’ve got you covered.

hackaday.com/2026/03/07/instan…

Depending who you ask, 3D pens are silly toys or handy tools. Those who use them as tools find them handy to fill gaps in printed assemblies or to use them as a PLA or PETG-based hot glue gun for their prints. [half-baked-research] on YouTube is in the second category, but knows that welding is better than gluing — so he built himself a 3D pen designed for plastic welding.

You can weld with a regular 3D pen, and [half-baked] demonstrates that in the video. But thanks to the low-conductivity tips on commercial pens, it’s a slow, fiddly business. By using a normal 3D printer hot-end, with its conductive brass nozzle, [half-baked] is able to get a lot more heat where it’s needed. That means the plastic on either side of the weld melts for a good bond with the stuff coming out the nozzle. He’s also able to push plastic much faster with the modified extruder he’s squeezed into the hot-glue-gun looking contraption. Those two things together conspire to make the whole process go much faster than with a commercial 3D pen. He calls his build a 3D pen, but given the form factor it might be more accurate to call it a ‘plastic extrusion gun’.

Starting at around 13:38 in the video, he performs some strength tests, something we wish more YouTubers would do. He’s able to demonstrate a stronger bond with his welding pen than the normal 3D pen, and a much, much stronger join than the usual superglue. A traditional plastic weld with hot air is even stronger, but [half-baked] points out elsewhere in the video that on thin-walled prints (as opposed to the solid test articles) hot air welding can be a very dicey business. Pen-welding offers much greater control, so is an interesting technique to keep in mind.

Alas, [half-baked-research] apparently still considers this idea too half-baked to release the design. If you don’t have time to wait or reinvent this particular wheel, we featured a much simpler implementation of a similar idea years ago, using PLA in a hot glue gun. If that won’t work for you — maybe you aren’t a fan of PLA — perhaps you might try friction welding with filament.

youtube.com/embed/3gL9PFk9JtA?…

hackaday.com/2026/03/07/diy-3d…

Modern-day receivers are miracles of digital audio and video processing, but compared to their more analog brethren, they can come with a host of new and fascinating faults. The Onkyo TX-SA806 and SR806 receivers were released back in 2008, with [Tony359] recently getting the latter variant in for repair. Described as having weird digital distortion on the audio outputs, this particular issue got fixed by recapping the PCB with all the digital processing in the first video on this receiver, but this left the second issue unaddressed of a persistent hum, which is the topic of the second video on this repair.
Capacitor C5662 in the Onkyo TX-SR608 receiver with a slight bulge.
With the easy fix of recapping of the digital board already tried, next was a deep-dive into the receiver’s schematics to figure out where this low-frequency hum was coming from. With it sounding very much like mains frequency hum bleeding through, this was the starting point. Presumably somewhere on the power rails the normal filtering had broken down, so all rails had to be identified and checked for this interference.

With ripple on the 10V and 12V rails as well as the others seemingly in order, it wasn’t clear where the 100 Hz hum was coming from, but people on the BadCaps forum offered some help. After some back and forth it was deduced that the problem was the +15 VA rail, with heavy ripple on it due to a dead capacitor on the +22 V rail that comes straight from a transformer.

For some reason Onkyo’s engineer and/or bean counters had decided that installing an 85°C electrolytic capacitor on the opposite PCB side of a bridge rectifier was a genius idea, which turned out to be not quite the case. With the capacitor eventually giving up on life, the mains hum was allowed to freely pass onto the analog voltage rail and from there into the outputs.
22 V rail of the Onkyo TX-SR608 receiver.
Of course, getting to the target C5662 capacitor was anything but easy, as these modern receivers are tightly packed sandwiches of PCBs, requiring basically a full disassembly. Upon getting to C5662 it was clear that the capacitor was bad, being visibly bulged. Despite being a quality Japanese Nichicon capacitor, such an abusive environment was simply too much. With more similarly poorly spec’ed capacitors at risk of the same fate, these were all replaced with 105°C rated electrolytics.

Perhaps unsurprisingly this fixed the mains hum on the outputs, returning this receiver back to full functionality. In some ways it’s good to know that even with these modern receivers the most typical fault is still due to electrolytic capacitors.

youtube.com/embed/OPZ0AGjqEI8?…

hackaday.com/2026/03/07/fixing…

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…