We have probably all at some point had to replace a peripheral not because it is faulty, but because it is no longer supported by our operating system. It’s especially bad for Windows users, but for older hardware this is increasingly a part of the Linux experience too. [George MacKerron] is here with what may prove to be a valuable technique to keep these devices active. He’s running a minimalist x86 computer in the browser, with just enough OS to support the device.

In this case the hardware is a USB scanner, and the resulting software takes a WebAssembly x86 emulator and adds a bit of glue software allowing it to use WebUSB to talk to the real-world hardware. It runs a minimal Alpine Linux environment with SANE — something that’s normal for Linux users but which has never been there on a Windows machine. The result is something which needs no installation, but can be run on any machine with a powerful enough web browser.

While such an approach might at first seem like overkill, we’re told it runs surprisingly quickly. In this case it’s for scanner, but we can see it could find a use with many other pieces of aged hardware.

If WebAssembly is new to you, we gave it a primer a few years ago.

Header image: Fir0002/Flagstaffotos, GFDL 1.2.

hackaday.com/2026/05/20/bring-…

Introduction

ExifTool is a widely adopted utility for reading and writing metadata in image, PDF, audio, and video files. It is available both as a standalone command-line application and as a library that can be embedded in other software. In this article, we break down CVE-2026-3102, an ExifTool vulnerability discovered by Kaspersky’s Global Research and Analysis Team (GReAT) in February 2026 and patched by the developers within the same month. Affecting macOS systems with ExifTool version 13.49 and earlier, this flaw could let an attacker run arbitrary commands by hiding instructions inside an image file’s metadata.

This investigation originated from revisiting an n-day vulnerability I first examined years ago: CVE-2021-22204. That flaw exploited weak regex-based sanitization before feeding user input into an eval sink. By auditing adjacent input validation routines across ExifTool codebase for similar oversights, I discovered CVE-2026-3102. Successful exploitation of CVE-2026-3102 enables an attacker to execute arbitrary shell commands with the privileges of the user invoking ExifTool, potentially leading to full system compromise.

Technical details

Disclaimer

Exploiting CVE-2026-3102 requires the -n (also known as -printConv) flag and outputs machine-readable data without additional processing.

Tracing the vulnerable sink

Taint analysis (aka tainted data analysis) allows for the detection of “dirty” data that reaches dangerous locations without validation. In this context, a “sink” is a point or function in a program where data or a parameter marked as “tainted” or originating from an untrusted source (e.g., user input) can affect the program’s behavior. In ExifTool, these functions are eval and system, both of which are capable of executing system commands. While CVE-2021-22204 exploited an eval function as a sink, this vulnerability (CVE-2026-3102) targets the system function. Knowing the vulnerable sink, we needed to trace how user-controlled data reaches it. Below, we break down the details.

Finding an unsanitized date value

The screenshot above shows where the system() sink resides within the SetMacOSTags function. Tracing backward from system(), we identified the $cmd variable as the source of the executed command. This variable is assembled from three inputs: $file (properly sanitized), $setTags (processed iteratively), and $val (user-controlled and, crucially, left unsanitized in the vulnerable branch).

In ExifTool, a tag is a named metadata field. When parsing an image, the utility extracts date and time values from standard EXIF records or macOS filesystem attributes. To handle file creation dates on macOS, ExifTool relies on the Spotlight system attribute MDItemFSCreationDate. Within the program code, this attribute maps to the internal alias $FileCreateDate. These two identifiers govern how the file creation date is stored and applied.

This creates a critical link to the vulnerability: when parsing an image, ExifTool iterates through the discovered tags. The current tag’s name is assigned to the $tag variable, while its text content (e.g., a date string) is assigned to $val. The vulnerable code path is triggered only when $tag matches MDItemFSCreationDate or $FileCreateDate. At this point, the tag’s content flows into $val and is passed to the SetMacOSTags function. As shown in the screenshot below, the filename parameter is properly escaped, but the date value ($val) is not. Because the date is extracted directly from file metadata, an attacker can inject quotes into this field. This breaks the command structure and allows the payload to execute via the system() sink.

