Safe Allowance Module Over-Withdrawal Attacks

introduction

ALLOWANCE MODULE OVER-WITHDRAWAL VULNERABILITIES

Introduction

A forensic record of integer overflow, flawed reset logic, and delegatecall misuse vulnerabilities in Safe Allowance Modules that enabled delegates to exceed intended spending limits.

The Safe Allowance Module is a critical component for treasury operations, enabling a Safe's owners to delegate recurring spending authority to a specific address with hard-coded limits on amount, token, and reset period. When these modules contain logic flaws, the consequences are severe: a delegate can drain funds far beyond the intended allowance, effectively bypassing the multi-sig security model that Safe is built upon. This page documents the historical class of vulnerabilities—including integer overflow in allowance computation, flawed reset-timer logic, and unsafe delegatecall patterns—that have been discovered and patched in specific Allowance Module versions.

The core risk stems from the module's privileged position. Allowance Modules are authorized to execute execTransactionFromModule on the Safe, meaning a logic error in the module's internal accounting is directly exploitable for fund extraction. Historical findings show that an attacker with delegate rights could craft a malicious payload to overflow the spent tracking variable, manipulate the reset timestamp to bypass cooldown periods, or force the module to delegatecall into a malicious contract, granting full control over the Safe's storage context. These are not theoretical edge cases; they represent a recurring pattern in spending-limit modules where complex state management intersects with the Safe's powerful module execution interface.

For treasury operators and integrators, the operational impact is immediate: any deployed Allowance Module must be verified against the canonical list of patched versions. The presence of a vulnerable module means the delegate's spending limit is not reliably enforced, and the Safe's funds are at risk regardless of the multi-sig threshold. Integrators who have forked or customized the Allowance Module for their own use cases inherit these vulnerability patterns and must conduct independent security review. Chainscore Labs provides targeted audit and verification services for teams that need to assess whether their deployed Allowance Modules contain known or novel logic flaws, and to implement monitoring that detects anomalous delegate spending patterns before a full drain occurs.

ALLOWANCE MODULE OVER-WITHDRAWAL VULNERABILITIES

Incident Snapshot

A structured breakdown of the root causes, affected components, exploit mechanics, and remediation steps for historical logic flaws in Safe Allowance Modules that enabled delegates to exceed spending limits.

Vulnerability Class	Root Cause	Affected Versions / Deployments	Exploit Impact	Remediation and Verification
Integer Overflow in Allowance Tracking	Unsafe arithmetic in spent-amount accumulation allowed a delegate to craft a series of transfers that overflow the tracker back to zero, resetting the allowance.	Custom Allowance Module deployments using Solidity <0.8.0 without SafeMath or explicit overflow checks.	Delegate can drain the full token balance of the Safe beyond the intended periodic limit, leading to total treasury loss.	Upgrade module to Solidity >=0.8.0 or integrate explicit overflow checks. Verify bytecode of deployed modules against patched versions.
Flawed Allowance Reset Logic	The module's reset function failed to properly zero out the spent amount or did not enforce a time delay, allowing a delegate to call reset and spend again within the same period.	Specific versions of community Allowance Modules and early Zodiac-compatible spending limit modules.	Delegate can repeatedly reset the allowance counter and execute multiple max-limit withdrawals within a single intended period.	Review the reset function's access controls and state transitions. Ensure reset either enforces a full period cooldown or is restricted to a higher-privilege role like the full multisig.
DELEGATECALL to Untrusted Address via Module	The Allowance Module used a low-level `delegatecall` to an address partially controlled by the delegate, allowing execution context manipulation to overwrite the allowance storage slot.	Custom modules that accept a target address as a parameter and execute via `delegatecall` without a strict allowlist.	Complete bypass of all spending limits. Attacker can execute arbitrary logic in the Safe's storage context, potentially changing owners or draining all assets.	Never use `delegatecall` to a user-supplied address in a module. Restrict execution to a hardcoded allowlist of trusted contracts. Audit all module execution paths for storage collision risks.
Signature Replay Across Chains for Module Delegates	The Allowance Module's EIP-712 domain separator omitted the chain ID, allowing a delegate's signed spending authorization to be replayed on another chain where the same Safe and module are deployed.	Allowance Modules deployed on pre-v1.3.0 Safe factories or modules that do not include `chainId` in their domain separator.	Delegate drains assets on a secondary chain where the Safe has a balance, using a signature intended only for the primary chain.	Verify the module's EIP-712 domain separator includes `chainId` and `verifyingContract`. For existing deployments, consider nonce-based replay protection or chain-specific module instances.
Missing `checkAfterExecution` Validation	The module performed allowance validation only in `checkTransaction` but failed to verify the final state in `checkAfterExecution`, allowing a reentrant or multi-call transaction to spend more than the limit.	Allowance Modules that do not implement the full `ITransactionGuard` interface or leave `checkAfterExecution` empty.	A malicious delegate can craft a transaction that appears compliant during pre-check but manipulates state mid-execution to exceed the allowance.	Implement a strict `checkAfterExecution` hook that re-verifies the total spent amount against the allowance. Ensure the module's state is updated before external calls to prevent reentrancy.
Unprotected Module Initialization	The Allowance Module's initializer function was left unprotected or used a predictable initializer signature, allowing a front-runner to initialize the module with malicious parameters during deployment.	Allowance Modules deployed via factory contracts without access-controlled or atomic initialization.	Attacker sets themselves as the delegate with an unlimited allowance before the legitimate deployment transaction is mined, gaining permanent spending authority.	Use a deployment pattern that atomically deploys and initializes the module in a single transaction. Implement access controls on the initializer or use a factory that enforces `msg.sender` checks.

