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
-
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.htmlTL;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.
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.
-
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.
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?
-
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.htmlTL;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.
0-day in acroread.exe? Are we back in the early twenty teens again?
-
0-day in acroread.exe? Are we back in the early twenty teens again?
@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?
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
-
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.htmlTL;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.
@wdormann does the exploit still work with JavaScript disabled in Acrobat?
-
@wdormann does the exploit still work with JavaScript disabled in Acrobat?
@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
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.
-
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.htmlTL;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.
@wdormann Why the heck can JavaScript in Adobe crap read stuff outside the document at all? And connect to random cross-origin destinations? This is Microsoft Office scripting all over again.
-
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.
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.
-
R relay@relay.infosec.exchange shared this topic
-
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.
@wdormann if the malicious PDF were blown up in a sandbox, would its activity be detected as abnormal?
-
@wdormann if the malicious PDF were blown up in a sandbox, would its activity be detected as abnormal?
@fellows
Depends on the sandbox, I suppose.
The vulnerability being exploited merely reads files likentdll.dllto get version infromation. But the subsequent polling of a remote C2 host is a touch out of the ordinary. At least to me. -
@wdormann Why the heck can JavaScript in Adobe crap read stuff outside the document at all? And connect to random cross-origin destinations? This is Microsoft Office scripting all over again.
@waldi
Well, that's the vulnerability. -
@waldi
Well, that's the vulnerability.@wdormann No, it is a documented feature: https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsapiref/JS_API_AcroJSChanges.html#new-util-method
-
@wdormann No, it is a documented feature: https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsapiref/JS_API_AcroJSChanges.html#new-util-method
@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. -
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.
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.
-
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.
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.
