{"id":"GHSA-29h2-jr22-frmh","aliases":[],"status":"published","title":"OpenZeppelin Confidential Contracts `VestingWalletConfidential`: a malicious ERC-7984 token is able to extract private data from the vesting wallet","description":"### Impact\n\nTwo locations consume an encrypted handle returned by an untrusted external party and use it without verifying that the party is ACL-authorized on it.\n\n#### `VestingWalletConfidential`\n\nMalicious users can call `release` with a malicious token. This token could return an alternative handle on `confidentialBalanceOf`, which represents the balance of the vesting wallet on an alternative ERC-7984 token (or any other handle that the vesting wallet has access to). The vesting wallet does not check that the token has ACL access and grants access to a new handle derived from the returned handle.\n\nEffectively, this bug allows a malicious user to gain information about any private `euint64` handle that the vesting wallet has access to via a malicious ERC-7984 token. There is no loss of funds.\n\n#### ERC7984\n\nOn a transfer with callback, `ERC7984` uses the `ebool` returned by the\nrecipient's `IERC7984Receiver.onConfidentialTransferReceived` to drive the refund\nlogic, without checking that the recipient has ACL access to it. A malicious recipient\ncan return any `ebool` the token has access to and recover its plaintext from the\nrefund result, which the token grants the caller access to. The leak is limited\nto `ebool` handles (the value is only used as an `FHE.select` condition), and\nthere is no loss of funds.\n\n### Patches\n\nBoth issues were fixed in the same patch releases: v0.5.2, v0.4.2, v0.3.2\n\n- `VestingWalletConfidential`: 93e75ceed2b9648f53f9d133f431064353456805 (#423).\n- `ERC7984` transfer callback: fe0863af2c9dce7614acce98720a913bf6a767a5 (#428), with follow-up ee47edf189ab681cebdad18bfb53dee541987be2 (#431) permitting an uninitialized returned handle.","severity":{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N","level":"high","from":"ghsa"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-284"],"published":"2026-09-25T19:31:08Z","modified":"2026-09-25T19:45:09Z","fixes":[{"ecosystem":"npm","package":"@openzeppelin/confidential-contracts","fixed_in":["0.3.2","0.4.2","0.5.2"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"@openzeppelin/confidential-contracts","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.3.2"}]}]},{"source":"ghsa","ecosystem":"npm","package":"@openzeppelin/confidential-contracts","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.4.0-rc.0"},{"fixed":"0.4.2"}]}]},{"source":"ghsa","ecosystem":"npm","package":"@openzeppelin/confidential-contracts","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.5.0-rc.0"},{"fixed":"0.5.2"}]}]},{"source":"osv","ecosystem":"npm","package":"@openzeppelin/confidential-contracts","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.3.2"}]}]},{"source":"osv","ecosystem":"npm","package":"@openzeppelin/confidential-contracts","ranges":[{"type":"SEMVER","events":[{"introduced":"0.4.0-rc.0"},{"fixed":"0.4.2"}]}]},{"source":"osv","ecosystem":"npm","package":"@openzeppelin/confidential-contracts","ranges":[{"type":"SEMVER","events":[{"introduced":"0.5.0-rc.0"},{"fixed":"0.5.2"}]}]}],"references":[{"url":"https://github.com/OpenZeppelin/openzeppelin-confidential-contracts/security/advisories/GHSA-29h2-jr22-frmh","tags":["web"]},{"url":"https://github.com/OpenZeppelin/openzeppelin-confidential-contracts/pull/423","tags":["web"]},{"url":"https://github.com/OpenZeppelin/openzeppelin-confidential-contracts/pull/428","tags":["web"]},{"url":"https://github.com/OpenZeppelin/openzeppelin-confidential-contracts/pull/431","tags":["web"]},{"url":"https://github.com/OpenZeppelin/openzeppelin-confidential-contracts/commit/93e75ceed2b9648f53f9d133f431064353456805","tags":["web"]},{"url":"https://github.com/OpenZeppelin/openzeppelin-confidential-contracts/commit/ee47edf189ab681cebdad18bfb53dee541987be2","tags":["web"]},{"url":"https://github.com/OpenZeppelin/openzeppelin-confidential-contracts/commit/fe0863af2c9dce7614acce98720a913bf6a767a5","tags":["web"]},{"url":"https://github.com/OpenZeppelin/openzeppelin-confidential-contracts/releases/tag/v0.3.2","tags":["web"]},{"url":"https://github.com/OpenZeppelin/openzeppelin-confidential-contracts/releases/tag/v0.4.2","tags":["web"]},{"url":"https://github.com/OpenZeppelin/openzeppelin-confidential-contracts/releases/tag/v0.5.2","tags":["web"]},{"url":"https://github.com/advisories/GHSA-29h2-jr22-frmh"},{"url":"https://github.com/OpenZeppelin/openzeppelin-confidential-contracts","tags":["package"]}],"sources":{"ghsa":[{"id":"GHSA-29h2-jr22-frmh","title":"OpenZeppelin Confidential Contracts `VestingWalletConfidential`: a malicious ERC-7984 token is able to extract private data from the vesting wallet","description":"### Impact\n\nTwo locations consume an encrypted handle returned by an untrusted external party and use it without verifying that the party is ACL-authorized on it.\n\n#### `VestingWalletConfidential`\n\nMalicious users can call `release` with a malicious token. This token could return an alternative handle on `confidentialBalanceOf`, which represents the balance of the vesting wallet on an alternative ERC-7984 token (or any other handle that the vesting wallet has access to). The vesting wallet does not check that the token has ACL access and grants access to a new handle derived from the returned handle.\n\nEffectively, this bug allows a malicious user to gain information about any private `euint64` handle that the vesting wallet has access to via a malicious ERC-7984 token. There is no loss of funds.\n\n#### ERC7984\n\nOn a transfer with callback, `ERC7984` uses the `ebool` returned by the\nrecipient's `IERC7984Receiver.onConfidentialTransferReceived` to drive the refund\nlogic, without checking that the recipient has ACL access to it. A malicious recipient\ncan return any `ebool` the token has access to and recover its plaintext from the\nrefund result, which the token grants the caller access to. The leak is limited\nto `ebool` handles (the value is only used as an `FHE.select` condition), and\nthere is no loss of funds.\n\n### Patches\n\nBoth issues were fixed in the same patch releases: v0.5.2, v0.4.2, v0.3.2\n\n- `VestingWalletConfidential`: 93e75ceed2b9648f53f9d133f431064353456805 (#423).\n- `ERC7984` transfer callback: fe0863af2c9dce7614acce98720a913bf6a767a5 (#428), with follow-up ee47edf189ab681cebdad18bfb53dee541987be2 (#431) permitting an uninitialized returned handle.","status":"published","published":"2026-09-25T19:31:08Z","modified":"2026-09-25T19:31:09Z","cvss":[{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-284"],"updated_at":"2026-11-02T14:41:22.654187Z"}],"osv":[{"id":"GHSA-29h2-jr22-frmh","title":"OpenZeppelin Confidential Contracts `VestingWalletConfidential`: a malicious ERC-7984 token is able to extract private data from the vesting wallet","description":"### Impact\n\nTwo locations consume an encrypted handle returned by an untrusted external party and use it without verifying that the party is ACL-authorized on it.\n\n#### `VestingWalletConfidential`\n\nMalicious users can call `release` with a malicious token. This token could return an alternative handle on `confidentialBalanceOf`, which represents the balance of the vesting wallet on an alternative ERC-7984 token (or any other handle that the vesting wallet has access to). The vesting wallet does not check that the token has ACL access and grants access to a new handle derived from the returned handle.\n\nEffectively, this bug allows a malicious user to gain information about any private `euint64` handle that the vesting wallet has access to via a malicious ERC-7984 token. There is no loss of funds.\n\n#### ERC7984\n\nOn a transfer with callback, `ERC7984` uses the `ebool` returned by the\nrecipient's `IERC7984Receiver.onConfidentialTransferReceived` to drive the refund\nlogic, without checking that the recipient has ACL access to it. A malicious recipient\ncan return any `ebool` the token has access to and recover its plaintext from the\nrefund result, which the token grants the caller access to. The leak is limited\nto `ebool` handles (the value is only used as an `FHE.select` condition), and\nthere is no loss of funds.\n\n### Patches\n\nBoth issues were fixed in the same patch releases: v0.5.2, v0.4.2, v0.3.2\n\n- `VestingWalletConfidential`: 93e75ceed2b9648f53f9d133f431064353456805 (#423).\n- `ERC7984` transfer callback: fe0863af2c9dce7614acce98720a913bf6a767a5 (#428), with follow-up ee47edf189ab681cebdad18bfb53dee541987be2 (#431) permitting an uninitialized returned handle.","status":"published","published":"2026-09-25T19:31:08Z","modified":"2026-09-25T19:45:09.704948941Z","cvss":[{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-284"],"updated_at":"2026-11-02T15:46:33.956911Z"}]}}