The mintToken function of a smart contract implementation: 315 records in one advisory
315 records announced together, published between 2018-07-05 and 2018-07-09, every one of them citing the same advisory.
The advisory
Every record in this batch cites https://github.com/BlockChainsSecurity/EtherTokens/blob/master/GEMCHAIN/mint%20integer%20overflo…. 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 315 of the 363 records that cite the same advisory. The other 48 are different findings announced alongside it.
None of those 48 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 lab's catalogue of copied token code, filed as one record per contract address
The anchor is a single markdown file in the GitHub repository BlockChainsSecurity/EtherTokens, created on 3 July 2018, whose repository description reads "Credit by ADLab of Venustech", the research lab of the Chinese security company Venustech. The file takes one Ethereum token, GEMCHAIN, as its worked example. It shows the unguarded mintToken function, walks a proof of concept through the Remix development tool, and shows the owner setting an arbitrary user's balance to zero by overflowing it. Then it says: "Other tokens found vulnerable by us are listed below. These ones have a similar code pattern." What follows is 370 further token sections, each with its own contract address on Etherscan and its own copy of the code, 366 distinct addresses in all. The identifiers came out in two bursts. Across the 2018 public CVE records, 401 cite this repository and 363 of those point at this one file. All 401 were assigned by MITRE, and they were published on exactly two days: 79 on 5 July 2018 and 322 on 9 July 2018. That is why they read identically apart from the token name.
Each record names one contract, deployed at one address, owned by one account. The other records catalogued in the same file name different contracts belonging to different owners. The report's own claim is that they carry a similar code pattern, which is a statement about the source code it prints, not about the contracts being one finding.
A deployed contract cannot be patched at its address, and the file says nothing about whether any of these operators later redeployed or moved holders to a new contract, so nothing here tells you the state of any address now. The file also names no individual author, only the lab in the repository description, and carries no dates, no disclosure history and no vendor contact.
Written from raw.githubusercontent.com, github.com, api.github.com, services.nvd.nist.gov. 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.
315 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.