Shiny sRWA — blacklisted operators cannot be revoked and can steal NFTs

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 64682-h-02-blacklisted-operators-can-not-be-revoked-from-being-an. Standalone Foundry PoC and full write-up: 64682-h-02-blacklisted-operators-can-not-be-revoked-from-being-an_exp in the evm-hack-registry mirror.

Reproduction: self-contained Foundry PoC (forge-std only) — no fork. Full trace: output.txt.

AuditVault taxonomy: lang/solidity · platform/shieldify · severity/high · sector/nft · sector/rwa · genome: broken-logic · direct-drain · account-ownership

Key info#


Impact	HIGH — Victim NFTs stolen after operator is blacklisted because revoke reverts and the operator re-approves an unblacklisted attacker
Protocol	Shiny sRWA
Bug class	setApprovalForAll reverts on blacklisted operator even for approved=false; approve still usable by blacklisted operators
Finding	Shieldify Security (H-02) · #64682
Report	https://github.com/shieldify-security/audits-portfolio-md/blob/main/Shiny-Security-Review.md
Source	AuditVault
Status	Audit finding — reproduced as a standalone local synthetic
Compiler	`^0.8.24` (PoC)

TL;DR#

setApprovalForAll reverts on blacklisted operator even for approved=false; approve still usable by blacklisted operators

HARM: Victim NFTs stolen after operator is blacklisted because revoke reverts and the operator re-approves an unblacklisted attacker

Root cause#

setApprovalForAll reverts on blacklisted operator even for approved=false; approve still usable by blacklisted operators

Preconditions#

Protocol-specific setup as described in the original finding (roles / managers / pending state in place).

Attack walkthrough#

See the synthetic test/64682-h-02-blacklisted-operators-can-not-be-revoked-from-being-an.sol and the Playground story beats. The @> VULN marker sits on the blamed executable line.

Diagrams#

sequenceDiagram participant U as Victim participant R as sRWA participant O as Blacklisted router participant A as Attacker U->>R: setApprovalForAll router true Note over R: admin blacklists router U->>R: setApprovalForAll router false R-->>U: revert Blacklisted O->>R: approve attacker tokenId A->>R: transferFrom victim attacker R-->>A: NFT stolen

Impact#

Victim NFTs stolen after operator is blacklisted because revoke reverts and the operator re-approves an unblacklisted attacker

Sources#

AuditVault finding
Report: https://github.com/shieldify-security/audits-portfolio-md/blob/main/Shiny-Security-Review.md
Reduced source provenance: github.com/ShinyUrban/SmartContracts@f49b5db sRWA.sol

Sources & further analysis#

Reproductions & code

Standalone PoC + full trace: 64682-h-02-blacklisted-operators-can-not-be-revoked-from-being-an_exp (evm-hack-registry mirror).
AuditVault finding: 64682-h-02-blacklisted-operators-can-not-be-revoked-from-being-an.

Alerts & third-party analyses

Web3Sec X hacked database: search.
Rekt leaderboard: search.
Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.

Source-level debugger — step opcodes and Solidity in sync