CIRCLE WITH A DOT

I guess we've entered the phase where doing anything is going to require you uploading your ID and more.

Pasting into PowerShell on Windows 11 is orders of magnitude slower than doing the same on Windows 10.

Is there a workaround for this?

This is now fixed as CVE-2026-34621.

Interestingly, it's a single CVE that is described as RCE. So presumably the same vulnerability that allowed for the reading of arbitrary files also is what enabled RCE.

Which suggests that somebody at Adobe did see what the second stage looked like. Or was able logically draw the conclusion that the same vulnerability (used in a different way) could be leveraged for RCE.

For the record, what got the JavaScript deobfuscated was:
https://webcrack.netlify.app/

There's also:
https://obf-io.deobfuscate.io/

It sure is better to run an app to do things than to even attempt to believe the nonsense that AI tools spew out.

@waldi
But it's a privileged function.
The vulnerability at play here is that normal JavaScript in a PDF is able to call privileged functions.

@waldi
Well, that's the vulnerability.

@fellows
Depends on the sandbox, I suppose.
The vulnerability being exploited merely reads files like ntdll.dll to get version infromation. But the subsequent polling of a remote C2 host is a touch out of the ordinary. At least to me.

And just for anybody playing along, again from the Bad Site, a link to a properly (functional) deobfuscated JavaScript has been shared.

And yeah, this part of the exploit allows for reading of arbitrary files.

Now, whatever threat actor at play here was fine with buffoons such as myself getting access to this part of the exploit chain. As it was only used to communicate precise details to the C2 server. i.e., this exploit chain was the disposable part.

I can only imagine what sort of second-stage exploit is being served up AES-encrypted to only some individuals.

Now, even without a fancy second stage, I suspect the ability to exfiltrate arbitrary files off of a system opening the PDF ain't nothing to sneeze at.

But I suppose I'll also note: What Grok provided to me was completely made up, including a nonsensical call to Collab.collectEmailInfo(). But to those not paying attention, it seemed plausible.

Which had a buffer overflow in CVE-2007-5659.

Strange days indeed.

@Chris_vonW
No, if JavaScript isn't enabled, the exploit doesn't do a thing.

As I was looking into this (specifically the readFileIntoStream() part), I was quite disappointed by where ChatGPT would refuse to go further. Because I'm apparently a criminal and all. The irony here being that I already provided to ChatGPT the JavaScript that performs the exploit. Albeit in a form that isn't readable by humans. As such, ChatGPT's refusal to proceed only helps the miscreants already performing attacks.

Compared to Grok, which just did what I asked.

I'm not particularly fond of receiving ethical judgment and assumptions about why I'm doing my job

@DaveMWilburn
What makes a PDF reader better than its competition is the number of features that it foists upon you, obviously.

Over on the Bad Site is a bit of analysis

The million dollar question is: Is this vulnerability chain, which is honestly used just to provide useful information to the C2 just the warm-up to the real exploit delivered by the C2?

Or is privileged JavaScript execution enough to do bad things?

The interesting thing about using ntdll.dll as the target for this first vulnerability is that in normal Reader operation, ntdll.dll is accessed.

So there's no immediate obvious symptom of shenanigans. Other than the fact that a C2 server is polled for further instructions that is.

There is at least one Adobe Reader 0day being exploited in the wild:
https://justhaifei1.blogspot.com/2026/04/expmon-detected-sophisticated-zero-day-adobe-reader.html

TL;DR: One 0day is being used to simply communicate details to a C2 server to get further commands. Specifically, there is a vulnerability that allows reading arbitrary local files using Reader JavaScript. In this case, ntdll.dll and friends, so that the C2 knows specifically what version of Windows the victim is running.

Nobody knows what secondary payload the C2 is delivering to selected targets. But it's a direct pipeline to allow the C2 to run arbitrary JavaScript on the victim system.

So I'll bet dollars to donuts that there is a second more powerful vulnerability that the attackers have up their sleeves. Or at the very least, the same vulnerability that allows the privileged file read might be able to be leveraged to do something nasty. And the whole AES-encrypted C2 stuff is merely to not put the payload statically in the exploit PDF, allowing a dynamic payload for any given target.

@AwkwardTuring
Right. That's the million dollar question.

@omnicore @signalapp
Regardless, even just testing things out on a clean test device, an iPhone with Lockdown Mode enabled still gets push notifications with the incoming message body.

So, color me skeptical that Lockdown Mode does anything regarding this.

@Mer__edith
Can we get a comment on this?

1) The default Signal setting to show message contents in push notifications seems... bad, assuming this article is accurate.
2) Does changing the in-Signal-app setting for Notification Content indeed prevent notifications from being stored anywhere, which by default contains incoming message bodies.

@omnicore @signalapp
Yeah, I've been on Lockdown Mode since it was released.

Do you have a reference for how this is the case?

@bsod
They had access to an unlocked device.

Unclear whether that was voluntary, through coercion, or through trickery like Cellebrite advertises.