The decentralized physical infrastructure network io.net, built on Solana and designed to aggregate underutilized GPU resources for AI and machine learning workloads, disclosed a significant security incident on April 25, 2024, that exposed critical vulnerabilities in its API architecture. The attack, which came just days before the highly anticipated launch of the platform’s native $IO token on April 28, highlights the growing security challenges facing DePIN protocols as they scale to meet surging demand for decentralized computing power.
The Exploit Mechanics
The incident began when malicious actors exploited a chain of vulnerabilities across multiple io.net APIs. The primary attack vector involved the IO Explorer API, which accidentally exposed user IDs when searching by device IDs. Attackers harvested this data weeks before the incident, compiling a database of user IDs and device IDs to identify which users controlled the largest GPU deployments — information valuable for gaming the upcoming $IO token airdrop.
Armed with this harvested data, the attackers discovered that the worker-api — used by routine cron jobs running on GPU worker nodes — could update any device metadata if the attacker passed the legitimate owner’s user ID in the request header. Crucially, this API endpoint required no user-level authentication beyond the user ID itself. The vulnerability was compounded by the fact that io.net’s system used a universal authentication token that was identical across all recognized GPUs, meaning any authenticated device could potentially manipulate another user’s metadata.
The attackers altered device names, statuses, and other metadata belonging to legitimate users. While they could not access the underlying GPU hardware or compute resources — which remained protected by multiple permission layers — the visual changes on the platform’s frontend caused significant confusion and concern within the community, with users seeing their devices appear to change status or ownership without their action.
Affected Systems
The attack primarily affected io.net’s device metadata systems and the IO Explorer frontend. The platform’s core compute infrastructure remained secure, meaning no actual GPU workloads were compromised and no user data beyond device metadata was exposed. However, the timing was particularly damaging — io.net had just introduced a Proof of Work mechanism on April 23, 26 hours before the attack, specifically to identify and block counterfeit GPUs from the network.
This anti-spoofing measure triggered the attack escalation. When the Proof of Work system blocked some of the attackers’ spoofed GPU accounts, they retaliated by using the harvested user data to vandalize legitimate users’ device metadata. The incident affected users across the platform’s global network, which at the time was aggregating GPU resources from data centers, mining operations, and private clusters across dozens of countries, with Bitcoin trading around $63,100 and the broader crypto market capitalization exceeding $2.4 trillion.
The Mitigation Strategy
io.net’s response was swift once the anomaly was detected. At 1:05 AM PST on April 25, automated alerts flagged an unusually high rate of write operations to the GPU metadata API. The development team was contacted by 1:16 AM and began investigating immediately. Within 10 minutes, remedial actions commenced, including blocking the originating IP addresses.
However, the attackers circumvented IP blocking by rotating through multiple addresses while continuing to leverage their harvested database of user IDs and device IDs. In response, io.net temporarily halted all metadata update capabilities — preventing users from changing hostnames and other device information — while implementing a permanent fix. The team accelerated the rollout of user-specific authentication through Auth0 with OKTA integration, completing in hours what had been planned for the platform’s Token Generation Event launch. This eliminated the vulnerability associated with the universal authorization token by ensuring each user had a unique, properly scoped authentication credential.
Lessons Learned
The io.net incident reveals several critical security lessons for the rapidly growing DePIN sector. First, API ecosystems must be audited holistically — the vulnerability chain involved three separate APIs, none of which was individually catastrophic but which combined to create a significant exploit path. The IO Explorer API’s data leakage, the worker-api’s weak authentication, and the universal token system each represented a link in the attack chain.
Second, token launches and airdrop events create powerful incentives for malicious actors to probe vulnerabilities. The attackers’ primary motivation was identifying users with the largest GPU deployments to gain advantage in the $IO token distribution, and their attack escalated when anti-spoofing measures threatened their schemes. Projects planning token generation events should assume increased attack activity in the weeks preceding launch.
Third, the incident underscores the importance of rapid incident response capabilities. io.net’s monitoring systems detected the anomaly within minutes, and the team’s decision to temporarily disable metadata updates — while disruptive — prevented further damage while a permanent fix was deployed.
User Action Required
For io.net users, the platform has recommended verifying that all device metadata is accurate following the incident remediation. Users should confirm their device names, statuses, and configurations have not been altered. The new Auth0-based authentication system requires all users to re-authenticate, and the platform has encouraged enabling additional security measures where available. Users who notice any discrepancies in their device listings should contact io.net support immediately. The $IO token launch proceeded as scheduled on April 28, with the team confirming the incident would not affect token distribution or the Ignition rewards program for early GPU suppliers.
Disclaimer: This article is for informational purposes only and does not constitute financial advice. Always conduct your own research before engaging with any cryptocurrency platform or token.
harvesting device IDs weeks before the token launch and nobody noticed? this is why i dont touch anything with airdrop in the roadmap
the IO token still launched on schedule after this. tells you everything about where priorities are in DePIN
launched AND pumped. users got rekt and the token did a 3x. incentives are completely broken in this space
The worker-api accepting requests without auth is genuinely embarrassing for a project that raised that much. You would think basic API security would be step one.
right? and they had multiple APIs all with different auth levels. classic case of shipping fast and ignoring security until it blows up
shipping days before token launch with zero auth on a worker API is not a bug its a culture problem. speed over security until it costs users
speed over security is the entire DePIN playbook right now. render, akash, io.net all rushing to ship before competitors
using harvested device IDs to game an airdrop is next level parasitic. the attacker basically did their own sybil attack on the reward system