False sense of security: the whitelist security gaps your wallet doesn’t tell you about

Introduction

Whitelisting is one of the most common transaction security measures in digital asset operations. The premise is simple:

If you only approve known, trusted addresses and protocols, you reduce the risk of funds going somewhere they shouldn’t.

This seems logical. But it's a presumption based on incomplete context.

Static whitelisting rules often fail to account for how those approved protocols are being used, such as a seemingly valid call being manipulated to produce malicious outcomes. This creates exploitable policy blind spots that attackers can use to bypass supposed whitelist "safeguards".

In this post, we’ll break down 3 common whitelisting gaps we’ve observed in the field, show how they’re exploited in real-world scenarios, and explain how Blockaid’s Cosigner closes each gap through real-time transaction simulation and policy enforcement:

• Gap 1: Swap calldata exploits – Malicious addresses can be hidden deep in router calldata, slipping through “known-good” contract approvals.
• Gap 2: Bridge parameter manipulation – Even a whitelisted bridge can be abused if attackers substitute their own recipient address in the transfer parameters.
• Gap 3: Typed message exploits (EIP-712) – Blanket approval of typed messages gives scammers a path to sneak in unlimited token approvals disguised as benign signatures.

Whitelist Policy Gap #1 – Swap calldata exploits

Whitelisting a “known-good” router contract still leaves you exposed if malicious destinations are embedded deeper in the calldata, allowing attacks to pass policy checks while draining funds.

How it happens

Many institutional custody platforms recommend enabling swaps by whitelisting the Uniswap UniversalRouter contract and allowing all swap destinations. While this approach is widely considered safe, it can still leave room for attackers to exploit the calldata path—ultimately sending tokens to attacker-controlled addresses hidden in the transaction data.

Blind spot in action

A common best-practice recommendation is to whitelist a protocol address, such as Uniswap’s UniversalRouter, to enable swaps. Security admins will confidently configure this policy, trusting that it creates a safe environment. 

However, this trust is misplaced because encoded calldata is not human-readable. While the policy correctly whitelists the router contract (left), a malicious to parameter hidden deep within the transaction's calldata can easily conceal an attacker-controlled destination (right).

Because this malicious parameter is buried inside encoded data, a policy that only whitelists the router contract will approve this transaction. The security admin sees a valid interaction with Uniswap, but the actual outcome is a direct transfer to a malicious wallet.

This is what that attempted exploit looks like when detected:

This pattern is just one example of a broader set of risks that slip through “known-good” whitelisting approaches, including:

• Indirect transfers to malicious addresses – Sending assets indirectly to an attacker-controlled address through a router function.
• DeFi withdrawal on behalf of a malicious destination – Executing trades or liquidity withdrawals where proceeds are routed to a compromised or untrusted recipient.
• Takeover of a benign protocol which has been compromised — An attacker gains control of a protocol that was previously trusted, using it to push malicious upgrades or redirect funds to attacker-controlled addresses.

Whitelist Policy Gap #2: Bridge parameter manipulation

Whitelisting a “known-good” bridge still leaves you exposed if attackers can manipulate the destination address parameter allowing cross-chain transfers to pass policy while sending funds to an unauthorized recipient.

How it happens

Many organizations whitelist bridge contracts like Optimism’s Standard Bridge or aggregators like Jumper to allow cross-chain transfers. But these contracts include an arbitrary to parameter. An attacker can substitute their own address, and since the bridge contract itself is whitelisted, the transfer meets policy rules while funds are distributed to the attacker’s wallet.

Blind spot in action

Here is an example of the underlying logic of the Optimism bridge. We can see the to parameter, marking that the recipient parameter can be set to any address.

Let's look at a transfer on a bridge aggregator like Jumper. Everything appears normal—the bridge contract is whitelisted, the amount is correct. But the recipient address has been changed to a known malicious one.

A security layer that analyzes the transaction pre-signing would detect that the recipient address is known to be malicious, providing clear evidence of the manipulated parameter and blocking the transfer.

Whitelist Policy Gap #3: Malicious typed messages (EIP712 exploit)

Allowing typed message rules creates an opening for phishing scammers to sneak in malicious permits granting unlimited approvals.

How it happens

Typed messages are not simple function calls. They are offchain signatures that encode flexible, user-defined parameters. A blanket “allow typed messages” rule gives attackers space to hide malicious approvals inside legitimate-looking payloads.

This means even if all contracts, tokens, and counterparties are whitelisted, malicious typed message can bypass safeguards and cause major losses.

Blind spot in action

Policy setup: Many custody and treasury platforms allow teams to enable typed message approvals through a general rule in their UI. This setup provides flexibility, but also introduces risk if the encoded payload is not deeply validated.

In practice, when a user-facing wallet prompts requesting approval of a typed message that looks harmless, it could be encoding unlimited token approvals.

Analysis of the transaction's underlying data reveals its true malicious intent: it attempts to grant unlimited USDC spending rights to an attacker-controlled address, a request that would be flagged and blocked by security protocols designed to validate message parameters.

How Cosigner can help close the gap in all 3 cases

All three gaps share the same root problem: whitelisting checks who a transaction touches, but never verifies what the transaction actually does.

Cosigner closes that blind spot by simulating every transaction before execution, validating its real effects, and enforcing policies at the signing layer. Instead of relying on static approvals, it acts as an independent, security-aware signer that only co-signs transactions proven safe—blocking malicious payloads, hidden recipients, and disguised approvals before funds ever move.

With Cosigner, teams don’t just see a simulation—they gain deterministic enforcement. Every transaction is validated against organizational policies, such as:

• Matching the expected transaction signature
• Ensuring value stays within dollar limits
• Verifying events and parameters against approved rules

This guarantees that approvals align with both operational intent and security requirements—turning whitelisting from a static rule into a dynamic, enforceable safeguard.

Learn more here