78 records in one advisory
78 records announced together, published 2022-07-11, every one of them citing the same advisory.
The advisory
Every record in this batch cites https://github.com/github/securitylab/issues/669#issuecomment-1117265726. 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 78 of the 87 records that cite the same advisory. The other 9 are different findings announced alongside it.
None of those 9 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 researcher ran a CodeQL query across GitHub and filed about 92 reports
A researcher using the handle porcupineyhairs opened a placeholder issue with GitHub Security Lab on 28 April 2022 saying "I plan on sending bulk PR's to approx 100 projects", as an entry to the lab's Bug Slayer bounty programme. On 4 May 2022 the same researcher posted a table of close to 92 reports, each one a Python project using Flask's send_file function in a way that let a request read files outside the intended directory, and later confirmed "the findings are from my CodeQL query". Most of the affected projects were small public repositories, and the researcher asked MITRE for identifiers directly when maintainers did not respond, which is why our index holds 78 of these records all published on 11 July 2022. Then the thread turned. Readers showed the proof-of-concept examples used relative rather than absolute traversal, and the researcher replied "I used an automation script to generate those PoC's. Hence, the PoC's could be incorrect". Java teams arrived reporting broken builds, because the product identifiers attached to some of these records matched unrelated libraries such as jakarta-annotation-api and JUnit 5. GitHub Security Lab acknowledged on 19 July 2022 that "there was an error assigning the CPEs for some of the CVEs associated with this Bug Slayer submission" and said it had raised the problem with NIST.
This record is one entry in a table filed by one person from one automated query, so the others are the same pattern in different unrelated projects rather than related work by any project's maintainers. The affected project is usually a small repository, and the researcher wrote the fix as well as the report. One identifier from that table, CVE-2022-31569, was withdrawn after the dispute.
The gap here is not a missing technical detail; it is that parts of this batch were disputed and some of it was withdrawn, and a record does not carry that argument. The reporter's account has since been deleted, so the thread shows a ghost and the researcher's real identity appears nowhere we could read. The published example for a given record may not match what was actually tested, by the researcher's own statement. And a record does not tell you whether the small project it names is still maintained, or whether its own identifier survived.
Written from github.com, github.com, github.com, github.com, github.com, securitylab.github.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.
78 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.