NahamSec chains two innocuous chatbot tools into a full PII exfiltration, then scales it from a self-only party trick into an interaction-free attack on other users by poisoning a shared knowledge base. The bug earned a $3,000 valuation but was duplicated by a hunter five days ahead of him.
Indirect prompt injection as a tool-chaining exfiltration primitive
The vulnerability class here is not a novel LLM jailbreak but a classic exfiltration chain expressed through AI tooling.
The target chatbot exposed two capabilities that were each legitimate in isolation: it could read sensitive user data (full name, phone, email, address, recent orders) that the attacker’s own account had no right to see through the normal UI, and it had a fetch_url tool built to make outbound requests to external URLs for calling APIs.
The exploit is combining them, using the fetch tool as an egress channel to carry the sensitive data off-platform.
This mirrors the older web-app exfil pattern (read a secret, then smuggle it out over an attacker-controlled request), except the “confused deputy” executing both steps is the AI agent acting with the victim’s privileges.
The broader lesson is that AI features sit on top of existing data that does not become safer for having an LLM in front of it; if anything it worsens, because the new component can read sensitive data and take actions on the user’s behalf, and almost nobody has tested what happens when its input is manipulated.
Reconnaissance: mapping what the agent can see and do
Discovery started by interrogating the agent about its own attack surface rather than the surrounding app.
The first prompts simply asked what tools it had access to and what data it could reach; because vendors want these assistants to be helpful and demonstrate their integrations, the agent often volunteers its tool list, though sometimes it must be teased out with varied prompts.
In the companion ShopMate lab, that enumeration surfaced three tools: search_KB (queries the help center), customer_get_info (returns the PII fields), and fetch_url.
A second recon axis was probing rendering behavior by asking the agent to emit markdown links, markdown images, and raw HTML injection payloads; if any of that renders, it signals a strong exfil lead.
The attacker also mapped the fetch tool’s boundaries by asking for example usage and firing test requests, learning that the tool would call in-scope-looking domains and return the full HTTP response (e.g. a Squarespace 404 body from a real personal domain) while rejecting URLs outside its allowlist.
Defeating markdown blocking and domain allowlists
Two mitigations stood in the way, and both were bypassable.
First, many chatbots deliberately do not render markdown as a security control, which kills the classic image-URL exfil where you embed stolen data in an <img> src and let the client render it.
The bypass, credited to a prior operation, is that a domain-connectivity or outbound-fetch tool does not need markdown at all: you place the stolen data directly inside the URL the tool requests, as a subdomain or a query parameter.
The described payload used the PII as a DNS label, roughly <victim-PII>.<callback-server>.com, so the data leaves the moment the request resolves, even to a listener like interact.sh.
Second, obvious out-of-band domains such as interact.sh are frequently blocked outright, which stalled the author for a while; the fix was simply spinning up another subdomain under his own domain that the allowlist had no reason to reject.
Tested end to end, this reliably exfiltrated arbitrary readable data to an attacker-controlled server.
Scaling from self-exfil to a zero-interaction watering hole
Exfiltrating your own data proves the mechanism but is not a reportable bug; it is a party trick because the attacker is only attacking themselves.
The impact multiplier is a watering-hole delivery: find a resource the agent already trusts and reads from automatically, and plant the prompt injection there so any user whose chat references it gets hijacked with no malicious input on their part.
Here that resource was the shared knowledge base / help center; the attacker edited a return-policy article to embed instructions telling the agent to pull the current user’s PII and send it through fetch_url to the callback server.
When Alice (and then a separate user, Bob) innocently asked “how do I return something?”, the agent consulted the poisoned article and quietly exfiltrated each user’s own name, email, phone, and address to interact.sh.
Notably the write access came from a lower-privileged account that could edit the knowledge base without full admin rights, which layers a broken-authorization / privilege-escalation flaw underneath the injection; an even stronger variant would chain an IDOR or write-permission bug to poison content the attacker shouldn’t be able to touch at all.
Key takeaways
- Do not skip AI features on bug bounty targets; they read sensitive data and take actions, and are usually untested against hostile input.
- Enumerate the agent’s tools and reachable data by asking it directly, then probe markdown and HTML rendering to gauge exfil potential.
- Any outbound-request tool is an exfil channel even with markdown disabled: encode stolen data in the URL as a subdomain or query parameter.
- When a callback domain like interact.sh is blocked, rotate to a fresh subdomain of your own to slip past the allowlist.
- Turn self-only exfil into real impact via a watering hole: poison a trusted, auto-referenced source (knowledge base) so other users are hit with zero interaction.
- Weak write authorization on shared content (editing the KB as a low-privileged user) compounds the injection into a privilege-escalation chain.
Sources
- Watch the video: youtube.com/watch?v=Q6hQlM6f6Cs
- Full transcript: first-3000-ai-vulnerability
- Related: hacking-ai-chatbot-over-dns, ai-recon-500-bug