ChatGPT Served the Malicious Link. The Stack Trace Shows Who Signed.

On June 12, at roughly 19:00 UTC, an attacker-controlled contract executed transferFrom on the Flare network and moved 1,904,513 FXRP out of a user's wallet. That is about 1.3% of all circulating FXRP. At the time, the position was worth close to $2.1 million. The same receiving infrastructure had quietly absorbed over $2.2 million across at least four different Flare ecosystem tokens dating back to April. The victim, Alex, did not visit a suspicious site he found on Telegram. He did not click a sponsored ad on a search engine. Alex asked ChatGPT, in Russian, how to convert sFLR into wrapped FLR. The AI answered with a link. He connected his wallet. He signed an unlimited approval. The money did the rest. The stack trace doesn't lie. This was not an exploit of the Flare consensus layer. It was not a vulnerability in the FXRP bridge contract. It was a textbook approval phishing campaign that found a new distribution channel: an AI recommendation engine that users treat as neutral infrastructure. And because the attack is still being framed as "another phishing victim," the actual structural problem is being missed. Context: The Protocol and the Prey FXRP is XRP bridged onto Flare for use inside DeFi. sFLR is the liquid staking derivative of Flare's native token. Alex's transaction intent was benign and routine: unwrap his staked position into a liquid form. His choice of tool, however, introduced a fatal trust assumption. He asked an AI chatbot to research the correct application. ChatGPT returned a link to sceptre.network. The legitimate liquid staking protocol is sceptre.fi. Same name. Different top-level domain. High-entropy phishing is built on exactly this kind of small, readable difference. The fake domain was not a new deployment. On-chain sleuth Val traced the receiving wallet's history, and its first funds arrived on April 23. That was fully 50 days before Alex ever signed an approval. The wallet continued to collect a range of Flare-based tokens, confirming that Alex was likely not the first victim and probably not the last. Independent researcher Nightingale corroborated the timeline. Meanwhile, BeInCrypto had already documented the same general playbook earlier in the year: drainer tooling registered lookalike Uniswap domains and purchased search ads to poison results. The only novelty here is the recommender. Core: Dissecting the Failure Chain Let me walk through the failure stack the way I would walk through an audit finding, layer by layer. Layer one: the AI output pollution vector. In my 2026 audit of an AI-driven trading protocol, I found that the sharpest risks were not in the model itself but in the data pipeline feeding it. Relying on AI output without independent verification of its sources is a trust violation waiting to happen. The ChatGPT case is a textbook variant of that pattern. The attacker likely polluted the sources a retrieval-augmented model pulls from, using SEO manipulation and planted content. The AI does not need to be hacked. It simply repeats what it has been given. Users then treat the repeated output as a personal recommendation. That is indirect prompt injection applied pragmatically: you do not need to control the model if you can control what the model reads. The technical community keeps calling this "AI-assisted phishing." It is not. AI-assisted phishing would mean the attacker used AI to write the lure. This is AI-distributed phishing. The AI was the delivery rail. The model did not have a malicious intent, and it did not need one. The intent lived inside the poisoned webpage that the model, with full confidence, handed back. Layer two: unlimited approval as the force multiplier. No part of this attack works without the user signing an unbounded approval. EVM-compatible chains have carried this weakness since the beginning. An allowance is a standing instruction, and an unlimited allowance is a standing instruction to hand over the entire balance, anytime, with no further confirmation. The attacker's contract triggered the extraction seconds-to-minutes after the signature was finally used, but the approval was already valid the moment it hit the mempool. We have seen this mechanism drain a single Ethereum holder of $999,999. We have seen it deployed across scams. What we have not done is remove it from the default user experience. Alex never moved his own tokens. The stack trace makes that unambiguous. The attacker's contract called transferFrom with an authorization that Alex had signed while believing he was approving a legitimate DeFi interaction. The signature was not a mistake in the technical sense. It was exactly what the user was asked to do. The design, however, gave the user no meaningful way to limit the scope or duration of that permission. That is not user error. That is a system design failure that the industry has chosen to outsource to user vigilance. Layer three: persistent infrastructure, not a one-off heist. The receiving wallet was funded in April. It collected multiple token types. The domain sceptre.network stayed live and responsive long enough to influence a model's output, then to greet the victim. This behavior indicates a commercially operated drainer setup, not an opportunistic hacker. The perpetrators ran a business. They built a domain portfolio. They tested distribution channels. They monetized across chains. The funding patterns I traced during post-FTX forensic work showed the same signature: infrastructure that pre-exists the victim by weeks, receives quietly, and consolidates only when necessary. A single victim story tends to make the news as a misfortune. Multiple wallets receiving multiple tokens from a single pre-funded address makes it an industrial operation. The phrase "community-driven" is used loosely across crypto, but phishing infrastructure is genuinely community-driven in the worst sense: one shared toolkit, many operators. This points to a structural ecosystem risk, not an individual lapse. Layer four: the detection gap. Traditional phishing can be mitigated with domain blacklists and browser warnings. AI output cannot be blacklisted in real time. The model generates a fresh answer per session. It hallucinates a URL, or it faithfully quotes a poisoned one, and there is no validation layer between the conversational response and the user's verdict to sign. Even well-trained users do not expect their research assistant to be an attack vector. This detection gap is systemic and currently unaddressed by the major AI providers. The Contrarian View: What the Bulls Got Right It is worth saying plainly what this incident was not. The attack technique contains no new code exploit. The Flare bridge contracts were not compromised. The sFLR unwrapping logic was not broken. Flare's token economics were not the problem, and the FXRP supply impact, at 1.3%, is small enough that market price effects will remain muted unless the attacker deliberately dumps. In that narrow sense, the techno-optimists are correct: the protocol worked exactly as designed. And that is precisely why this case deserves more scrutiny, not less. The protocol worked as designed, and the user still lost everything. The AI responded as designed, and the response was still malicious. The approval mechanism worked as designed, and the outcome was still irreversible. When failure requires no component to malfunction, the fault belongs to the architecture of trust around the components. The vulnerability was never in the smart contract. It was in the unverified leap between an AI output and a financial signature. As an auditor, I have learned that the bug was always there. Here, it was in the absence of a verification step, a missing check that allowed every subsequent action to be valid while the overall system was compromised. Takeaway: An Accountability Gap The The stack trace doesn't lie, but the AI will. Users who asked ChatGPT a question and signed its first link have turned an LLM into an attack distribution network. AI providers need to treat URLs in their outputs as executable payloads and validate them against phishing feeds before surfacing them. Wallets need to loudly warn against unlimited approvals and surface token permissions as first-class security settings. And users, in a bear market where survival is the goal, should treat every AI recommendation as a raw, unverified lead. Until the validation layer exists between the model output and the wallet signature, the next victim is not a question of if. It is a question of which model they ask first. I spent years tracing failed systems. The FTX collapse taught me that trust without transparency is a liability. The 0x audit taught me that the whitepaper is a summary while the code is the truth. This FXRP case adds one more lesson: the interface itself is now an attack surface. Verify. Do not trust. And never let a language model approve your transactions.