436 records in one advisory
436 records announced together, published between 2014-09-09 and 2014-10-29, every one of them citing the same advisory.
The advisory
Every record in this batch cites https://docs.google.com/spreadsheets/d/1t5GXwjw82SyunALVJb2w0zi3FoLRIkfGPc7AMjRF0r4/edit?usp=sha…. 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.
Every record names something of its own, listed against it below.
What this page does not cover
This batch is 436 of the 1390 records that cite the same advisory. The other 954 are different findings announced alongside it.
None of those 954 is grouped with any other. Each one has its own record page and nothing else.
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
One CERT researcher's automated phone in a box, testing Android apps for SSL failures
These records come from a single automated testing campaign run by Will Dormann at the CERT Coordination Center, part of Carnegie Mellon University's Software Engineering Institute. He wired the Android emulator to CERT Tapioca, a machine-in-the-middle testing proxy that CERT released on 21 August 2014. VMware snapshots and MonkeyRunner scripts did the repetitive part. Each app was installed, its buttons pressed and its fields typed into, while the proxy watched whether the app accepted a certificate it should have rejected. Apps were tested one at a time and the process ran slowly, yet by 3 September 2014 he had already found several hundred that failed. CERT published the results as a running list, first in vulnerability note VU#582497 and then in the Google spreadsheet that these records point at, recording the app, the tested version, the result and an identifier for each one. Dormann described that spreadsheet as a living document that would keep being updated as more apps were tested, and said CERT was notifying the app authors as it went.
Each record is a different app from a different developer, caught by the same tool making the same mistake, so the others tell you about the tool's reach and not about this app. The shared reference is a spreadsheet that was designed to keep changing, so the row behind any one record may no longer say what it said when the record was written.
The test shows only that an app accepted a certificate it should have refused; it does not show that any user was ever intercepted. It also does not tell you whether a given app was fixed afterwards, except where someone updated the spreadsheet row.
Written from kb.cert.org, sei.cmu.edu, threatpost.com, docs.google.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.
436 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.