The following screenshots show some of the tags that can be modified. With the vulnerable parameter identified, the next challenge was delivery: how to place our payload into FileCreateDate without triggering early validation? We found the answer in the official documentation.

Planning the payload delivery

Let’s refer to the documentation to understand how ExifTool handles tag operations and identify a legitimate feature that can be repurposed for exploitation. Specifically, we need to find a way to deliver our payload into the vulnerable FileCreateDate parameter. When looking for macOS-related tags as well as FileCreateDate, we can find the following information:

• To write or delete metadata, tag values are assigned using –TAG=[VALUE], and/or the -geotag, -csv= or -json=
• To copy or move metadata, the -tagsFromFile feature is used.

(You can find the useful info on tag operations above and how it relates under the hood in ExifTool in the dedicated section of the documentation and on the ExifTool description page.)

To trigger the vulnerability, we need to copy a string (date format: MM/DD/YYYY) using the -tagsFromFile feature, as this operation invokes the SetMacOSTags function where the unsanitized $val parameter reaches the system() sink.

Why copy instead of writing directly? Because the vulnerable code path (SetMacOSTags) is only triggered when metadata is copied into FileCreateDate — not when it is written directly. By using -tagsFromFile, we can prepare a “source” tag (e.g., DateTimeOriginal) that accepts arbitrary values and copy that value into FileCreateDate, thereby invoking the vulnerable function with our controlled input.

Furthermore, we want to introduce single quotes (since they are not being escaped in $val). For starters, we can look for date-time tag and copy via -tagsFromFile by searching the EXIF tag table. Direct assignment to FileCreateDate is heavily validated, so we looked for a source tag that accepts raw values and can be copied into the target field. The following snippet shows the beginning of said table.

When doing the analysis, I made use of DateTimeOriginal though I believe you can also use CreateDate which is 0x9004 (see the following screenshot). Initial attempts to inject malformed dates failed: ExifTool’s built-in filter rejected the input. To bypass this, we examined how the tool handles raw metadata.

Bypassing the filter

To confirm that the PrintConvInv filter rejects invalid dates when written directly, I ran the following command, where evil_benign.jpg is a normal JPG with an invalid date time format. We are greeted with the error message: Invalid date/time. This requires the time as well. The next screenshot confirms that direct exploitation fails: ExifTool’s date validation detects the malformed input and rejects the change, activating the internal PrintConvInv filter.

That said, it is possible to ignore the formatting and use the -n flag which accepts raw values instead of human-readable value. The -n flag skips the PrintConvInv conversion step, which is exactly where input sanitization occurs. This confirmed we could park unsanitized data in a source tag. The final step was to trigger the vulnerable code path by copying that data into FileCreateDate. This means we should now be able to modify the DateTimeOriginal tag with the invalid date time format with an -n flag. Examining the EXIF metadata tag, we can confirm that we can store a raw value without a proper human readable format that ExifTool accepts:

Triggering the exploit

To inject commands, we have to revisit the single quote injection into this datetime related tag.

The following screenshot shows that we have successfully set the datetime metadata with the single quote. With the payload safely stored in a source tag, the next step was to copy it into FileCreateDate, triggering the vulnerable system() call.

The next step now is to copy the datetime tag to a file which invokes SetMacOSTags. According to the documentation, this is how we can copy the data from the SRC tag to the FileCreateDate tag as seen in the SetMacOSTags with the -tagsFromFile feature.
exiftool [_OPTIONS_] -tagsFromFile _SRCFILE_ [-[_DSTTAG_<]_SRCTAG_...] _FILE_...
Therefore, we can craft our final command:
cp evil_benign.jpg pwn.jpg;
../../exiftool -n -tagsFromFile evil_benign.jpg "-FileCreateDate<DateTimeOriginal" pwn.jpg
Here, we confirm that the payload has been executed! Note that when copying tags in MacOS (Darwin), the /usr/bin/setfile command is used. To view the full $cmd value before the injection, I have added the debugging statement to displaying the actual command that is executed within the system function.