technical-context

ALLOWANCE MODULE LOGIC FLAWS

Root Cause Patterns

The recurring logic errors that allow delegates to exceed spending limits in Safe Allowance Modules.

The root cause of over-withdrawal attacks in Safe Allowance Modules consistently traces back to a failure to correctly enforce the relationship between the spent counter and the allowance limit. In the most critical historical vulnerability, the module's executeAllowanceTransfer function performed an unsafe integer addition (spent + amount) without checking for overflow before comparing it to the allowance. An attacker could craft a transfer amount so large that the sum wrapped around to a small number, passing the allowance check and draining the module's entire token balance. This class of bug is not a Safe core contract issue but a module-specific logic flaw that treasury operators inherit when deploying unverified or outdated module versions.

A second, subtler pattern involves flawed reset logic. In some module implementations, the resetAllowance function failed to properly update the spent counter or allowed the delegate to influence the reset timing under adversarial conditions. When combined with the periodic nature of allowances, a delegate could front-run the reset transaction to spend the old allowance, then immediately spend the new allowance in the same block, effectively doubling their authorized limit. This timing-dependent attack vector is particularly dangerous for DAOs and treasury teams that automate allowance resets through bots or keeper networks without considering mempool visibility and execution ordering.

A third root cause pattern emerges from the misuse of DELEGATECALL within module logic. When an Allowance Module uses DELEGATECALL to invoke an arbitrary external contract, the execution context retains the module's storage permissions. An attacker who can influence the target address can force the module to overwrite its own allowance or spent storage slots, permanently disabling the spending limit. This pattern is not unique to Allowance Modules but is amplified by their role as a treasury gatekeeper. Integrators should verify that any Allowance Module they deploy restricts DELEGATECALL targets to a known, audited set of contracts and never allows user-supplied addresses in the execution path.

These root cause patterns share a common thread: they arise from the assumption that module logic is simple enough to be obviously correct. In practice, the interaction between integer arithmetic, periodic resets, and execution-context management creates edge cases that are easy to miss in manual review. Chainscore Labs recommends that any team operating an Allowance Module conduct a focused security review of the specific module version they have deployed, verify that overflow checks use SafeMath or Solidity 0.8+ built-in checks, audit the reset function for front-running susceptibility, and confirm that no DELEGATECALL path can reach an untrusted address. For teams that cannot confidently verify these properties, migrating to a formally verified Allowance Module or implementing off-chain monitoring of allowance consumption is a prudent interim control.

IMPACT SURFACE

Affected Systems and Actors

Treasury Operators

DAOs and on-chain organizations using the Allowance Module to delegate spending authority are the primary affected actors. A flawed module allows a delegate to drain funds beyond the intended allowance, turning a time-locked or rate-limited withdrawal right into an unbounded theft vector.

Immediate actions:

