GHSA-29H2-JR22-FRMH: Improper Access Control and Handle Substitution in OpenZeppelin Confidential Contracts

The @openzeppelin/confidential-contracts library provides essential primitives for constructing privacy-preserving tokens and financial instruments on EVM-compatible networks using Fully Homomorphic Encryption (FHE). Unlike standard transparent blockchains, FHE-enabled smart contracts perform computations on encrypted data states (such as private balances or boolean conditions) without ever decrypting them. The primary attack surface exposed by this architecture involves how data handles are passed across contract trust boundaries.

To interact with encrypted states within EVM constraints, frameworks like Zama's fhEVM represent encrypted payloads using global cryptographic reference pointers termed "handles" (e.g., ebool, euint64). The security and isolation of these handles rely on an Access Control List (ACL) enforced by the underlying virtual machine, which dictates which smart contracts have authorization to read or compute over specific handle IDs.

This vulnerability represents a systemic architectural validation failure in how handles returned by untrusted external contracts are ingested. Specifically, both VestingWalletConfidential and the ERC7984 transfer callback logic consume ciphertext handles from untrusted entities without verifying that the sending contract has ACL authorization over those handles. This allows an attacker to conduct a handle substitution attack, supplying sensitive handles belonging to other contracts and extracting their plaintext contents.

The fundamental root cause of the vulnerability is the implicit trust placed in FHE handles returned from external calls. In traditional Solidity development, returning an arbitrary data type does not compromise security because variables are scoped. However, FHE handles are global 32-bit or 64-bit integer values pointing to a shared enclave state. Because handles lack inherent namespaces, any contract can attempt to pass any handle ID to another contract.

In VestingWalletConfidential, the vestedAmount function calculates linear vesting by calling IERC7984(token).confidentialBalanceOf(address(this)). Because the returned balance handle was consumed in FHE arithmetic operations (FHE.add) without asserting that the token contract was ACL-authorized on that handle, a malicious token could return an arbitrary handle representing a sensitive private state of the wallet. The wallet would then perform arithmetic operations on this swapped handle and register transit permissions, creating an oracle that leaks private states.

In ERC7984 transfer callbacks, a similar flaw occurs during the evaluation of recipient responses. When performing a transfer with a callback, the token contract executes onConfidentialTransferReceived and expects an ebool handle indicating success or failure. The contract then uses this handle as a condition parameter in FHE.select to determine if a refund is required. Because there is no validation to confirm that the recipient has ACL authorization to the returned ebool, an attacker can pass a victim's encrypted boolean handle. The subsequent transaction execution patterns (whether a refund occurred or not) allow the attacker to deduce the underlying plaintext bit of the victim's handle.

A detailed review of the patches reveals how validation controls were integrated to remediate the handle substitution vectors.

In VestingWalletConfidential.sol, the vulnerability was resolved by introducing a validation function, _checkTokenHandleAccess, which asserts that the token has ACL permissions for the returned handle before performing FHE arithmetic operations. Uninitialized handles (representing zero balances) are ignored to prevent honest zero-value transfers from reverting.

// Patched VestingWalletConfidential.sol
function vestedAmount(address token, uint48 timestamp) public virtual returns (euint128) {
    euint64 balance = IERC7984(token).confidentialBalanceOf(address(this));
    // Fix: Assert that the token contract is authorized on the returned handle
    _checkTokenHandleAccess(token, balance);
    return _vestingSchedule(FHE.add(released(token), balance), timestamp);
}
 
function _checkTokenHandleAccess(address token, euint64 handle) private view {
    require(
        !FHE.isInitialized(handle) || FHE.isAllowed(handle, token),
        VestingWalletConfidentialUnauthorizedHandle(handle, token)
    );
}

In ERC7984Utils.sol, the callback handler was fortified to ensure the recipient contract has actual permissions for the returned boolean handle. The logic checks that either the handle is uninitialized (handling non-FHE receivers safely) or that the recipient is authorized on it via FHE.isAllowed.

// Patched ERC7984Utils.sol
try IERC7984Receiver(to).onConfidentialTransferReceived(operator, from, amount, data) returns (
    ebool retval
) {
    // Fix: Enforce ACL authorization check on returned callback handle
    require(
        !FHE.isInitialized(retval) || FHE.isAllowed(retval, to),
        ERC7984UtilsUnauthorizedUseOfEncryptedAmount(retval, to)
    );
    return retval;
} catch (bytes memory reason) {
    // standard fallback handling
}

To exploit this vulnerability, an attacker constructs a malicious contract that registers as an ERC-7984 token or receiver, allowing them to inject targeted handles into the victim contract's execution thread.

In a callback-driven attack, the adversary target is a confidential boolean value (Target_Bool). The attacker deploys a contract implementing IERC7984Receiver and configures its onConfidentialTransferReceived function to return the handle ID of Target_Bool instead of a newly generated execution status. The attacker then executes a transfer targeting their own receiver contract.

When the token contract processes the transfer, it triggers the callback and receives the substituted handle. It then evaluates the conditional check FHE.select(Target_Bool, refundAmount, zeroAmount). Because the outcome of this transaction (specifically, whether the attacker receives a refund or not) is visible on-chain, the attacker directly observes the logical evaluation of Target_Bool. If the refund is executed, Target_Bool evaluated to false; otherwise, it evaluated to true. This side-channel completely decrypts the target boolean without requiring direct access keys.

Remediation requires upgrading @openzeppelin/confidential-contracts dependencies to versions that enforce strict ACL validation. Project maintainers must audit their configurations to ensure they are on the patched release lines: 0.3.2 for the 0.3.x line, 0.4.2 for the 0.4.x line, and 0.5.2 for the 0.5.x line.

When developing custom FHE-based contracts outside of the OpenZeppelin ecosystem, engineers must follow defensive design principles for handles. Every external call that returns an FHE handle should be subjected to an explicit validation check using FHE.isAllowed(handle, sender) before incorporating the handle into internal arithmetic, comparison, or storage routines. Additionally, developers should design fallback mechanisms to ignore uninitialized handles to prevent Denial of Service (DoS) attacks on non-FHE integrations.