Eurostar's chatbot is not a confirmed customer-data breach. That is the point.

In December 2025, Pen Test Partners published research on Eurostar's public AI chatbot after disclosing four weaknesses through the company's vulnerability disclosure process. The researchers did not claim they stole customer records. Eurostar told TechRadar that customer data was never at risk because the chatbot was not connected to other systems and sensitive data remained behind customer login. Taken narrowly, that is a good outcome.

Taken as an engineering signal, it is much less comforting. The researchers found a public support chatbot with guardrails that could be bypassed, prompt-injection paths that could expose internal instructions, HTML injection that could run script in the chat window, and conversation and message IDs that were not validated properly. The fact that no customer database sat behind the bot is the reason this stayed a hazard rather than becoming a breach story.

The Chat History Trap

The basic architecture looked reasonable at first glance. The chatbot was API-driven. Each user message went to a Eurostar chatbot endpoint along with the chat history. The server ran a guardrail check, marked allowed messages as passed, and returned signatures that were supposed to show which messages had cleared the policy layer.

The failure was in what the server trusted. According to Pen Test Partners, each request sent the whole chat history, but the system only checked the most recent message's signature. Older messages in the same history were not re-verified and were not cryptographically bound to the guard decision. That meant a researcher could make the latest message harmless enough to pass, then alter an earlier message client-side into the real payload.

That is a classic web security mistake wearing an AI costume. The client supplied state. The server trusted more of it than it should have. The new part is that the trusted state was not just a form value or a hidden field. It was model context.

Once that context could be rewritten, the chatbot's guardrail stopped acting like a control and started acting like theater. The latest message passed, so the poisoned history reached the model as if it were legitimate conversation. Pen Test Partners used that pattern to bypass guardrails and extract information the bot should not have disclosed, including model and system-prompt details.

Prompt Injection Was Only One Piece

The prompt-injection result is the obvious headline, but the more durable lesson is that the bug chain mixed AI-specific and old web flaws.

The researchers reported four issues: guardrail bypass, information disclosure via prompt injection, HTML injection or self-XSS due to weak input validation, and conversation and message IDs that were not verified properly. HTML injection meant the chatbot could be made to return content that executed in the user's browser. On its own, Pen Test Partners characterized that as self-XSS because the payload ran for the person using the chatbot. Combined with weak conversation ID validation, they warned it suggested a plausible path toward stored or shared XSS if malicious chat content could be replayed in another user's session.

They did not attempt to access other users' conversations or prove cross-user compromise, because that would have exceeded the disclosure scope. That restraint matters. It is also why the story should be framed as a demonstrated hazard, not a proven customer compromise.

TechRadar reported Eurostar's position that the chatbot had no access to other systems and no sensitive customer data was at risk. That statement narrows the known harm. It does not erase the weakness. A customer-support chatbot is not a toy once it sits on the public website of a travel operator. Even if the first version can only answer basic questions, the natural product roadmap is obvious: bookings, refunds, loyalty status, disruption handling, personal itineraries, accessibility requests, and account-specific support. A brittle design at launch can become a breach after one integration sprint.

The Disclosure Mess

The disclosure path added a second failure mode. Pen Test Partners said they initially reported the issues to Eurostar's vulnerability disclosure email on June 11, 2025, then followed up on June 18 without response. After nearly a month, they escalated through LinkedIn. They were reportedly told to use the vulnerability disclosure program, even though that was where they had already submitted the report.

According to the researchers, Eurostar had outsourced its vulnerability disclosure program during the process, launched a new disclosure form, and retired the old route. The original report was eventually found, and some fixes were said to be public. The Register reported that, during the back-and-forth, Eurostar's head of security allegedly suggested the researchers' escalation could be seen as blackmail.

That does not make the chatbot more vulnerable, but it does say something about readiness. If a company is going to ship public AI features, especially ones that invite prompt-injection testing, it needs a disclosure process that can absorb AI-specific reports without losing them or treating persistence as hostility. AI systems generate a lot of strange reports, and many will be noise. That makes triage harder. It does not make triage optional.

Why This Counts Without Confirmed Harm

This story belongs because it shows the pre-breach version of an AI support failure. The system had visible guardrails, but the enforcement boundary was wrong. It treated a signature on one message as confidence in an entire mutable history. It allowed model context to be supplied by the browser and trusted too much of that context on the server. It rendered chatbot output in a way that made HTML injection relevant. It accepted weak conversation and message identifiers.

None of those problems require a science-fiction model failure. They require ordinary engineering discipline: validate server-side, bind signatures to the content and IDs they claim to protect, treat client-supplied history as hostile, sanitize output before rendering it, and assume prompt injection is a normal input class.

The AI piece made the failure easier to underestimate. A conventional support form with weak IDs and HTML injection would read as a familiar web security bug. Add an LLM, and teams can get distracted by prompts, guardrail copy, and model behavior while the old API rules still decide whether the feature is safe.

Eurostar appears to have avoided confirmed customer harm because the chatbot was not deeply integrated into sensitive customer systems. That is exactly the moment to file the lesson. The safe time to fix an AI support architecture is before it can reset accounts, touch bookings, issue refunds, or read personal data. Once the bot gets those privileges, the same design errors stop being embarrassing and start becoming incident reports.