Audit all active Allowance Module deployments against the patched version list.
Revoke allowances for any delegate operating under a vulnerable module instance.
Re-deploy allowances using the fixed module version and re-issue delegate permissions.
Implement off-chain monitoring that alerts when cumulative withdrawals approach the allowance ceiling, not just when a single transaction exceeds it.

Chainscore Labs can perform a targeted review of your Allowance Module deployment, verify the delegate set, and confirm that reset logic and overflow protections are intact before funds are put at risk.

implementation-impact

ALLOWANCE MODULE RISK CONTROLS

Verification and Remediation Impact

Actionable verification steps and remediation patterns for treasury operators and integrators managing Safe Allowance Modules affected by integer overflow, reset logic flaws, or delegatecall misuse.

Verify Deployed Allowance Module Version

Audit every deployed Allowance Module against the patched canonical versions. Modules deployed before the fix may contain integer overflow vulnerabilities in the spending calculation or flawed reset logic that allows a delegate to spend more than the intended allowance. Check the module's bytecode hash against known-good versions on each chain. If the module is unverified or custom, treat it as potentially vulnerable until a bytecode-level review confirms otherwise.

Audit Delegatecall Paths in Module Logic

Allowance Modules that use delegatecall to execute token transfers or interact with external contracts introduce a risk of storage context confusion. A malicious delegate could craft a calldata payload that, when executed via delegatecall, manipulates the module's own allowance-tracking storage. Review all delegatecall targets to ensure they are immutable, trusted, and cannot be influenced by the delegate. Prefer direct calls over delegatecall for token transfer execution.

Implement Off-Chain Allowance Monitoring

Do not rely solely on on-chain allowance state. Deploy an off-chain monitoring service that tracks the cumulative spending of each delegate against their granted allowance, flags transactions that approach the limit, and alerts operators to anomalous spending patterns. This provides a defense-in-depth layer that can detect over-withdrawal attempts even if the module's on-chain logic is bypassed or manipulated through an unknown vulnerability.

Review Allowance Reset and Refill Logic

Flawed reset logic is a common root cause of over-withdrawal attacks. If the module resets the spent amount to zero on a new allowance grant without properly invalidating the previous delegate's authorization, a delegate can spend the old allowance and the new allowance in the same period. Verify that the module's reset function atomically revokes the old delegate and initializes the new allowance state in a single transaction, with no window for reentrancy or double-spend.

Conduct Periodic Module Security Reviews

Allowance Modules are not set-and-forget. Schedule periodic security reviews that re-verify the module's bytecode against the latest patched version, audit any new delegate grants for anomalous patterns, and test the module's behavior against edge cases such as maximum integer values, zero allowances, and rapid reset-and-spend sequences. Chainscore Labs can perform targeted reviews of deployed Allowance Modules to identify residual risk from known vulnerability classes.

Migrate to Canonical Allowance Module Versions

If a deployed Allowance Module is identified as vulnerable, plan an immediate migration to the latest canonical version. The migration should revoke all existing delegate authorizations on the old module, deploy the new module, and re-grant allowances only after verifying the new module's bytecode and initialization parameters. Coordinate with all delegates to ensure they understand the new module's interface and any behavioral changes before allowances are re-established.

ALLOWANCE MODULE FLAW EXPOSURE AND REMEDIATION

Risk and Compatibility Matrix

Evaluates the failure modes, affected actors, and required actions for teams operating or integrating Safe Allowance Modules that may contain integer overflow, flawed reset logic, or delegatecall misuse vulnerabilities.

