- Remedio's researchers found that opening a PDF with a crafted 16-bit image could cause an out-of-bounds write in Adobe Acrobat. Adobe fixed it in bulletin APSB26-141.
- A size check overflowed in 32-bit arithmetic and approved a 16-byte buffer. The loop that followed had no bounds check. The report does not describe exploitation in the wild.
- Confirm every Acrobat machine has the APSB26-141 update, ask how fast your fleet applies reader fixes, and ask whether size checks use arithmetic that cannot overflow.
A size check that can overflow gives false comfort
A size check that overflows approves the very input it exists to stop. That is the clearest lesson in CVE-2026-81983, a memory flaw in Adobe Acrobat that Remedio's research team reported and Adobe has now fixed.
Remedio found that opening a PDF with a crafted 16-bit image could trigger an out-of-bounds write inside Acrobat.dll. Opening the file is the only step required. The researchers reported it to Adobe through HackerOne on 31 May 2026. Adobe assigned the CVE and published the fix in bulletin APSB26-141 on 8 September 2026.
The report does not say the flaw was exploited in the wild. It describes a privately reported bug that has been patched.
How one size check approved a 16-byte buffer
Acrobat must decide how much memory an image needs. It reads the image width from the file, so an attacker controls that number. A validator then works out the expected size: width, times colour components, times two bytes per 16-bit sample. If the data stream is shorter, the file is rejected.
That multiplication uses 32-bit numbers, which cannot hold values past 2^32. With a large enough width, the result wraps around to a tiny number, like an odometer rolling over to zero.
Remedio's example uses four colour components and a width of 0x20000000. The validator's total reaches 0x100000000, wraps to 0, and accepts an 8-byte stream. The buffer that results is only 16 bytes.
A later routine swaps the byte order of the samples in place. Its loop count is width times components, without the factor of two. For the example that is 0x80000000, still enormous. The validator includes the doubling and the loop does not. That mismatch lets one number wrap while the other stays huge.
Nothing compares the loop's count with the buffer size. The only guard is a test that the count is not zero.
The loop moved two bytes at a time. In the crash the researchers captured, it ran roughly 144 KB past the end of the buffer before it reached an unmapped page and stopped.
The routine does not run for every image. It sits on the render path and fires only when several conditions hold. The image must use 16 bits per component, source and destination must be the same, and the component count must qualify. These gating conditions map to fields an attacker sets in the image's own dictionary.
What Adobe changed
The fix is small. The updated code computes the count in 64-bit arithmetic at entry, before either loop, and rejects anything above INT_MAX (0x7FFFFFFF). The example count of 0x80000000 now fails that test before the swap loop runs.
What the fuzzer tells leaders
A fuzzer is a tool that feeds a program thousands of altered inputs and watches for crashes. Remedio says it built one, mostly written by an LLM, in Python. It wraps a single image in a minimal valid PDF and mutates the fields that drive the decoders, such as width, bit depth, colour space and the raw samples.
Remedio says the model was given the PDF specification. That kept the test documents well-formed and aimed the changes at fields the decoders actually read.
The researchers say crashes were caught under a debugger and sorted automatically. They also say work that normally takes days ran in a fraction of that time, which left them free to analyse crashes. That is one team's account of one project.
Our view: this shows where the effort can move. Less of it goes into finding crashes and more into understanding them. The report does not say attackers use the same approach.
The bug itself is an old kind: a number taken from a file and trusted as a loop limit. If finding such mistakes gets cheaper, patch speed matters more. That is our inference from one team's account, not a measured trend.
Questions to put to your team
First, confirm that every machine running Acrobat has the update described in APSB26-141. Ask for a count of machines not yet updated, not a statement that patching is under way.
Second, ask how long your fleet takes to apply a document-reader fix after a vendor bulletin. Opening a file is enough here, so the answer matters.
Third, ask your software and vendor teams whether size checks use arithmetic wide enough that a large input cannot roll over. A check that can wrap gives false comfort.
The fix here was one 64-bit range check. The lasting point: when a file supplies the numbers, do the size sums with room to spare and test the result before any memory is written.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: remedio.io.
