defirisk.co
rubric v1.7.0

UUPS _authorizeUpgrade correctly permissioned

A code & audits factor in the v1.7.0 rubric. Measured per protocol on a s cadence.

Methodology how we score#

What this measures
This factor verifies that all UUPS (Universal Upgradeable Proxy Standard) implementation contracts define and correctly restrict the _authorizeUpgrade(address) function. Specifically, the function must revert for any caller that is not the designated owner, admin, or timelock controller. An unprotected or absent _authorizeUpgrade() allows any address to point the proxy at a new, attacker-controlled implementation. The assessment is performed by static analysis of the UUPS implementation's _authorizeUpgrade() visibility and access control gate.

Why it matters
UUPS puts the upgrade authorization logic inside the implementation contract rather than the proxy, which means an incorrectly implemented _authorizeUpgrade() is a complete proxy takeover vector. A publicly callable or improperly gated _authorizeUpgrade() allows any attacker to call upgradeTo() and replace the implementation with one that drains all protocol funds in a single transaction. Approximately four documented hacks in the T-01 inventory involve UUPS authorization failures or related proxy upgrade bugs. As UUPS has become a common pattern in newer DeFi deployments, the authorization gate is a critical checkpoint.

Green / Yellow / Red
Green: _authorizeUpgrade() is restricted to owner or admin and reverts for all other callers, confirmed by static analysis; the owner/admin itself is a multisig or timelock. Yellow: _authorizeUpgrade() is correctly restricted but the permissioned caller is a single EOA rather than a multisig or timelock. Red: _authorizeUpgrade() is absent from the implementation contract, or it does not revert for non-owner callers.

Common gray cases
This factor is gray for protocols that do not use UUPS proxy patterns -- e.g., transparent proxy, beacon proxy, or non-upgradeable implementations.

Notable historical examples
No hacks are currently linked in the database for this specific factor as a standalone causal driver. The factor is retained as P1 based on approximately four supporting instances in the T-01 evidence inventory.

Measurement what to look for#

Determine whether the UUPS implementation defines `_authorizeUpgrade(address)` restricted to owner/admin/timelock (not open to arbitrary callers).

Data & output #

Data source
Slither `suicidal` + `unprotected-upgrade` detectors + source review of `_authorizeUpgrade` implementation
Output format
Green / Yellow / Red
Evidence artifact
Slither output + source excerpt of `_authorizeUpgrade` function
Confidence signal
green = `_authorizeUpgrade` restricted to authorized role; red = `_authorizeUpgrade` open or missing; gray = contract does not use UUPS pattern (N/A) or source unverified

Scored protocols 0 carry this factor#

No protocols have been scored for this factor yet.

Linked hacks no historical incidents linked#

No historical incidents are linked to this factor.
rubric_version v1.7.0factor RD-F-021category 1carried 0critical no