Upon injection, we can see that our command gets executed via command substitution. The single quotes that we added helped to make the entire command syntactically valid. The following shows a more detailed labelling and their roles in making this command line injection successful:

Such an image can appear completely benign and easily find its way into a newsroom or any organization that processes photos on macOS using ExifTool. Once processed, an attacker could silently deploy a Trojan for covert data exfiltration, drop additional malware, or use the compromised machine as a foothold to expand the attack within the victim’s network.

Patch analysis

After verifying successful exploitation, we examined how the maintainer addressed the flaw in version 13.50. In the vulnerable version of ExifTool, commands were sanitized before being concatenated together. This means that it is possible to concatenate single quotes which led to the exploitation. However, by abstracting the system call into a dedicated wrapper and requiring a list of arguments instead of concatenated string, the fix removes the need for any manual escaping altogether.

1. Replacing string form to argument list form:
#### BEFORE
$cmd = "/usr/bin/setfile -d '${val}' '${f}'";
system $cmd;

#### AFTER
system('/usr/bin/setfile', '-d', $val, $file);
2. Create new System() wrapper. In version 13.49, the output is piped to /dev/null . To maintain that logic, the wrapper would temporarily redirect STDOUT/STDERR to /dev/null and restore them after the call.
# Call system command, redirecting all I/O to /dev/null
# Inputs: system arguments
# Returns: system return code
sub System
{
open(my $oldout, ">&STDOUT");
open(my $olderr, ">&STDERR");
open(STDOUT, '>', '/dev/null');
open(STDERR, '>', '/dev/null');
my $result = system(@_);
open(STDOUT, ">&", $oldout);
open(STDERR, ">&", $olderr);
return $result;
}

How to protect against ExifTool vulnerability

It’s critical to ensure that all photo processing workflows are using the updated version. You should verify that all asset management platforms, photo organization apps, and any bulk image processing scripts running on Macs are calling ExifTool version 13.50 or later, and don’t contain an embedded older copy of the ExifTool library.

ExifTool, like any software, may contain additional vulnerabilities of this class. To harden defenses, I recommend using Kaspersky Open Source Software Threats Data Feed for continuous monitoring of open-source components in your software supply chain, and Kaspersky for macOS as comprehensive endpoint protection. Additionally, isolate processing of untrusted files on dedicated machines or virtual environments with strictly limited network and storage access. If you work with freelancers, contractors, or allow BYOD, enforce a policy that only devices with an active macOS security solution can access your corporate network.

Conclusions

CVE-2026-3102 highlights the risks of inconsistent input sanitization in tools that bridge high-level metadata parsing with platform-specific utilities. While exploitation requires explicit flag usage (-n) and is restricted to macOS, the vulnerability underscores the danger of manual escaping routines in evolving codebases. The transition to list-form system execution provides a robust, architecture-level fix that eliminates shell interpretation risks entirely. This case reinforces a core security principle: replacing fragile string concatenation with secure, list-based API calls remains the most reliable mitigation against command injection.

securelist.com/exiftool-compro…

Alessandro Mantovani, collega del Fatto Quotidiano, sia subito rilasciato con tutti gli attivisti della Global Sumud Flotilla sequestrati in acque internazionali dalle forze armate israeliane con un autentico atto di pirateria, per bloccare il soccorso umanitario della martoriata popolazione di Gaza e impedire il racconto dei crimini e delle violazioni dei diritti umani che lì, come in Cisgiordania e in Libano, continuano a essere perpetrati. Un obiettivo, quest’ultimo, perseguito con la mattanza dei cronisti sul campo, le intimidazioni, l’accesso negato all’informazione internazionale.

Stampa Romana esprime tutta la sua vicinanza ad Alessandro Mantovani e agli altri sequestrati, per le ragioni dell’umanità e del diritto di cronaca.

La Segreteria dell’ASR

dicorinto.it/associazionismo/s…

Many of us have suffered the common experience of buying a great deal of (now very expensive) food, only to have it go off before it can be consumed. [ptallthings93] has whipped up a simple device to try and tackle this problem.

