> For the complete documentation index, see [llms.txt](https://zokyo-auditing-tutorials.gitbook.io/zokyo-tutorials/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zokyo-auditing-tutorials.gitbook.io/zokyo-tutorials/tutorial-67-erc1155-vulnerabilities/vulnerabilities-in-openzeppelins-erc1155supply-contract.md).

# Vulnerabilities in OpenZeppelin's ERC1155Supply Contract

OpenZeppelin (OZ) provides some of the most trusted and widely used implementations of Ethereum smart contracts. However, like any software, vulnerabilities can occasionally arise. One such vulnerability was discovered in **OpenZeppelin's ERC1155Supply** contract in **version 4.3.2**, which was later patched in **version 4.3.3**.

In this tutorial, we will explore the vulnerability that impacted the ERC1155Supply contract, how attackers might exploit it, and the steps developers should take to secure their contracts when using this implementation. This is critical if your smart contract relies on accurate token supply tracking, as an unpatched version could allow for incorrect supply calculations and potential exploitation.

***

#### Understanding the ERC1155Supply Vulnerability

**ERC1155Supply** is an extension of the **ERC1155** standard that adds functionality to track the total supply of each token type within the collection. The contract introduces the `totalSupply()` function to check how many tokens of a particular type exist.

**The Core Vulnerability**

The vulnerability occurs due to **non-atomic updates** to the token supply. This opens up the possibility of a reentrancy attack, where an attacker can manipulate the token supply during minting or burning operations.

* When tokens are minted, the contract increments the total supply.
* When tokens are burned, the contract decrements the total supply.

However, if the token supply is updated asynchronously (not in a single operation), an attacker can take advantage of this window of time to exploit the contract. Specifically, a function that relies on an accurate **total supply** value could be tricked into working with outdated data, allowing an attacker to exploit the state of the contract before the correct supply is reflected.

#### Exploiting the Vulnerability

Here’s a simplified example of how this vulnerability could be exploited in a contract:

1. **Mint Tokens**: An attacker mints tokens, temporarily increasing the total supply.
2. **Reenter the Contract**: Before the supply is fully updated in the contract’s state, the attacker can reenter by triggering another function, which relies on the outdated total supply data.
3. **Exploit Inaccurate Supply**: Because the total supply hasn’t been updated yet, calculations based on supply values (such as distributions, allocations, or internal logic) can be manipulated to benefit the attacker.

This could result in **incorrect allocations** to users or give malicious actors an unfair advantage over other participants.

***

#### Mitigating the Vulnerability

The vulnerability was addressed in **OpenZeppelin version 4.3.3**, and upgrading your contract dependencies to this version or later is the most straightforward way to fix the issue. However, you should also adopt additional security measures to ensure your smart contracts are safe from similar vulnerabilities.

**1. Upgrade to OpenZeppelin 4.3.3 or Later**

To mitigate this vulnerability, you should ensure that your contracts are using a version of OpenZeppelin that contains the fix:

```yaml
yamlCopy codedependencies:
  - OpenZeppelin/openzeppelin-contracts@4.3.3
```

In the patched version, total supply updates are handled more securely to avoid potential race conditions or delays in updating the state. This prevents reentrancy attacks that could exploit outdated token supply values.

***

#### Conclusion

The **ERC1155Supply vulnerability** in OpenZeppelin's 4.3.2 version allowed for potential exploitation by malicious actors, due to race conditions in supply tracking. By upgrading to **OpenZeppelin 4.3.3 or later**, and following best practices like implementing reentrancy guards and using the CEI pattern, you can mitigate these risks and secure your contracts.

Always ensure you stay up to date with the latest security patches and thoroughly test your contracts to avoid vulnerabilities.