Unauthenticated GraphQL Endpoint Leaks Emails, IP-to-Wallet Mappings, Push Tokens, and Support Messages
The Risk
Anyone on the internet could read the wallet provider's internal user database with a single web request, no login, no key, no token. The exposed data tied real email addresses, home network locations, device identifiers, and private support messages to specific blockchain wallets. Around 250,000 wallet-to-network-location records and 80,000 push notification handles were exposed, which is the equivalent of leaving the company's customer database open to the public internet with the front door removed.
The Vulnerability
The wallet provider's backend exposed a GraphQL data layer at a public endpoint. The anonymous role on that data layer had unrestricted read access to production tables containing user identity, device, and support data. There was no authentication required, no row-level filtering, and the endpoint also had introspection and real-time subscriptions enabled for unauthenticated callers.
In practice this meant any HTTP client could:
- List the entire database schema by introspection
- Query user-facing tables directly by name
- Walk records sequentially by primary key, since direct lookups by integer ID were allowed
- Open a long-lived subscription and watch new user registrations and device claims happen in real time
The Attack
Pulling user identity
A single unauthenticated query against the support feedback table returned real customer email addresses, the wallet addresses tied to those emails, and the body of every private support message users had submitted. Many of those messages contained sensitive context such as complaints about lost funds, stuck transactions, and screenshots of wallet balances attached as base64 images.
Deanonymizing blockchain users at scale
A wallet claims table mapped each on-chain wallet address to the IP address that registered it and to a unique device fingerprint. The full table held roughly 250,000 records. Anyone could pull batches of these records and link a pseudonymous on-chain identity to a real-world network location and a specific physical device. IP addresses are personal data under GDPR, so this alone is a regulated breach.
Push notification token harvest
The device configuration table exposed roughly 80,000 push notification tokens, the per-install identifiers used to route push messages to specific user devices. These tokens are never meant to be public. Combined with the project's separately reported hardcoded push signing key, an attacker could send arbitrary push notifications to those 80,000 devices.
Other exposed surface
- 40+ database tables including app config, campaign data, token lists, and dApp listings
- Active third-party API keys for blockchain explorers, stored in a network configuration table
- Internal infrastructure URLs for the bundler, paymaster, email service, and subgraph
- Full bridge architecture mapping cashier contracts, token-safe contracts, and router contracts
- Real-time subscription endpoints for persistent surveillance of new user activity
- Direct primary-key lookup, allowing sequential enumeration of all wallet records by incrementing an integer ID
The Impact
| Data exposed | Approximate scale |
|---|---|
| User emails tied to wallet addresses and support messages | 42 records sampled, more behind the same query |
| Wallet-to-IP-and-device mappings | ~250,000 records |
| Push notification tokens | ~80,000 records |
| Wallet info table accessible by primary key | ~109,000 records |
| Active third-party API keys | 2 confirmed in production use |
| Internal service URLs | Bundler, paymaster, email, subgraph endpoints |
Any of these on its own is a serious incident. Combined, they let an attacker take the public, pseudonymous list of on-chain addresses and tie each address to a real email, an IP, a device, and a push channel. That undermines the privacy assumption every blockchain user makes, and it does so without any compromise of a user device or account.
Remediation
- Require authentication on the GraphQL endpoint and deny anonymous access by default
- Revoke all read permissions from the anonymous role on tables containing user data
- Disable schema introspection and real-time subscriptions for unauthenticated callers
- Apply row-level authorization on every table that holds personal information
- Rotate the leaked third-party API keys and rotate or invalidate the exposed push notification tokens
- Notify affected users, since the IP and email exposure is a regulated breach in multiple jurisdictions