Risk Area	Failure Mode	Severity	Affected Actors	Mitigation and Verification
Integer overflow in allowance tracking	Delegate spends amount that causes internal accounting to wrap, resetting the allowance to a maximum value and enabling unlimited withdrawals.	Critical	DAO treasuries, protocol-owned liquidity managers, delegate-spending operators	Verify module version against patched canonical releases. Audit on-chain delegate spending history for anomalous resets. Replace unpatched modules immediately.
Flawed allowance reset logic	Module fails to correctly zero out spent allowance after a transfer, allowing a delegate to repeatedly spend the same allowance within a single time window.	Critical	Treasury operators, institutional Safe users, delegate-based payroll systems	Review module logic for post-transfer state updates. Simulate multi-spend scenarios in a fork environment. Engage Chainscore for a targeted module logic review.
Unchecked delegatecall to user-supplied address	Module uses delegatecall to an arbitrary address supplied by the delegate, allowing execution of malicious code in the Safe's storage context and complete asset drainage.	Critical	Any Safe with a vulnerable Allowance Module enabled	Audit module for delegatecall usage. If present, verify that the target address is strictly constrained to a trusted, pre-approved list. Disable module until review is complete.
Missing chainId binding in module signatures	Module-generated signatures lack a chainId domain separator, making valid spending approvals on one chain replayable on another chain where the same Safe and module are deployed.	High	Multi-chain Safe deployments, cross-chain treasuries, bridge operators	Verify EIP-712 domain separator includes chainId and verifyingContract. For custom modules, audit signature construction. Assume replay risk on pre-1.3.0 Safes.
Incorrect time-window enforcement	Module allows spending outside the intended time window due to off-by-one errors or timestamp manipulation, enabling a delegate to drain funds before or after the authorized period.	High	Vesting contracts, grant disbursement Safes, time-locked treasury operations	Test module behavior at boundary timestamps. Verify that block.timestamp usage is safe against miner manipulation within the allowance window. Review time-logic with formal verification tools.
Unrestricted token approval scope	Module grants infinite token approval to itself or the delegate, creating a secondary attack surface where a compromised delegate key can drain all approved tokens even outside the module's intended logic.	High	Safes holding multiple ERC-20 tokens, DeFi protocol treasuries	Audit approval patterns in module setup. Prefer exact-amount approvals per transaction. Monitor for unexpected approve() calls originating from the module address.
Lack of spending cooldown or rate limiting	Module permits instantaneous repeated withdrawals with no per-block or per-epoch cap, amplifying the damage from a compromised delegate key before revocation is possible.	Medium	High-frequency spending operations, streaming payment systems	Implement on-chain rate limiting in custom modules. Use a circuit-breaker pattern with a separate guardian role. Monitor delegate spending velocity with off-chain alerting.
Unverified module upgradeability proxy	Allowance Module deployed behind an upgradeable proxy allows the module owner to change logic arbitrarily, potentially introducing a malicious implementation that bypasses all spending limits.	Medium	Safes using upgradeable Allowance Modules, DAO-managed treasuries	Verify proxy admin is a trusted governance contract or timelock. Monitor for implementation upgrade events. Prefer immutable module deployments for high-security treasuries.

ALLOWANCE MODULE SECURITY

Detection and Remediation Checklist

A structured checklist for treasury operators, security engineers, and integrators to detect whether deployed Allowance Modules contain known logic flaws and to remediate exposure to over-withdrawal attacks. Each item includes the specific signal to check, why it matters, and the artifact that confirms readiness.

What to check: The exact contract address and bytecode hash of every deployed Allowance Module against the canonical list of patched and vulnerable versions published by Safe and Zodiac.

Why it matters: Historical vulnerabilities involving integer overflow in allowance tracking, flawed reset logic, and delegatecall misuse were fixed in specific module versions. Deployments using unpatched versions remain directly exploitable by any delegate with an active allowance.

Confirmation signal: The deployed module's bytecode hash matches a known patched version, or a Chainscore Labs review confirms the custom module does not contain the vulnerable patterns. If the module is unpatched, immediately revoke all delegate allowances and redeploy with the fixed version.

resource-links

SAFE ALLOWANCE MODULE SECURITY

Canonical Resources

Use these resources to verify Allowance Module source code, deployed bytecode, Safe execution semantics, and disclosure channels before deciding whether a treasury or integration is exposed to over-withdrawal risk.

Safe Modules Repository

Start with the official Safe modules source when reviewing Allowance Module behavior. Security teams should compare the deployed module bytecode against the repository source, inspect arithmetic and reset logic around spending limits, and review any delegatecall or module-execution paths that can affect Safe storage or authorization. Do not rely on UI labels alone; confirm the exact implementation, compiler metadata, and commit or release lineage used by the deployed contract.

EXPLORE

Safe Smart Account Contracts

Allowance Module risk cannot be assessed in isolation from the Safe execution model. Review the Safe smart account contracts to understand module enablement, execTransactionFromModule behavior, guard interaction, fallback handler assumptions, and how module-originated transfers bypass the normal owner signature threshold. Operators should map the vulnerable module path to the Safe version they use and verify whether guards, policies, or monitoring actually cover module-triggered withdrawals.

