# Client-supplied identity trusted without proof

Server acts on identity, recipient, or author from client data without verifying ownership or matching the original request

_Area: Web business logic and race conditions. Seen in 3 disclosed reports; one confirmed bounty: $500; latest 2026-10-28. Updated 2026-11-01._

## How it works
A server or remote service supplies a value that names *who* or *where* — a recipient output script, a transaction in wallet history, the "author" of a document — and the client acts on it as if it were proven. The broken assumption is that the party reporting the identity is the party entitled to set it. When the reporter is untrusted (a malicious server, storage operator, or a contributor who can transfer ownership), the value can be swapped for one the attacker controls, and the client signs, pays, or warns on the attacker's behalf.

## Where it shows up
- Wallet or client code that takes output scripts, recipients, or transaction bodies from a remote service and feeds them to a signer [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-36f9-7rg5-cpf8.md).
- Light clients that display or act on server-supplied mempool/history data without checking input signatures [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-6jp4-8v48-cc5v.md).
- Fee-bump / RBF paths that re-sign a transaction already in history without re-checking its outputs [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-6jp4-8v48-cc5v.md).
- Permission or warning layers that parse a transaction but only read inputs and fee, never outputs [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-36f9-7rg5-cpf8.md).
- Security warnings that name an "author" or "owner" drawn from mutable metadata (ownership transfer, contributor roles) [E3](https://bugbountylibrary.com/r/blog%3Aehpus-com-post-author-spoofing-in-google-colaboratory.md).

## How to review
Find every field the signer or user-facing decision consumes, and trace it back to its source. The invariant: **any identity, recipient, or author value that drives a signature, payment, or trust warning must be compared against the caller's original request or an independently verified source before it is acted on.**
- For signing paths: does `buildSignableTransaction`-style code compare each non-change output's script to the caller's requested outputs? [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-36f9-7rg5-cpf8.md)
- For permission layers: does the manager inspect `tx.outputs`, not just inputs and fee? [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-36f9-7rg5-cpf8.md)
- For light clients: are server-supplied transactions validated (input signatures) before entering history or being re-signed? [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-6jp4-8v48-cc5v.md)
- For warnings: can the displayed identity be changed by the attacker (ownership transfer, role change)? [E3](https://bugbountylibrary.com/r/blog%3Aehpus-com-post-author-spoofing-in-google-colaboratory.md)

## How finders spotted it
- Code review of the signing path: noticed the lockingScript came from the storage response, and that the permission manager parsed the tx but used only inputs and fee, never outputs; confirmed with a storage server returning a substituted output [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-36f9-7rg5-cpf8.md).
- Victims noticed wallet history showed a different transaction after broadcast, that the original never propagated over p2p, and that the attacker address was ground to match the last four characters of the real one [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-6jp4-8v48-cc5v.md).
- Researcher asked who the "author" in the warning actually refers to, concluded it was the document owner, then noted Drive lets any contributor receive ownership [E3](https://bugbountylibrary.com/r/blog%3Aehpus-com-post-author-spoofing-in-google-colaboratory.md).

## Variants seen
- Remote storage operator substitutes recipient output scripts during transaction construction [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-36f9-7rg5-cpf8.md).
- Malicious server substitutes a conflicting mempool transaction that the user later re-signs on fee bump [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-6jp4-8v48-cc5v.md).
- Ownership transfer spoofs the author named in an execution warning [E3](https://bugbountylibrary.com/r/blog%3Aehpus-com-post-author-spoofing-in-google-colaboratory.md).

## Impact and severity
Redirected payments and signed-away funds in the wallet cases [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-6jp4-8v48-cc5v.md)[E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-36f9-7rg5-cpf8.md); user runs attacker code in the Colab case [E3](https://bugbountylibrary.com/r/blog%3Aehpus-com-post-author-spoofing-in-google-colaboratory.md). Impact rises when the trusted value feeds a signer directly (funds move without further checks) [E2](https://bugbountylibrary.com/r/ghsa%3AGHSA-36f9-7rg5-cpf8.md), and when a cosmetic detail (matching address prefix) defeats the user's own verification [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-6jp4-8v48-cc5v.md). Severity is high where the client is the last line of defense and performs no independent check.

## Evidence
- E1: https://bugbountylibrary.com/r/ghsa%3AGHSA-6jp4-8v48-cc5v.md
- E2: https://bugbountylibrary.com/r/ghsa%3AGHSA-36f9-7rg5-cpf8.md
- E3: https://bugbountylibrary.com/r/blog%3Aehpus-com-post-author-spoofing-in-google-colaboratory.md