Microsoft is aware of a security feature bypass vulnerability in Windows publicly referred to as "YellowKey". The proof of concept for this vulnerability has been made public violating coordinated vulnerability best practices.

I know people here probably don't want to rehash the disclosure discussion for the 683,547,329th time, but fuck Microsoft and this passive aggressive bullshit trying to frame their own interests as "best practices" in a vuln mitigation publication. Your shit is getting torn apart. Act like you've been there before because we all know you have.

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-45585

Microsoft have issued a CVE for the YellowKey BitLocker bypass and provided mitigation advice - CVE-2026-45585

My take - mitigations too fiddly to actually deploy, BitLocker+PIN and BIOS password mitigates and should be used if you are sensitive to BitLocker bypass threats.

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-45585

Neue BitLocker-Lücke "YellowKey": Microsoft bestätigt Zero-Day-Schwachstelle CVE-2026-45585. Angreifer mit physischem Zugriff können verschlüsselte Laufwerke entschlüsseln. #Microsoft #Windows https://winfuture.de/news,158827.html?utm_source=Mastodon&utm_medium=ManualStatus&utm_campaign=SocialMedia

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-45584

One job. You had one job.

Heap-based buffer overflow in Microsoft Defender allows an unauthorized attacker to execute code over a network.

"No way to prevent this" say users of only language where this regularly happens

https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2026-45584/?utm_campaign=mi_irl&utm_medium=social&utm_source=mastodon

Fedify security updates: 1.9.11, 1.10.10, 2.0.18, 2.1.14, and 2.2.3

If you use Fedify, update to a patched release now. CVE-2026-42462 affects Fedify's Linked Data Signature handling. An attacker could use JSON-LD graph-restructuring features to change how a signed activity is interpreted without invalidating its Linked Data Signature.

Fedify verifies incoming ActivityPub activities with several mechanisms, including HTTP Signatures, Object Integrity Proofs, and Linked Data Signatures. The vulnerable path is Linked Data Signatures: the signature is checked over the canonical RDF graph, but JSON-LD can represent the same graph in more than one JSON shape. In affected versions, that gap could let a signed activity be reshaped so that Fedify reads a different ActivityPub object shape than intended.

The fix makes Fedify normalize Linked Data Signature-verified activities against Fedify's local JSON-LD context before interpreting them, and rejects JSON-LD constructs that can preserve the signed RDF graph while changing the ActivityPub object shape consumed by Fedify.

Patched releases are 1.9.11, 1.10.10, 2.0.18, 2.1.14, and 2.2.3. The GitHub Security Advisory is GHSA-9rfg-v8g9-9367, and the CVE ID is CVE-2026-42462.

Update @fedify/fedify:

npm  update  @fedify/fedify
yarn upgrade @fedify/fedify
pnpm update  @fedify/fedify
bun  update  @fedify/fedify
deno update  @fedify/fedify

After updating, redeploy. If you run other Fedify-based servers, update those too.

Thanks to @Claire for the report and responsible disclosure.

If anything is unclear, ask below.

Qualys has published their full write-up of CVE-2026-46333: https://www.openwall.com/lists/oss-security/2026/05/20/15

This includes a PoC to full root via `accounts-daemon` demonstrated in Debian 13, Fedora Workstation 43/44, so goes well beyond the initial "you need a program that opens a given file and you get to read it" assumption.

Lulz. An RCE from an image? Image metadata, to be precise? In ExifTool, which is supposed to display the image metadata. Only on Macs, though.

"How an image could compromise your Mac: understanding an ExifTool vulnerability (CVE-2026-3102)":

https://securelist.com/exiftool-compromise-mac/119866/

How an image could compromise your Mac: understanding an ExifTool vulnerability (CVE-2026-3102)

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…

CVE-2026-2005: Public PoC Released for Critical 20-Year-Old PostgreSQL pgcrypto RCE Vulnerability
#CyberSecurity
https://securebulletin.com/cve-2026-2005-public-poc-released-for-critical-20-year-old-postgresql-pgcrypto-rce-vulnerability/

ICYMI, Fragnesia (CVE-2026-46300) is a third recently disclosed Linux kernel local-root flaw.

Every supported AlmaLinux release is affected, so patched kernels have been rolled out to production repositories/mirrors.

https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/

🚨 Worried about your #NGINX web servers? 👉 We built a *free* scanner for CVE-2026-42945 (NGINX Rift). 👇

Check your targets now (no account required): https://pentest-tools.com/network-vulnerability-scanning/cve-2026-42945-scanner-nginx-rift

Once the scan completes (and if your target is vulnerable), you'll get a finding that includes:
✅ the detected NGINX version
✅the vulnerable range it falls into
✅the CVSS score & severity rating
✅remediation guidance

Download it as a PDF and share it with whoever handles remediation.

Oh, and one thing to check before you call it patched: upgrading your primary NGINX install *doesn’t* cover copies embedded in container images or Kubernetes ingress controllers.

Those need separate inventory and patching.

PS: We also have a dedicated Kubernetes vulnerability scanner. You can find it on our website.

#offensivesecurity #pentesting #vulnerabilitymanagement

We released Ruby 4.0.5 and published security advisory for CVE-2026-46727.

If you use Ruby 4.0.0~4.0.4, we recommend updating your Ruby version to 4.0.5.

https://www.ruby-lang.org/en/news/2026/05/20/ruby-4-0-5-released/

I thought there was a bug in EPSS since I couldn't see the score for CVE-2026-45498, but... it's just too new. Released today. Rare not-Patch-Tuesday CVE release for Microsoft. Wonder what's up.

(It's a Microsoft Defender DoS, which, sure, seems bad for an A/V thing, but... it's just DoS according to the CVE and KB.)

(Also the KB says there's no exploitation, but CISA KEV says otherwise... curiouser and curiouser.)