EXPLORE

Safe Deployments Registry

Use the Safe deployments registry to distinguish canonical Safe infrastructure from custom or legacy deployments. For incident response, compare the Safe singleton, proxy factory, and related contract addresses against the registry for each chain. Allowance Modules may be deployed separately or by third parties, so the registry should be treated as a baseline for Safe core verification, not as proof that every enabled module on a treasury is safe.

EXPLORE

Safe Documentation

Safe documentation is the operational reference for how modules, guards, owners, thresholds, and transaction execution are expected to work. Use it to confirm the intended control plane before reviewing a suspected Allowance Module flaw: who can enable a module, how module transactions are executed, where module lists are surfaced, and which assumptions belong to Safe core versus third-party module logic. Teams should verify current behavior against the latest docs and deployed contracts.

EXPLORE

Safe Bug Bounty and Disclosure Channel

If a review finds a reproducible over-withdrawal path, unsafe reset condition, integer boundary issue, or delegatecall-based bypass in an Allowance Module, use the official disclosure channel rather than publishing exploit details. Include affected contract addresses, chain IDs, transaction traces, bytecode comparison, proof-of-concept conditions, and whether any live Safe accounts are at risk. Coordinated disclosure is especially important because Safe deployments often protect DAO treasuries, protocol reserves, and exchange operations.

EXPLORE

On-Chain Verification Checklist

For each Safe, enumerate enabled modules directly from on-chain state, identify delegates and allowance parameters, simulate maximum withdrawal paths, and check whether allowance resets can be triggered more often than intended. Risk teams should also review historical module transactions for withdrawals above policy limits, unusual delegate activity, and repeated reset or spend patterns. Where the module implementation is not verified or does not match a reviewed source, disable it through the Safe owner flow before re-enabling any replacement.

Chains We Build On

Looking to build on a specific blockchain?

We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.

Learn More

EVM ecosystems

Ethereum
Arbitrum
Optimism
Polygon
Avalanche
Cronos

Non-EVM ecosystems

Solana
Sui
Aptos
Hedera
Stellar
NEAR

Additional ecosystems

Polkadot
Cosmos
TON
Cardano
Algorand
Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

ALLOWANCE MODULE SECURITY FAQ

Frequently Asked Questions

Common questions from security engineers, treasury operators, and integrators about historical Allowance Module vulnerabilities, how to verify whether deployed modules are affected, and what operational controls reduce residual risk.

The two most critical historical vulnerability classes are:

Integer overflow in allowance tracking: In older module versions, arithmetic operations on the spent allowance could overflow, resetting the tracked total and allowing a delegate to spend far beyond the intended limit. This typically occurs when the module uses unchecked arithmetic or fails to use SafeMath patterns.
Flawed allowance reset logic: Some module implementations allowed the delegate or a third party to reset the spent counter to zero without proper authorization, effectively refreshing the allowance without owner consent. This often stems from incorrect access control on the reset function or a missing check that the allowance period has expired.
DELEGATECALL to untrusted addresses: If the module executes a DELEGATECALL to an address controllable by the delegate, the delegate can execute arbitrary code in the Safe's storage context, bypassing all allowance checks entirely.

Teams should verify the exact module version deployed against the Safe team's published security advisories and the module's audit history. If the module is custom or forked, a dedicated security review is essential.

Trusted by Industry Leaders

Delivering blockchain solutions for 5+ years.

We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.

Selected Partners & Clients

“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”

Lee Erswell

CEO, Telos Foundation

how to get started

How to get started?

If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Learn More

Explore More Solutions

Discover our
blockchain development services.

We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.

Book a Call

DeFi Protocol Development

End-to-end development of custom DeFi protocols including core smart contracts and system architecture.

DEX & Exchange Development

Building high-performance decentralized exchanges with optimized liquidity and advanced trading logic.

Lending & Borrowing Platforms

Scalable credit markets and money protocols built for production-grade liquidity and security.

Allowance Module Logic Flaws and Over-Withdrawal Attacks

Introduction

Incident Snapshot

Root Cause Patterns

Affected Systems and Actors

Treasury Operators