Cowrie Research

deprecation-without-deauthorization

15 min read

Deprecation Without Deauthorization

  • Name: deprecation without deauthorization
  • Category: exploit pattern / lifecycle-control failure / deprecated-surface authority retention / residual-authority risk
  • Summary: Teams often say a feature, entrypoint, deployment, or whole product is deprecated, legacy, maintenance-only, or sunset. The dangerous assumption is that this social label meaningfully shrinks technical authority by itself. It does not. If the old path still mints, still sets solvency, still moves custody, still controls admin rights, or still gates withdrawals, then it is not dead; it is merely less watched. Acala preserves the deprecated reward branch still had stablecoin mint authority variant. Holograph preserves the legacy operator / proxy admin still sat inside the mint-authority boundary variant. Sturdy preserves the deprecated helper entrypoint missed later hardening and still touched solvency variant. TempleDAO / STAX preserves the retiring old staking system still certified withdrawable balance in the replacement contract variant. Aztec Connect and Aztec 2.0 preserve the deprecated immutable system still custodied withdrawable value variant. Moonwell Moonriver preserves the deprecated deployment still held constitutional authority over real cash variant. The recurring failure is not just stale code. It is mistaking operational discouragement for actual deauthorization.
  • What it is:
    • A protocol marks some path as deprecated, old, legacy, sunset, paused-in-practice, or no-longer-recommended.
    • Users, operators, or developers implicitly downgrade how much security review and monitoring that path receives.
    • But the path still retains live economic or constitutional authority: minting, collateral toggles, withdrawals, governance, upgrade rights, settlement, or custody.
    • Later hardening, monitoring, or cleanup focuses on the preferred path while the deprecated surface remains callable or still controls real value.
    • The exploit comes from that mismatch: the system treats the old surface as authoritative even though the team treats it as conceptually dead.
  • Typical preconditions:
    • Deprecated code is left reachable behind configuration, permissions that are still broad enough, or immutable contracts that cannot be retired automatically.
    • New safeguards are applied only to the main path, leaving legacy entrypoints outside the hardened perimeter.
    • Residual deployments keep governance, admin, or treasury rights after user attention and market depth have already decayed.
    • Operators rely on convention (nobody should use this anymore) rather than enforced deauthorization (this can no longer move value or authority).
    • Cleanup plans remove front-end prominence or documentation support before they remove real authority.
    • Monitoring, alerting, and incident response also decay faster than the deprecated surface’s ability to cause damage.
  • Common vulnerable surfaces:
    • reward or incentive modules that still have mint authority after the feature is considered obsolete
    • deprecated lending or collateral-management entrypoints left outside newer validation logic
    • sunset deployments whose governor, timelock, oracle admin, or market admin still controls real balances
    • immutable rollup, bridge, or vault systems that remain withdrawable long after active product support ends
    • half-configured or maintenance-only strategy paths that are still callable from public entrypoints
    • migration helpers that still accept a retiring staking, lock, or vault system as authority for creating new redeemable balances or releasing custody
  • Failure sequence:
    1. The protocol socially deprecates a feature, route, or deployment.
    2. Attention, testing, and operational discipline shift to the preferred replacement.
    3. The old surface still retains live authority over money, solvency, or governance.
    4. An attacker finds that the deprecated surface either missed later hardening, can still be steered by configuration, or still protects real cash with weakened monitoring.
    5. The system honors the old authority exactly as designed, because no technical deauthorization ever happened.
    6. Operators discover that deprecated was only documentation, not a state transition.
  • Variants:
    • Deprecated mint branch still live — an old reward, issuance, or accounting path can still create unbacked value, as in Acala.
    • Deprecated control plane still speaks for issuance — a legacy operator, proxy, or admin stack is treated as old infrastructure socially but still remains inside the mint-authority boundary, as in Holograph.
    • Deprecated helper missed safety retrofit — a lower-profile entrypoint still mutates solvency or authorization state outside newer invariant checks, as in Sturdy.
    • Deprecated deployment still governs cash — a sunset chain instance or old governor still controls markets, treasuries, or admin rights, as in Moonwell Moonriver.
    • Deprecated migration source still certifies value — a retiring staking, lock, or vault system is still accepted as authoritative proof for creating or refunding redeemable balance in the replacement flow, as in TempleDAO / STAX.
    • Deprecated immutable system still custodies value — active development ends, but withdrawable balances remain exposed to latent bugs, as in Aztec Connect.
    • Operationally dead, technically live — front ends, docs, and social attention disappear long before the underlying authority surface is removed.

Three retirement-authority promotions reviewers should not collapse

  1. A deprecated surface still exists at all

    • The old contract, deployment, helper, governor, migration source, withdrawal rail, or operator stack is still reachable enough to do something.
    • This is only the reachability question: some old path is still there.

  2. That surviving surface still counts as canonical authority truth for this exact action

    • The harder question is whether the system still treats that old path as authoritative for minting, solvency, withdrawal eligibility, governance, settlement, or configuration.
    • Many incidents become catastrophic because teams quietly promote legacy compatibility into still canonical certifier of value or authority.

  3. That accepted legacy truth still deserves this much live authority right now

    • Even if a residual path must survive for compatibility or exits, it should not automatically retain ordinary-speed mint, admin, governance, collateral, or treasury authority.
    • This is the authority-budget question: why does this old path still get to matter this much today?

