SubQuery Network Security Incident: Full Disclosure and Recovery Plan

Mon Apr 13 2026

On April 12, 2026, three separate transactions exploited a vulnerability in the SubQuery Network’s Settings contract on the Base network, resulting in the unauthorized drainage of 359,614,732 SQT tokens. The exploit affected the Staking contract’s pooled SQT balances (TX1 and TX2) as well as 272 individual staker and delegator wallets (TX3).

No user private keys were compromised. The root cause was an internal smart-contract configuration issue that we have now fully resolved. We are committed to transparency, rapid recovery, and preventing recurrence. Below is a complete, factual account based on our on-chain investigation (including full Tenderly traces).

Root Cause

The vulnerability was a missing onlyOwner access control modifier on the setContractAddress() function (selector 0xc413e5be) in the Settings contract implementation.

This function allows any caller to update the registered addresses for critical roles in the SQContracts enum (including StakingManager = sq=2 and RewardsDistributor = sq=8). The absence of the modifier meant the function could be called permissionlessly, bypassing the intended owner-only protection that existed elsewhere in the system.

The vulnerability has been present since the contract was deployed and was not introduced by any recent change. We have since added the onlyOwner modifier to both setContractAddress() and the related setBatchAddress() function.

Exact Contracts Affected

Settings contract (implementation): The contract containing setContractAddress().
Staking contract (TransparentUpgradeableProxy at 0x7A68b10Eb116a8b71a9b6f77b32b47eb591B6Ded): The contract that held all staked and delegated SQT. Its implementation is at 0xf6c913c506881d7eb37ce52af4dc8e59fd61694d.
SQT token contract: Used for transfers and approvals (victims had pre-existing MAX_UINT approvals to the Staking proxy).

No other contracts were modified or exploited.

Attack Path (Step-by-Step)

All three attacks used the same missing access-control gap but employed slightly different delivery mechanisms. The core path was:

Attacker calls setContractAddress(sq=2, attacker-controlled-address) to register themselves (or a temporary contract) as the StakingManager.
This unlocks two key functions in the Staking contract:
- transferDelegationTokens(address _source, uint256 _amount) – moves SQT from any address that has approved the Staking proxy.
- withdrawARequest(address _source, uint256 _index) – executes withdrawals.
Attacker also calls setContractAddress(sq=8, attacker-controlled-address) to register as RewardsDistributor.
Using RewardsDistributor privileges, the attacker calls unbondCommission() to create a Commission-type unbonding request (bypassing normal delegation checks).
The attacker then calls withdrawARequest() (still as StakingManager) to drain the accumulated SQT from the Staking contract, minus the standard 0.1% treasury fee.
After drainage, the attacker restores the original StakingManager and RewardsDistributor addresses to cover tracks.

TX1 & TX2 (pooled balance drain, ~230M SQT total) used temporary contract creation + selfdestruct.

TX3 (individual wallets, 129,494,294 SQT) used EIP-7702 code morphing on an address the attacker had owned for ~1.5 years. No phishing or key compromise occurred – the attacker self-authorized the morph.

Timeline of Events

April 12, 2026 05:04 UTC: TX1 drains ~218M SQT from the pooled Staking balance.
April 12, 2026 05:28 UTC: TX2 drains ~11.8M SQT from the pooled Staking balance.
April 12, 2026 06:51 UTC: TX3 drains 129.5M SQT from 272 individual wallets into the now-empty Staking contract and withdraws the full amount.
April 12–13, 2026: SubQuery team identifies the incident, simulates the full attack trace, restores original contract addresses, and deploys the fix (adding onlyOwner modifiers).

Audit History

The SubQuery ecosystem underwent two security audits:

First audit: April 2022 – The settings contract was included in this audit and found to be secure at the time.
Second audit: February 2024 – This was a targeted audit focused on specific components. The settings contract was not within scope.

The vulnerability was inadvertently introduced during a code refactor after the first audit. The second audit was scoped to other components and did not re-examine the settings contract.

We are now conducting a full review of all contracts to ensure no similar gaps exist.

Fixes Implemented

Added onlyOwner modifier to setContractAddress() and setBatchAddress() in the Settings contract.
Restored original StakingManager and RewardsDistributor addresses immediately after the incident.
Deployed the patched Settings implementation via the existing proxy admin.
The patched contract is now live and has been verified on BaseScan.

Preventative Measures Going Forward

The root cause of the vulnerability has been fixed. In addition, several other mitigations are being implemented to prevent similar issues in the future.

The following fixes are already planned or in progress:

Fix	Why
Add lock period check in withdrawARequest	Blocks same-transaction create + drain entirely
Require non-zero delegation in unbondCommission	The attacker's worker had zero stake history

Beyond these immediate code-level fixes, we have also performed an additional security scan using AI to identify potential vulnerabilities that traditional audits might miss.

Compensation & Recovery Plan

We are making whole every affected user. No staker or delegator will bear any loss from this incident.

Who is eligible: All stakers and delegators whose SQT was held in the Staking contract (pooled balances drained in TX1/TX2) and the 272 individual wallets directly drained in TX3. Full victim list and amounts are available internally from the on-chain data.
How compensation works: Automatic on-chain credit to affected wallets.
Timeline for refunds: Compensation distribution will begin on 14 Apr and complete no later than 15 Apr.
When functionality resumes: Withdrawals and normal Staking operations will resume once compensation distribution is complete and we have confirmed network stability.

Closing Statement

This incident is very unfortunate and we apologize to every member of the SubQuery community whose trust was impacted. We have acted swiftly to contain the exploit, restore the affected contracts, and prepare full compensation.

We will continue to provide regular updates via our official channels. Thank you for your patience and continued support.

— The SubQuery Team

About SubQuery

SubQuery is building the foundational data layer of Web3 — open, scalable, and designed for the AI-driven future.

SubQuery Network provides decentralised data indexers and dRPCs that power thousands of dApps across nearly 300 networks. With AI-assisted tools in the SubQuery SDK and Model Context Protocol (MCP) integration, developers can easily build, deploy, and scale blockchain data infrastructure.

AskSubQuery.xyz provides graphql query MCP as a service. It is also the first product to connect to Hermes Subnet as an Authorized Caller.

With SubQuery, you can unlock intelligence in blockchain data.