OpenZeppelin Confidential Contracts EUVD-2026-58188

Exploitation requires the targeted ERC7984ERC20Wrapper deployment to have already accumulated a total underlying token balance equivalent to approximately 18.4 trillion wrapped token units (type(uint64).max), which is the overflow threshold for the euint64 confidential supply counter. The wrapped ERC-20 token must therefore have a circulating or transferable supply large enough for a single wrapper instance to be filled to this threshold. Under the default rate() of 1, this means 18.4 trillion ERC-20 base units must be deposited before subsequent wrap calls silently lose funds. Wrappers using a higher rate() value reduce the effective unit count and thus require proportionally more underlying tokens to reach the threshold. No authentication is required - any account calling wrap() or triggering onTransferReceived() after the threshold is met becomes a victim. Wrappers holding tokens with sub-trillion total supply, or wrappers with a sufficiently high rate() override, are not practically at risk.

The CVSS 4.0 score of 6.6 (VI:H, all other impacts N) correctly characterises this as a fund-integrity issue with no confidentiality or availability dimension. The vector AV:N/AC:L/AT:N/PR:N/UI:N indicates the triggering transaction is network-accessible and requires no special privileges; however, the E:U supplemental tag confirms no active exploitation at time of scoring. The critical limiting factor - explicitly acknowledged by the vendor - is that the wrapper must first accumulate approximately 18.4 trillion units of the underlying token before the overflow threshold is reachable. The vendor states that very few tokens with sufficient total supply exist to fill the wrapper under default rate() settings, which substantially narrows the real-world attack surface. EPSS data was not provided in the input; given the experimental nature of the library, a low exploitation probability is inferred but not confirmed. No CISA KEV entry exists. For the small set of deployments that do wrap extremely high-supply tokens, the risk is material - a user will lose funds with no on-chain revert to alert them. For all other deployments, this is a medium-severity latent defect that warrants upgrading but does not represent an immediate crisis.

A user interacts with an ERC7984ERC20Wrapper that has been used to wrap a high-supply token - such as a token with a circulating supply in the trillions - until the wrapper's confidential total supply counter approaches type(uint64).max (~18.4 trillion). Any subsequent call to wrap() or onTransferReceived() (e.g. via ERC-1363 transferAndCall) transfers the caller's underlying ERC-20 tokens into the wrapper contract, but the silent _mint overflow results in no confidential ERC7984 tokens being credited, permanently locking the deposited funds in the contract with no revert or error signal to the caller.