Healthy retirement review keeps those three promotions separate instead of flattening them into one vague the legacy system was still live story.

  • Detection heuristics:
    • Inventory every path or deployment described as deprecated, legacy, sunset, old, maintenance-only, unsupported, or do not use and ask what exact authority it still has.
    • Diff new safety checks against the full callable surface; if a mitigation was added function-by-function, assume a legacy sibling may still be exposed.
    • Treat configuration-reachable deprecated branches as live production code, especially if they can mint, publish prices, toggle collateral, or release value.
    • Ask whether removing front-end visibility or reducing docs support changed any onchain power at all.
    • For old deployments, compare residual protected value with current governance depth, liquidity, and monitoring quality.
    • For immutable systems, ask whether a product can be deprecated while still leaving ordinary withdrawals or settlement live for years.
  • Defenses:
    • Turn deprecation into an enforced state transition: revoke mint paths, disable entrypoints, migrate balances, remove admin rights, or quarantine withdrawals behind narrower controls.
    • When hardening one vulnerability class, prove coverage across the whole authority surface rather than only the primary UX path.
    • Treat deprecated code as high-risk until it is removed, permissioned off, or economically neutered.
    • Move residual deployments to a clearly defended custodian or fully unwind their cash and root powers.
    • Separate unsupported from still authoritative in docs and runbooks; if users can still lose money through it, it needs first-class security ownership.
    • Build explicit decommissioning checklists that remove authority, not just attention; decommissioning-authority-extinguishment-discipline is the positive-design companion for what those runbooks should prove.
    • If the old system must survive for withdrawals or settlement, force it into a bounded residual service rather than vague legacy compatibility; exit-only-residual-surface-discipline is the narrower companion for that case.
    • Once that residual path exists, publish it as withdraw only, still monitored and remove downstream fresh-trust assumptions instead of letting vague legacy labeling re-normalize it; exit-only-status-signaling-and-downstream-de-recognition is the communication-side companion for that case.
    • Then publish one canonical structured residual-status object so routers, collateral engines, dashboards, and governance tooling do not have to infer that treatment from prose; machine-readable-residual-status-publication is the policy-distribution companion for that case.
    • Then keep the balances left behind segregated from active TVL, route scoring, and collateral assumptions so residual inventory does not quietly regain production meaning; residual-liquidity-segregation-and-active-tvl-hygiene is the accounting-side companion for that case.

What sound design looks like

  • Healthy systems keep three retirement-authority promotions explicit instead of inheriting them from one soft legacy label: a deprecated surface still exists, that surviving surface still counts as canonical authority truth for this exact action, and that accepted legacy truth still deserves this much live authority right now should each need their own justification.
  • Deprecation is a balance-sheet and authority transition, not a documentation update. The old surface either loses the power to mint, govern, settle, configure, or withdraw value, or it is still a production security surface no matter how unfashionable it has become.
  • Retirement should narrow authority monotonically: active can become exit-only, admin-frozen, or fully extinguished, but it should never linger in a socially dead yet technically sovereign middle state.
  • Residual compatibility paths should be explicit and bounded. If withdrawals or migrations must stay live, the protocol should preserve only that narrow duty, remove every unrelated privilege, and publish the residual status clearly enough that downstream systems stop treating the venue as normal liquidity or collateral support.
  • Hardening should follow authority, not traffic. Legacy entrypoints, stale deployments, and obsolete operators deserve first-class review for as long as they can still define money-good truth.
  • A decommissioned system should have one accountable owner until the last real power is gone: someone who can explain what the old surface still controls, what monitoring still covers it, and what exact event will count as true retirement.

Failure-prevention checklist

  • Maintain a decommissioning inventory that names every deprecated contract, deployment, helper, admin role, reward rail, migration source, and residual balance along with the exact authority each still holds.
  • Document the three retirement gates explicitly for each legacy surface: still reachable at all, still canonical for this action class, and still allowed this much live authority. If teams cannot answer those separately, deprecated is doing too much narrative work.
  • Convert deprecated into an objective state change: disable public entrypoints, revoke minters and admins, zero configuration that can still publish value, and remove old surfaces from downstream solvency and routing assumptions.
  • Diff every new hardening patch against the full historical callable surface, including legacy siblings and compatibility helpers, before declaring a vulnerability class closed.
  • Force residual systems into explicit bounded modes such as withdraw-only, redeem-only, or admin-frozen, and make the residual mode machine-readable rather than prose-only.
  • Move leftover cash, governance rights, proxy-admin rights, oracle setters, and mint authority to a clearly owned successor custodian or extinguish them entirely before reducing monitoring.
  • Keep deprecated surfaces inside first-class alerting, code-ownership, and incident-response coverage until their authority is truly gone; low traffic is not a security downgrade signal.
  • Treat migrations as authority transfer projects, not UX upgrades: the old system should stop certifying balances, permissions, or collateral truth the moment the replacement starts honoring them.
  • Periodically test whether any legacy path can still mint, withdraw, toggle collateral, set rates, or govern value despite current team beliefs that it is dead.

