Deus DAO / DEI stablecoin: Mis-ordered Parameters in burnFrom — Public Approval Override

Summary #

Deus DAO / DEI stablecoin suffered a Stablecoin / CDP on 2023-05-06, resulting in a loss of approximately $7M.

What happened #

Deus DAO's third hack in two years came from a mis-ordered parameter in the `burnFrom` function of a token upgrade, allowing anyone to seize approval over DEI holders' balances and drain $6.5M across three chains.

Linked factors #

• RD-F-004 — causal : Audit count likely 0; floor display [via dashboard_risk_factors/Vulnerability in audited or unaudited code: Unknown — likely unaudited for the specific upgrade]
• RD-F-006 — causal : Audit-deploy gap (RD-F-006 time between audit and deploy) [via dashboard_risk_factors/Exploited code newly deployed/upgraded?: Y — the vulnerable burnFrom function was introduced in an upgrade approximately 1 month before the exploit] || Audit-deploy gap — alternate field name [via dashboard_risk_factors/Exploited code newly deployed/upgraded?: Y — the vulnerable burnFrom function was introduced in an upgrade approximately 1 month before the exploit] || Time between audit end and deploy [via cross-hack: Factor 4: Newly Deployed or Unannounced Contract]
• RD-F-007 — causal : Direct: bug bounty presence + max payout [via cross-hack: Factor 9: No Bug Bounty Program] || Bug bounty absent — baseline integrity gap [via dashboard_risk_factors/Bug bounty: Unknown]
• RD-F-027 — causal : ★ Single admin EOA — when value mentions key compromise [via realtime_signals/Governance/admin action: Y — contract upgrade deploying the flawed burnFrom function was an admin/deployer action visible on-chain]
• RD-F-050 — causal : Dependency graph [via cross-hack: Factor 6: Cross-Protocol / Composability Complexity]
• RD-F-052 — related : Breakage analysis [via cross-hack: Factor 6: Cross-Protocol / Composability Complexity]
• RD-F-053 — causal : ★ Oracle source = spot DEX pool (no TWAP, no fallback) [via cross-hack: Factor 16: Single-Source VWAP / Thin-Liquidity Oracle Without Flash Swap Filtering]
• RD-F-055 — related : Underlying oracle pool depth (USD) [via cross-hack: Factor 16: Single-Source VWAP / Thin-Liquidity Oracle Without Flash Swap Filtering]
• RD-F-056 — related : Single-pool oracle (no medianization) [via cross-hack: Factor 16: Single-Source VWAP / Thin-Liquidity Oracle Without Flash Swap Filtering]
• RD-F-077 — causal : Prior exploit count [via cross-hack: Factor 5: Second Exploit on Same Protocol]
• RD-F-078 — causal : Chronic flag (≥3 prior exploits) [via cross-hack: Factor 5: Second Exploit on Same Protocol] || Chronic flag (≥3 prior exploits) [via cross-hack: Factor 59: Three-or-More Exploit History]
• RD-F-079 — causal : Same-root-cause repeat exploit [via cross-hack: Factor 5: Second Exploit on Same Protocol]
• RD-F-101 — illustrative : Large governance proposal queued — RT signal would have fired [via realtime_signals/Governance/admin action: Y — contract upgrade deploying the flawed burnFrom function was an admin/deployer action visible on-chain]
• RD-F-111 — causal : Team doxx status — pseudonymous-no-track-record class [via dashboard_risk_factors/Team anonymity: Unknown]
• RD-F-141 — related : Test-mode parameters left on in deploy (possibly related) [via cross-hack: Factor 4: Newly Deployed or Unannounced Contract]
• RD-F-146 — related : New deploys in last 30 days (fresh attack surface) [via cross-hack: Factor 4: Newly Deployed or Unannounced Contract] || New deploys in last 30 days — fresh attack surface [via dashboard_risk_factors/Exploited code newly deployed/upgraded?: Y — the vulnerable burnFrom function was introduced in an upgrade approximately 1 month before the exploit]