Sign in Subscribe
Featured

BlockThreat - Week 5, 2026

Step Finance, CrossCurve Bridge, Gyroscope Bridge, XPlayer, PGNLZ, Revert Finance, Holdstation, dYdX, USMS, Lick, Address Poisoning

Peter Kacherginsky

• 8 min read
BlockThreat - Week 5, 2026

About $30M was stolen this week across eight incidents. Two bridges were exploited in the same week using very similar attack vectors. The CrossCurve hack drew most of the attention with roughly $2.76M in losses and a wave of copycat attacks across nine different chains. The Gyroscope bridge hack, however, is even more concerning. The underlying vulnerability had the potential to enable far more devastating attacks, making it worth a closer look at the exact root cause and, more importantly, what not to do when designing cross chain messaging.

On January 31, 2026, Gyroscope disclosed that its cross chain contract had been exploited. Within minutes, the Ethereum bridge began transferring roughly $7M worth of GYD to an attacker controlled address.

The key clue to the root cause appears in what initially looks like a benign transaction on January 30, 2026 at 20:27:59 UTC. This transaction transfers a tiny amount of GYD to the GYD token contract itself. At first glance, nothing seems out of the ordinary. However, a closer inspection reveals a concerning event.

What looked like an innocuous transfer concealed a malicious payload that granted an infinite token approval to address 0x7dd407. With this approval in place, the attacker was then able to drain the bridge.

The transaction in question originated as a routine cross chain transfer from Arbitrum. So how did the attacker manage to coerce the bridge into executing an unlimited approval on the GYD token? To answer that, we need to examine the Arbitrum side transaction that preceded the Ethereum transfer.

At a high level, the call appears to be a standard bridgeToken invocation. But inspecting the payload reveals the real problem. The recipient on Ethereum is set to 0xe07f9d, which is the GYD token contract itself!

More importantly, the data field contains a carefully crafted calldata payload:

% cast 4byte-calldata 0x095ea7b30000000000000000000000007dd4075a6eae9f18309f112364f0394c2dfa8102ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
1) "approve(address,uint256)"
0x7DD4075A6eAe9f18309F112364f0394C2DfA8102
115792089237316195423570985008687907853269984665640564039457584007913129639935 [1.157e77]

This is a direct call to approve(address,uint256) with the maximum possible allowance. Because the bridge performed no validation on either the target contract or the calldata, it blindly forwarded this payload to the GYD token contract. The result was an infinite approval granted to the attacker address.

The underlying issue becomes obvious when looking at the bridge implementation on the Arbitrum end. The bridgeToken function accepts an arbitrary recipient and arbitrary data, and forwards both as part of the CCIP message without any verification of what is being called or why:

function bridgeToken(
  uint64 destinationChainSelector,
  address recipient,
  uint256 amount,
  bytes memory data
) public payable virtual {
  ChainMetadata memory metadata = chainsMetadata[destinationChainSelector];
  if (metadata.targetAddress == address(0)) {
    revert ChainNotSupported(destinationChainSelector);
  }

  _burn(msg.sender, amount);
  Client.EVM2AnyMessage memory evm2AnyMessage = CCIPHelpers.buildCCIPMessage(
    metadata.targetAddress, recipient, amount, data, metadata.gasLimit
  );

The same issue exists on the receiving side in ccipReceive(), which performs no validation to prevent dangerous calls. Due to the bridge’s trust relationship with the token contract, it was able to invoke the privileged approve function.

💡
If your bridge or messaging layer can execute arbitrary calldata, you must strictly constrain the allowed targets and function selectors. Otherwise, a simple bridge transaction quietly becomes a remote code execution primitive.

The attacker quickly drained approximately $7M in tokens and appears to have gotten away with around 300 ETH in liqudity. Far more troubling is that the same arbitrary call injection could have been weaponized against users, leading to significantly broader ecosystem losses. We must do better!

In other news, there was yet another mass compromise event by someone hunting for vulnerable contracts with burn pools on BSC. PGNLZ and XPlayer were hit so far, but likely more contracts will surface.

Supply chain attacks also continued. Both PyPI and NPM packages for dydx-v4-clients were recently backdoored. Please check if you downloaded PyPI (version 1.1.5.post1) and NPM (versions 3.4.1, 1.22.1, 1.15.2, 1.0.31) immediately!

Let’s dive into the news!

Events

News

Crime

Phishing

Scams

Malware

Media

Contests

Research

Tools

  • The Solodit API is now live. Get instant access to 50,000 smart contract vulnerabilities.
  • Introducing WhoDis a Chrome extension that lets you impersonate any Ethereum address.
  • Assertions by BlossomLabs. On-chain assertions for securing DAO proposals and Safe transactions. Verify invariants atomically.

Hacks