Audit prompts

  • Which paths, deployments, and roles are described internally or publicly as deprecated, legacy, maintenance-only, old, sunset, exit-only, or unsupported, and what exact authority does each still retain?
  • For each such surface, can reviewers answer three separate questions: does it still exist at all, does it still count as canonical authority truth for this exact action, and if so why does it still deserve this much live authority?
  • When the last major hardening change landed, which legacy siblings, helper functions, migration adapters, or old deployments were explicitly checked for the same bug class?
  • Could a deprecated branch still publish any truth that downstream systems honor: balances, exchange rates, reward indexes, withdrawal eligibility, governance authority, bridge release authority, or mint limits?
  • Has front-end removal or documentation de-emphasis been mistaken for technical retirement anywhere in the stack?
  • If a deprecated deployment still holds assets or admin rights, what defended owner now controls those rights, and what prevents cheap governance or stale admin paths from seizing them?
  • Are residual balances and deprecated venues still counted in active TVL, route quality, collateral support, or governance significance even though the team believes they are out of production?
  • Which monitoring, alerting, and signer runbooks still cover deprecated authority surfaces, and which ones quietly stopped when attention shifted to the replacement?
  • If an attacker used the old path today, would responders clearly recognize it as a live authority incident rather than a confusing but that system was deprecated anomaly?

Lessons that should already be standard

  • Deprecated is not a security control. Authority only shrinks when the system can no longer exercise it.

  • The old path still exists, the old path still counts as canonical authority truth, and the old path still deserves live economic or constitutional budget are three different claims.

  • Removing a UI path or docs page without removing onchain or backend authority usually makes the surface more dangerous, not less, because it becomes both live and under-watched.

  • A migration is incomplete if the retiring system can still certify balances, governance rights, collateral truth, or redeemable claims in the replacement environment.

  • Hardening only the popular path is how legacy siblings become exploit paths.

  • Residual deployments need stronger clarity, not vaguer language: either they are truly dead, or they are still a production security surface with explicit bounded duties.

  • Teams should assume deprecated systems fail at the worst possible moment: after review ownership, operator memory, monitoring quality, and market attention have already decayed.

  • High-signal incidents:

    • [[../../../incidents/governance-admin-upgrades/acala-ibtc-ausd-deprecated-dexsaving-reward-rate-misconfiguration-recursive-unbacked-ausd-mint-2022-08-14|Acala iBTC/aUSD deprecated DexSaving reward-rate misconfiguration / recursive unbacked aUSD mint (2022-08-14)]] — a deprecated rewards branch still had aUSD mint authority, and one mis-set DexSavingRewardRates parameter turned ordinary LP reward claims into recursive unbacked stable issuance.
    • 1B HLG mint (2024-06-13) — Holograph’s legacy v1 operator / proxy admin surface was socially obsolete but still technically authoritative enough to sit inside the HLG mint boundary, so retained historical admin access functioned as a live backdoor rather than dead infrastructure.
    • collateral-toggle bypass (2023-06-12) — Sturdy had already wrapped most paths with _validateOracle(), but one deprecated setUserUseReserveAsCollateral() entrypoint still touched solvency without the new protection.
    • [[../../../incidents/lending-liquidations/templedao-stax-migratestake-unvalidated-oldstaking-drain-2022-10-11|TempleDAO / STAX migrateStake() unvalidated oldStaking drain (2022-10-11)]] — STAX’s replacement staking contract treated a retiring oldStaking system as if it could still certify new redeemable stake, so migration support remained a live withdrawal-authority surface instead of a harmless legacy bridge.
    • [[../../../incidents/proofs-verifiers/aztec-connect-processrollup-numrealtxs-proof-settlement-boundary-drain-2026-06-14|Aztec Connect processRollup() numRealTxs proof-settlement boundary drain (2026-06-14)]] — Aztec Connect had been deprecated and governance-renounced, but the immutable system still held withdrawable value, so the old proof/settlement flaw remained economically live.
    • [[../../../incidents/proofs-verifiers/aztec-2-escapehatch-old-data-root-decoupling-unsound-proof-withdrawal-2026-06-17|Aztec 2.0 escapeHatch() old_data_root decoupling / unsound proof withdrawal (2026-06-17)]] — Aztec 2.0 had been deprecated even earlier, yet the old escape-hatch verifier and residual operator permissions still controlled real assets long after the codebase had moved on.
    • Moonwell Moonriver MFAM low-float governance capture attempt (2026-03-24) — a deprecated deployment still controlled about $1.08M of market cash and admin rights behind governance cheap enough to buy outright.

Internal linkages

Control surface

Graph View

Backlinks