Once upon a time, computing was simple. You had files on a floppy disk. If you wanted to take them to a different computer, you ejected the disk from one machine and put it in another. It wasn’t fast, but it was easy and intuitive. Besides, you probably only had one computer of your own, anyway.

Life has since gotten a lot more complex. You’ve got a desktop, a laptop, a work laptop, your personal and business phones, and a smart watch to boot. You live amongst a swirling maelstrom of terabytes of data. Despite all the technical advances that got you here, it’s still a pain to get a file from one device to another, even when they’re sitting on the same desk. Why?!

This Modern Glitch

So many buttons to share a file… just get it on to the computer!!!
Our computers are actually very good at connecting to each other. We have Ethernet devices with auto-negotiation, WiFi and Bluetooth in just about everything, and DHCP for good measure. It’s easy to get devices on the network and online. One might think all this connectivity would make sharing data easy. But we’re not so lucky.

Let’s take a straightforward example. Just getting a JPG off a smartphone requires jumping several hurdles and a little bit of begging to the benevolent tech gods. You can plug your phone in via USB to grab files, assuming you’ve got an Android, but you’ll have to flick through menus multiple times to get it to shift into the right mode to get files off. An iPhone will allow the same but you’ll need an app to help “import” them.

You could alternatively try sending them via Bluetooth, but you’ll have to go through the hassle of pairing, which almost never works first time. You’ll also get glacial transfer speeds and watching the process fail a few times. Alternatively you might see if your phone comes with a proprietary app for transfers, or you could try waiting to sync files to a cloud service or just emailing them to yourself. The latter method will make a mess of your inbox, but at least you get the files across when you need them.

It Was Not Ever Thus

In the Windows 9x days, sharing files in the home was easy. Permissions were simple, but security was not up to the standards of today.
It wasn’t always like this. Jump back a quarter century, and things looked very different. Windows 9x had a massive install base, with Windows XP just bursting on to the scene. You could still sneakernet stuff around with floppy disks if you wanted, of course. But it was also a cinch to set up simple network shares to access files across machines on a home network. It just worked.

Much the same was true of the Macintosh ecosystem. Back then, smartphones weren’t a thing, and few of us were carrying any sort of device with any real amount of data. Things like digital cameras and MP3 players would soon rise to prominence, but getting files on and off them was a dream—simply plug in, and they’d present as a USB mass storage device. No drivers, no passwords, no bloated apps. Just peace.

Of course, that would all change a few years down the line. Take the Windows world as an example. Network shares still exist, and you can set them up if that’s what you really want. Unfortunately, though, they’re so much worse than they used to be at the turn of the century. They’re buried under layers of permissions and user account nonsense that makes enabling them absolutely arcane. Only some of us run multi-user logins on individual machines, even fewer of us choose to run domain-style networks in our homes. In contrast, a lot of us would like it to be easy to pull a few files off the loungeroom computer when needed. However, doing so requires navigating passwords and accounts and setting permissions and if you get the slightest bit of it wrong, you won’t even see the shared files, let alone be able to access them. A task that used to take 3 minutes of setup now takes half an hour or more and a couple trips to Knowledgebase.
Tools like Apple’s AirDrop and Samsung’s Quick Share have attempted to solve this problem, to a degree. Ultimately, though, they have their limitations and aren’t a free-for-all for easily accessing data across devices.
It shouldn’t be like this. One can imagine a world where all our devices in the home are allowed to share files openly and freely. Imagine if you could just click into the network tab on your PC, and see everything across all your devices – your laptops, your phones, your desktops and lab machines. Imagine not having to pair your phone or fiddle with utilities or special sharing tools or, god forbid, sending files all the way to the cloud just to move them three feet across your desk. Imagine this, all your files across all your machines at the click of a button, no auth, no nonsense, whether Apple, Windows, or Android. You already have all these devices talking on the same network, so all your stuff should just be there!

Alas, we cannot have such nice things. It’s not just because Big Tech is full of mean people that want to make life worse than it used to be, but it can feel that way sometimes. Instead, it’s more because of boring, sad, practicalities that are difficult to overcome. Security is perhaps the biggest headline issue in this regard. We now use our personal computers to store more private and confidential data than ever.. This makes access control paramount to avoid bad actors getting access to compromising information. There’s also the need to prevent the easy spread of viruses, which becomes very difficult when there’s a permissive file sharing route between devices. Malware has often taken advantage of holes in network sharing protocols as a vector for infection.

Beyond this, there’s the simple problem of interoperability. There isn’t a uniform standard that would allow easy, secure file sharing across laptops, desktops, and smartphones of all makes and models. This would require a large number of different tech companies to all get together, define a solution, and agree to implement it going forward. Sadly, current thinking seems to be that the proprietary solutions we have today are “good enough.” Apple’s AirDrop or Samsung’s Quick Share will get you by if you stay in the right walled garden, for example, and neither cares much to start a dialogue to establish something better and more cross-platform. Few tech companies would be excited about opening up potential security holes by implementing a new broadly-accessible file sharing protocol, either.
Sometimes it’s quicker to throw something on a USB drive than try and convince Windows networking to let you dump files on a friend’s laptop. You can have two computers right next to each other, on the same network, but it’s just too hard.
Perhaps a metaphor best explains the misery we find ourselves in today. If you live in a safe town with low crime, you might not feel the need to lock your car doors when you pop down to the supermarket. It means you can get in and out of your car without fishing for your keys, which is a great convenience when you’re carrying a bunch of heavy grocery bags. At the same time, you can’t live like this in a nastier place. Bad actors will simply open your door, rifle through your car, and take anything they like. That could end badly for you.

Unfortunately, cyberspace is that nasty place. By and large, we can’t just freely share files between devices because it’s too dangerous to do so. You don’t want your bank accounts drained, or your personal photos used for blackmail, so we have to drench everything in layers of authentication, even in the privacy of our own homes. Perhaps one day there will be some framework that allows us to create a close-knit network of “trusted” devices so we can freely move data about our own protected little bubble. But until then, we’ll have to suffer with Bluetooth passcodes and proprietary apps and the fact that it’s usually quicker to email a friend a photo then to find a way to directly transfer it to their phone which is sitting right next to you. It’s an annoying problem, and one that will not easily be solved.

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

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…