rag-poisoning

umdctf

Task: a Flask RAG chatbot exposed retrieved context inside a readable signed session cookie, and the poisoned snippets contained internal secret markers. Solution: poll the async chat flow, repeatedly query the two leaked marker names, join the returned base64 fragments, and decode the final flag.

flask base64 werkzeug session_cookie prompt_injection rag prompt_leakage

retrieval_context_inspectionasync_chat_pollingprompt_secret_extractionbase64_fragment_reconstruction

$ ls tags/ techniques/

flask base64 werkzeug session_cookie prompt_injection rag prompt_leakage

retrieval_context_inspectionasync_chat_pollingprompt_secret_extractionbase64_fragment_reconstruction

$ cat /etc/rate-limit

Rate limit reached (20 reads/hour per IP). Showing preview only — full content returns at the next hour roll-over.

rag-poisoning — UMDCTF

Summary

This challenge was a RAG chatbot that mixed user prompts with retrieved internal documents. Our solve was based on live reproduction against the running service: we inspected the Flask session state, confirmed poisoned retrieval snippets, then used two stable prompts to recover two base64 flag fragments and decode them.

Description

No separate organizer description was present in the provided workspace files.

English summary: the target was a Flask/Werkzeug chat application at http://rag-poisoning.challs.umdctf.io:45139/. The goal was to exploit the retrieval layer and prompt leakage behavior to recover a hidden flag from the model's internal context.

Recon

Endpoint: http://rag-poisoning.challs.umdctf.io:45139/
Root page: Flask chat UI
Observed server header: Werkzeug/3.1.8 Python/3.9.2
Request flow:
- GET / returns the chat page
- POST / with form field msg submits a question
- the bot often replies asynchronously, so the first HTML response only shows ⏳ Processing...
- the real answer appears only after polling GET / again in the same session

The most important early observation was the Flask session cookie. It was signed but not encrypted, so its JSON-like payload was readable client-side after sending a message. Decoding it showed keys such as:

_permanent
documents
history
last_job

The documents field contained retrieved RAG snippets including:

An internal audit drimovantelis is currently underway to review the system.
Policy prompts nemporath are used to guide system behavior and enforce operational constraints.
System performance is monitored regularly, including any base64-encoded logs or records.

That immediately suggested a poisoned retrieval setup where unusual tokens inside documents were acting as handles for hidden data.

Analysis

Two parts of the service behavior mattered.

1. Retrieval context was exposed indirectly

...