Node Abuse Postmortem: From Open Access to a Whitelist Model
On October 19, 2026, the Stash Cloud Regtest environment saw two distinct kinds of abusive traffic within a single day: one source flooding the test-coin faucet while probing node endpoints through a simulated client, the other registering accounts and creating nodes in bulk. This post documents what we observed, the basis for our assessment, the measures we took, and the change it prompted in our admission policy for the open platform.
1. Overview
We identified two independent sources of abuse. Their behaviour, target endpoints, and our assessment differ:
| Source A | Source B | |
|---|---|---|
| Origin | 36.148.xx.xx (Hunan, Changsha, mainland China) | Three VPS subnets under Hong Kong AS38136 (Akari Networks) |
| Main behaviour | High-frequency faucet requests, simulated wallet client accessing node endpoints | Bulk account registration, bulk node creation |
| Target endpoints | /api/v1/faucet/claim, /v3/* | /v3/console/nodes |
| Assessment | Most likely an unintentional grey-hat test | Most likely a black-hat attack with a clear objective |
Both occurred on the same day, but we found no shared client fingerprint, IP, extension ID, or account evidence linking them, so we did not treat them as a single campaign.
2. Source A: Faucet Flooding and Client Simulation
2.1 Origin
The source IP prefix is 36.148.xx.xx, geolocated to Hunan, Changsha, mainland China.
2.2 Request pattern
Between 14:29:41 and 15:53:41 (UTC+8), this source issued 5,265 requests to /api/v1/faucet/claim, using a new BTC payout address for every request.
The endpoint lets users claim Regtest test coins from https://stashlabs.io/stash-wallet/. Rotating the payout address on every request indicates addresses generated in bulk by a script rather than a user clicking repeatedly.
2.3 Client simulation
From 14:43:37 to 15:53:41, this source used python-requests/2.34.2 to imitate the Stash Wallet client, operated four wallet nodes, called Stash Cloud v3 endpoints for login, queries, and transfers, and probed several non-existent endpoints such as /openapi.json.
2.4 Assessment
The client was built by imitating the open-source stash-wallet code, so we lean toward reading this as a grey-hat test without malicious intent — for example, an experimental script for automating operations across multiple wallets.
The source used a real residential broadband IP, the traffic imitated genuine client behaviour, and it caused no substantive impact on the platform. We decided not to pursue the matter further, restricting requests from that IP only while reserving all rights.
3. Source B: Bulk Registration and Bulk Node Creation
3.1 Origin
Primarily three VPS subnets under Hong Kong AS38136 (Akari Networks), with professional VPN tooling used to mask the real IP.
3.2 Method
Unlike Source A, this source did not simulate the Stash Wallet client. It called the Stash Cloud open platform endpoint /v3/console/nodes directly to create nodes.
The strategy was "one node per account plus unlimited free registration": per-account node count stayed at or below one, but registration itself had no admission barrier, so an automation script could keep registering new accounts and keep creating new nodes.
3.3 Root cause
This endpoint serves the Stash Cloud open platform (https://stashcloud.net/). Until then, the platform had no admission control at all: anyone could sign in with a wallet, register, and create and manage nodes. The capability was designed for small and mid-sized developers who would rather not operate nodes themselves, but without an admission barrier it also became a zero-cost path to acquiring resources.
3.4 Impact and assessment
The objective was to consume backend resources and inflate node operations costs.
Our services run on a Kubernetes cluster with elastic scaling and temporary capacity expansion. We monitored the environment throughout the attack and verified that normal users were unaffected; only after we deployed the security patch and upgraded the system did users report that the new security controls could misclassify legitimate requests.
Based on the attack path, we lean toward classifying this as a black-hat attack with a clear objective: Stash Cloud was not yet fully open, yet this source mounted the operation using only a subset of the open APIs and produced a large number of meaningless wallet nodes.
4. Response and Hardening
The Stash Labs security team has completed the patch and stopped the activity.
We tightened controls at two levels:
- Ingress: restrict requests from anomalous sources so a single source cannot keep consuming resources.
- Identity: re-evaluate how the open platform admits users, instead of assuming "registered means allowed".
5. Admission Policy: From Open Access to a Whitelist
This incident prompted us to revisit the pace of openness.
We will temporarily suspend fully open access to Stash Cloud and move to an invitation-based whitelist through partnerships. Developers can reach Stash Labs by direct message to obtain access to the open platform.
We still believe the RGB ecosystem needs a lower barrier to node operations — small teams should not be shut out of application development because they cannot afford to build infrastructure. But openness requires that access be observable, constrainable, and traceable. Once the whitelist model is running reliably and our admission and quota policies have been thoroughly validated, we will re-evaluate when to open up more broadly.
Closing
For any platform offering open APIs, being targeted by automation is a matter of when, not if. This incident made clear that security investment must keep pace with openness. We will continue strengthening anomaly detection and admission control, and restore broader access as those policies mature.