[BUG] NullClaw shared bearer A2A route allows cross-caller task and context reuse
I maintainer di solito rispondono entro 10 giorni
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 25/100
Direzione di ricerca
Start at the Gateway /a2a JSON-RPC route and trace how tasks/get, tasks/list, cancel, and message handling select task and context state. Run the attached reproduce.sh to observe the shared-bearer behavior and fresh-context negative control. Done means callers sharing a bearer cannot read another caller's task history or reuse their context session; an open pull request already addresses this issue.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
NullClaw protects /a2a with a bearer token, but later task and session authority is selected by bare task id and caller-supplied contextId. In the replay, Bob and Alice share a valid bearer. Bob reads and lists Alice task history, then reuses Alice context to receive prior downstream session state.
Affected Target Verified
- Repository:
https://github.com/nullclaw/nullclaw - Component: Gateway
/a2aJSON-RPC route - Affected commit verified:
9967eb9cacbf70e617602b6c36056ea67557614f - Vulnerability type: Task/history disclosure within a shared bearer boundary
Preconditions
- A bearer token is shared by multiple local users, tools, or peer callers.
- The A2A route is reachable to those callers.
- A task id or context id is known through task flow, logs, or enumeration.
Steps To Reproduce
From the attachment directory:
bash reproduce.sh
The script clones the target repository, checks out the verified commit, prepares a local test environment, and runs the bundled PoC. It does not contact attacker-controlled services; the setup only downloads the public repository and normal build dependencies.
To run against an existing checkout:
NULLCLAW_TARGET_DIR=/path/to/checkout bash reproduce.sh
The wrapper accepts NULLCLAW_TARGET_DIR for an existing checkout. It also accepts the target commit override documented in attachments/reproduce.sh.
Technical Details
The task registry is process-global. tasks/get, tasks/list, and cancel operate by task id/context filters without caller dimension. Message handling derives session_key = a2a:{contextId} from caller input.
Expected Behavior
If a bearer token is shared by multiple local users, tools, or peers, tasks and
context sessions should include a second caller/peer/session authority
dimension. Bare task ids and caller-supplied contextId values should not
select another caller's history.
Actual Behavior
- Bob
tasks/getandtasks/listexpose Alice secret-bearing history/artifacts. - Bob same-context
message/sendreceives Alice prior session content. - Fresh-context negative control stays isolated.
Impact
If the bearer is used as an app/gateway token shared by multiple local users,
tools, or peers, it becomes enough to read another caller's A2A task history and
join another caller's conversation state. The reproduced flow shows Bob reading
Alice's task artifacts/history and then reusing Alice's contextId to receive
prior downstream session content.
Task history can contain user prompts, model responses, artifacts, tool output,
and intermediate state. Context-session reuse can also affect future behavior:
Bob's later messages are processed as part of the same downstream conversation
instead of a fresh caller context.
If each bearer token is intended to represent exactly one end user or peer, the
route is effectively single-principal and that assumption should be documented
and enforced. Without that enforcement, a shared bearer boundary is too coarse
to protect task and context state between local callers.
Suggested Fix
If bearer tokens are shared at an app/gateway level, introduce a second caller/peer/session authority dimension for tasks and context sessions, or document the route as single-principal only.
Attachments
- Lingua principale
- Zig
- Stelle
- 8.1k
- Fork
- 945
- Merge medio
- 7g 6h
- PR unite (30g)
- 7
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di nullclaw/nullclaw
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
nullclaw/nullclaw#1078 · 2 commenti ·
I maintainer di solito rispondono entro 10 giorni
-
ci: gate Docker image changes on PRs and before release publishForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 10 giorni
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
nullclaw/nullclaw#993 · 1 commento ·
I maintainer di solito rispondono entro 10 giorni
-
Difficoltà 4/5 Più di una settimana Idoneità per principianti 12/100
I maintainer di solito rispondono entro 10 giorni
-
enhancement
Difficoltà 4/5 3-5 giorni Idoneità per principianti 28/100
nullclaw/nullclaw#1055 · 3 commenti ·
I maintainer di solito rispondono entro 10 giorni
Tutte le issue di nullclaw/nullclaw
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
cloudevents/sdk-go#1346 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
cyrusimap/cyrus-imapd#6640 ·
I maintainer di solito rispondono entro 2 giorni
-
GD decoder discards the finfo media type in mediaTypeByBinary() since 4.4.0Forse già presa @lazerg l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
Intervention/image#1556 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 60/100
I maintainer di solito rispondono entro 1 giorno