The result is DecayDock, which lives on a fridge and tries to keep track of what’s going on inside. It achieves this with the use of an ESP32-CAM module, which combines the capable microcontroller with a camera for image detection work. With the aid of an Edge AI model, it’s able to detect common food items that are held in front of the camera, which are in turn added to an internal inventory. The items are tracked over time based on expected shelf lives, and the freshness of various items in the fridge is displayed on an attached LCD screen with a green/yellow/red color coding system.

The system is only making estimates—it’s not able to actually identify when the cheese has gone moldy or the milk has gone sour. Still, if you struggle to remember what you should be prioritizing to use in your fridge, it might be a handy aid.

Ultimately, we never really saw smart fridges dominate the market, even though the idea has long been a popular one in futurist circles. Perhaps none of them thought that nobody really wants to stand staring down at a screen on the fridge all day. In reality, some areas of the home are best left unsmartified.

hackaday.com/2026/05/20/decayd…

Custom printed circuit boards have become more and more accessible to the average hobbyist over the last decade. But one problem still remains: your circuits will take at least a couple days to make. But what if you needed some really rapid prototypes? [The Raccoon Lab] shows us how to do it with a 3D printer.

You start with the usual hobby PCB pipeline: take your idea, make a schematic, and then lay it out in KiCad. That’s where the changes start: to keep traces strong, they are made very thick. The PCB is then exported and opened in 3D CAD software, where the traces are extruded to be 2 mm tall. Off to the printer! The newly printed “circuit board” is made conductive by applying copper tape to it, and traces are cut out along their raised edges.

The result is a very quick and dirty PCB. Sure, it isn’t exactly production-ready, but for just about any simple microcontroller project it’ll do just fine, and it’s a whole lot more accessible than milling one using a CNC! We’ve seen a few variations on this approach recently, including some custom software designed to help along the process.

youtube.com/embed/O7aimMbIAvA?…

hackaday.com/2026/05/19/using-…

Magnetic fields are all around us. We can’t really feel or see them ourselves, per se, but we can map them with the right hardware, like this device built by [edosari50].

The build uses an ESP32 microcontroller, which is built on to a board with an integrated 4.3″ touchscreen LCD. It’s paired with an Arduino Nano, which does the work of actually talking to a pair of EMS100 Fluxgate magnetic sensors. The slower, less capable Arduino handles the low-level chatter and then passes the readouts to the ESP32 over a UART connection. Power is courtesy of a pair of 18650 lithium-ion cells, and a XL4005 DC-DC converter. A lithium-ion charging module is on hand to keep the batteries topped off safely. Scan results are visualized on the device itself using a heatmap representation, and can also be exported to SD card for later analysis if so desired.

Unless you’re in the geological field or otherwise hunting for stuff underground, this probably isn’t a tool you’ll have a lot of use for. However, if you like finding magnetic anomalies and investigating them, it might be very much in your wheelhouse. We’ve featured other tools for magnetic visualization before, too. Video after the break.

youtube.com/embed/CHlLDAJMrik?…

hackaday.com/2026/05/19/buildi…

Even [maurycyz] doesn’t think it is a good idea, but it is possible to use an AVR 8-bit CPU to serve web pages. Of course, it is a vastly simplified web server, but it does serve pages — OK, technically just one page — to the public Internet.

Working backward, it is fairly easy to get the microcontroller to note an HTTP request and then simply spit out a prerecorded HTTP response to provide the page. The hard part is connecting the little processor to the network. The server is dead simple, just a CPU and a scant number of components like filter caps and LEDs. The trick is to use SLIP, an ancient protocol used to connect dial-up modem terminals to the network.

Linux supports SLIP, so the MCU connects to a Linux computer via SLIP. Then the Linux computer uses WireGuard to network with the remote web server that serves [maurycyz’s] site. The SLIP implementation assumes that IP packets aren’t fragmented, which is normally true these days. TCP was a bit more complicated since you have to track the connection state and possibly re-transmit lost packets. Still, nothing the AVR with 8 K of RAM and 64 K of flash can’t handle.

Practical? No. Cool? Sort of. Funny that a disposable vape has more CPU power. Of course, something like an ESP32 is an obvious choice.