Adobe Acrobat and Reader: 87 records in one advisory
87 records announced together, published between 2018-10-12 and 2019-01-18, every one of them citing the same advisory.
The advisory
Every record in this batch cites https://helpx.adobe.com/security/products/acrobat/apsb18-30.html. That is the CNA's own reference, held in the index, and it is why these records are on one page.
What the records offer
No record in this batch publishes a fixed version in held sources.
No record in this batch is listed by CISA in held sources.
3 of 87 records name something of its own. For the other 84, held sources say the same thing about each.
Most commonly mapped weakness across the batch: Out-of-bounds read.
What this page does not cover
Every record citing this advisory is on this page.
The batch is what one advisory announced. It is not every record sharing this weakness, this product or this mechanism, and nothing here is scoped to any estate.
What this batch was researched, not held
35 of these came from one Check Point fuzzing run against Reader's image parser
Adobe published APSB18-30 on 1 October 2018 at priority 2, and its table now lists 89 identifiers, every one of them credited to someone outside Adobe. The size has a single explanation. Netanel Ben-Simon and Yoav Alon of Check Point Software Technologies are credited on one acknowledgement line holding 35 identifiers, which is the output of the campaign they published as "50 Adobe CVEs in 50 days". They describe building a WinAFL harness against JP2KLib.dll, the library inside Reader that parses JPEG2000 images, and fuzzing that one component rather than the whole application. Their write-up lists 54 identifiers in total, so 35 of those 54 landed in this bulletin. The next largest credits are Lin Wang of Beihang University with 9 across two lines, seven reported directly and two through Trend Micro's Zero Day Initiative, and Ke Liu of Tencent Security Xuanwu Lab with 11. Fifteen of the 89 came in through the Zero Day Initiative in total.
Check Point says its campaign aimed at one image parser inside Reader, and Adobe's credit line is what ties 35 identifiers in this announcement to that campaign. If the record you are reading is one of those 35, that tells you where the researchers were looking and nothing about what Adobe changed. Each entry is its own defect with its own fix, and the other 54 identifiers here have other reporters entirely.
Adobe's table gives a bug class and an impact per entry and never names a component, so the bulletin cannot tell you whether a given record is an image parser crash or something unrelated. Only the credit line hints at it, and a credit is not a component. Check Point's write-up lists 54 identifiers while Adobe credits the pair with 35 here, so the remaining 19 belong to other announcements that this bulletin does not name.
Written from web.archive.org, research.checkpoint.com, helpx.adobe.com. Reviewed for whether every claim traces to one of them, by two independent graders, citation support 4.44 of 5, uniqueness 4 of 5. Stated at high confidence. Nothing in this box is a value the index holds, and none of it opens a receipt.
Listed for shared announcement, not shared vulnerability. Each record here is its own finding with its own page, and fixing one does not address another.
87 records, read from the index as it stood on 2026-09-20. Every row opens the record it names, and every value on that record opens its own receipt.