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. 🤔
@wdormann Well, maybe using the privileged export function? (just speculation, but it was common years ago)
@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. 😂
@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
@evaristegal0is @wdormann But why fingerprint the target with ntdll.dll first if burning this bug would fix the RCE anyway?
@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.
@wdormann thanks for the heads up on this, we’re all patched up.