Login
You're viewing the mstdn.social public feed.
  • Will Dormannwdormann@infosec.exchange
    Apr 9, 2026, 10:03 PM

    There is at least one Adobe Reader 0day being exploited in the wild:
    justhaifei1.blogspot.com/2026/

    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.

    Edit: This is now fixed as CVE-2026-34621.

    💬 4🔄 17⭐ 28

Replies

  • Will Dormannwdormann@infosec.exchange
    Apr 9, 2026, 10:07 PM

    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. 😂

    💬 1🔄 2⭐ 5
  • Will Dormannwdormann@infosec.exchange
    Apr 9, 2026, 10:47 PM

    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?

    💬 1🔄 0⭐ 1
  • Will Dormannwdormann@infosec.exchange
    Apr 10, 2026, 12:45 PM

    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

    ChatGPT Why I won't provide that What you're asking for is effectively: "Make this script bypass Acrobat's sandbox and read arbitrary files" That requires: • exploiting a vulnerability • or bypassing security controls I can't help construct or reproduce that behavior.
    Unreadable ChatGPT deobfuscatuon
    Human readable Grok deobfuscatuon
    💬 1🔄 0⭐ 2
  • Will Dormannwdormann@infosec.exchange
    Apr 10, 2026, 3:32 PM

    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.

    💬 1🔄 0⭐ 0
  • Will Dormannwdormann@infosec.exchange
    Apr 10, 2026, 5:24 PM

    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.

    JavaScript code modified to read win.ini and alert it as ASCII text.
    Windows screenshot with procmon showing win.ini being read, and Adobe reader alerting the contents of it.
    💬 2🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • Will Dormannwdormann@infosec.exchange
    Apr 11, 2026, 1:48 PM

    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. 🤔

    💬 2🔄 2⭐ 0
  • 💬 1🔄 0⭐ 0
  • Will Dormannwdormann@infosec.exchange
    Apr 10, 2026, 5:59 PM

    @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.

    💬 0🔄 0⭐ 0
  • 💬 2🔄 0⭐ 0
  • Will Dormannwdormann@infosec.exchange
    Apr 11, 2026, 2:13 PM

    @evaristegal0is
    Yeah, I sifted through the JavaScript API for Reader to see if anything jumped out at me, but no luck. But I'm also not particularly clever. 😂

    💬 1🔄 0⭐ 0
  • evariste.gal🌈isevaristegal0is@mastodon.social
    Apr 11, 2026, 3:37 PM

    @wdormann I don't know but I agree with you and the other user, I think the interesting part is 2nd stage. But maybe they found a way to abuse `exportDataObject` 🤷‍♂️ - but still, my own one is a low-value speculation

    💬 0🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • Will Dormannwdormann@infosec.exchange
    Apr 11, 2026, 2:27 PM

    @caspicat @evaristegal0is
    Right. Thus my skepticism.

    Since the attackers bothered AES-encrypting the 2nd stage, that would sort of imply that the 2nd stage had more value than just the thing to do fingerprinting before the 2nd stage is deployed.

    💬 0🔄 1⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • waldiwaldi@chaos.social
    Apr 10, 2026, 4:06 PM

    @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.

    💬 1🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • Will Dormannwdormann@infosec.exchange
    Apr 10, 2026, 6:16 PM

    @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.

    💬 0🔄 0⭐ 0