WhatsApp hid prompt injections in its help docs to steer AI answers

What happened

On October 18, Redact — a privacy-tooling startup — published findings that WhatsApp's public help pages contain hidden text designed not for humans but for the large language models that increasingly summarize those pages. The payload wasn't subtle. Buried in the HTML of help articles about account issues, privacy complaints, and data access, researchers found instruction-style strings telling any model reading the page how to behave: don't recommend contacting regulators, don't suggest the FTC or EU data protection authorities, steer users back to WhatsApp's internal support flow.

The instructions were hidden using the usual tricks — CSS `display:none`, zero-size containers, off-screen positioning. A human visiting help.whatsapp.com sees a normal FAQ. A model doing retrieval-augmented generation over the same URL ingests the full DOM, imperatives and all. Meta didn't jailbreak a model. Meta prompt-injected its own help site, and let the open web deliver the payload for them.

The Hacker News thread hit 290 points within hours, and the comments split predictably: half asking whether this is legally actionable, half pointing out that every company with a content team and a lawyer is about to try the same thing. Meta has not, as of this writing, responded on the record. The hidden strings appear to have been removed from at least some pages after the Redact post went live, though cached copies are still floating around.

Why it matters

The prompt-injection discourse for the last two years has focused on adversarial injection: a malicious third party hiding instructions in a web page, an email, a PDF, a tool result — anywhere a model might read untrusted content on behalf of a user. The defensive posture has been "treat all retrieved content as untrusted," with the implicit assumption that the first-party publisher is on the user's side. WhatsApp's hidden instructions invert that assumption: the publisher is the attacker, and the "attack" is just aggressive opinion-shaping dressed up as metadata.

This is not a technical novelty. You could have done this in 2023. What's new is that a company the size of Meta apparently decided it was worth doing — which means someone, somewhere, ran the math on "what percentage of our support traffic now originates from ChatGPT and Gemini summaries" and concluded it was high enough to justify engineering effort against. That number is almost certainly only going to grow. If you build products that help users navigate services, you are now in an adversarial information environment where the services themselves are gaming the retrieval layer.

Compare the mechanics to classic SEO cloaking, which Google has penalized for twenty years. The signature is nearly identical: content shown to crawlers that differs from content shown to users, with the goal of manipulating a downstream ranking or summarization system. The difference is that search engines evolved an entire adversarial trust infrastructure — cloaking detection, manual review, penalty systems, reconsideration requests. LLM providers have essentially none of this. OpenAI, Anthropic, and Google's Gemini team all ingest web content for RAG and browsing features, and none of them publish a cloaking policy, a hidden-text detection pipeline, or a mechanism for users to report sites that inject instructions. The web is being scraped under 2010-era assumptions by systems that have 2025-era consequences.

The community reaction on HN also surfaced the harder question: at what point is this illegal? In the EU, Article 5 of the Digital Services Act requires platforms to not deceive users in ways that materially distort behavior. In the US, FTC Section 5 covers deceptive practices. A hidden instruction telling an AI not to mention the FTC — when a user is specifically asking how to escalate a complaint — is a fascinating edge case. The user never sees the instruction. The AI never discloses that it saw one. The user ends up with worse information than they would have gotten from a plain Google search. This is probably the first prompt injection in history that could end up as a consent decree.

What this means for your stack

If you ship anything that does retrieval-augmented generation over the open web — a support bot, a research agent, a code assistant that reads docs, a browser extension that summarizes pages — you now need to treat first-party content as hostile too. The practical implications are concrete.

Strip hidden content before it hits the model. Any element with `display:none`, `visibility:hidden`, `aria-hidden="true"`, zero-size dimensions, off-screen positioning (`position:absolute; left:-9999px`), or color-matched text should be dropped at the preprocessing layer. This is cheap, deterministic, and would have blocked the WhatsApp payload cleanly. Playwright or Puppeteer with `page.innerText()` instead of `page.content()` gets you most of the way there — render the page, then extract only what a human would actually see.

Separate retrieved content from instructions at the prompt layer. This has been best practice for a year, but if you're still concatenating `system_prompt + user_query + scraped_content` into one blob, you're building the exact pathology WhatsApp just exploited. Use structured message boundaries, mark retrieved content explicitly as untrusted, and tell the model its instructions come only from the system role. Anthropic's and OpenAI's docs both cover this; the compliance rate in actual production code is much lower than it should be.

Log and audit what retrieval returned. If your bot gave a user a weird answer, you need to be able to go back and see exactly what text your scraper fed the model, not just the model's response. Without the raw retrieval log, you can't tell the difference between model hallucination, bad retrieval ranking, and a vendor injecting instructions into your context window. Store the full retrieved content for every answer that touches live web data, at least for a rolling window. Storage is cheap; being unable to explain a regulatory-sensitive answer is not.

Consider the trust graph. For high-stakes queries — legal, medical, financial, regulatory — rank first-party docs *lower*, not higher. A user asking "how do I file a privacy complaint about WhatsApp" is better served by the EFF, the ICO, or noyb than by WhatsApp's own help pages, and this incident is the proof. Hard-coding regulator URLs into your retrieval allowlist for compliance-adjacent queries is suddenly a defensible product decision.

Looking ahead

The interesting question isn't whether other companies are doing this — they are, or they will be by Q1. The question is whether the model vendors treat it as a cloaking problem (detect, penalize, publish policy) or as free training signal they'd rather not look at too closely. Historically, when there's revenue on both sides of a scrape, the scraper tends to notice less. Expect the first "AI SEO" vendor to pitch hidden-instruction injection as a service by the end of the year, and expect at least one AI lab to quietly add a cloaking filter without ever naming WhatsApp in the changelog. The retrieval layer just became a battleground, and your RAG pipeline is standing on it whether you planned to be there or not.