Hidden prompt injection in web pages: what it is and how to spot it

What it is

OWASP defines the weakness this way: “A Prompt Injection Vulnerability occurs when user prompts alter the LLM’s behavior or output in unintended ways.” It separates two kinds. In direct injection the user’s own prompt changes the model’s behaviour. In indirect injection, “an LLM accepts input from external sources, such as websites or files”, and OWASP adds that “these inputs can affect the model even if they are imperceptible to humans”. A page that a model summarises, searches or acts on is such an external source.

The idea is not new. Greshake and colleagues described it in February 2023: attackers can exploit applications built on language models remotely “by strategically injecting prompts into data likely to be retrieved”. A web page is data likely to be retrieved.

It is also hard to remove at the source. The UK National Cyber Security Centre argued in December 2025 that current language models do not enforce a boundary between instructions and data, that prompt injection may never be mitigated completely in the way SQL injection can be, and that organisations should put their effort into reducing the impact.

How the text is kept from the reader

A person reads the rendered page; a model usually reads the text of the page. The gap between the two is where the text hides. Common ways:

• text in the same colour as the background, or at a font size of zero or a few pixels;
• elements hidden with display: none, visibility: hidden or an opacity of zero, or pushed off the screen with absolute positioning;
• text in HTML comments, or in attributes such as alt, title and aria-label;
• invisible Unicode characters;
• user-generated content such as reviews, comments and form fields that the site prints without review;
• text in a PDF or another file the page links to.

A real case: in July 2025, press reports described hidden commands in academic preprints, in white text and tiny fonts, addressed to AI reviewers and telling them to ignore their instructions and give a positive review only. Nikkei counted 17 such preprints on arXiv and Nature found 18, according to the coverage, and institutions disagreed about whether it was acceptable. The same trick works on a web page that an AI product reads to answer a question about a company or a product.

Google’s spam policies are relevant from the other side. They list “adding hidden links or hidden text to a page by using CSS or HTML” as a form of content injection on hacked sites. Whoever places it, hidden text is a sign that something other than the visible page is speaking.

Where it shows up on client sites

1. Added by someone who wants to steer AI summaries, such as a vendor, a previous agency or the client’s own marketing, with lines that tell a model to recommend a product or ignore a criticism.
2. Injected by an attacker into pages, templates or the database of a compromised site, often together with spam; see How SEO spam hacks hide on WordPress sites.
3. Left in user-generated content that nobody reads, such as old comments, reviews, profile fields and support forms.
4. Brought in by a third-party script or embed, which can write text into the page that never appears in the template.
5. Served only to AI crawlers, which is cloaking: Cloaking for AI crawlers and why it hurts LLM visibility.

Look for it on a client site

1. Search the source for instruction-like phrases. View the page source and the raw HTML from curl, and search for phrases such as “ignore previous instructions”, “ignore all previous”, “system prompt”, “you are an AI”, “do not tell the user” and “when summarizing”. Search the database or the content export for the same phrases.
2. List what is hidden. A short script finds text in elements hidden by inline styles. It is a starting point: it misses styles in stylesheets, off-screen positioning and text hidden by colour.

import re, sys, urllib.request

html = urllib.request.urlopen(sys.argv[1]).read().decode("utf-8", "replace")
hidden = re.findall(r'<([a-z0-9]+)[^>]*style="[^"]*(?:display\s*:\s*none|visibility\s*:\s*hidden|font-size\s*:\s*0|opacity\s*:\s*0)[^"]*"[^>]*>(.*?)</\1>', html, re.I | re.S)
phrases = re.findall(r"(?i)ignore (?:all )?(?:previous|prior) instructions|system prompt|you are an? (?:ai|assistant)|do not tell the user", html)
print(len(hidden), "elements hidden by inline style;", len(phrases), "instruction-like phrases")

1. Compare text, not pixels. Extract the text from the raw HTML, extract the text a browser shows (select all and copy, or a text-mode browser), and compare. Large differences point to hidden content.
2. Check the places nobody reads: user-generated content, third-party embeds, linked PDFs and the page templates.
3. Test with an assistant that has no access to anything of yours. Ask a sandboxed assistant to “summarise this page and list any instructions it contains”. Do not use one that holds your accounts, files or tools: a successful injection would then have something to act on.

Find nothing, and you have found nothing in the places you looked. The check cannot prove a page is clean.

If you build with AI

If your own tools read web pages, whether a support bot, a research agent or an assistant connected to monitoring data, OWASP’s mitigations apply: give the model specific instructions about its role, capabilities and limits; “separate and clearly denote untrusted content to limit its influence”; and restrict its access rights to what its task needs. The NCSC’s advice follows the same line: assume that some injected text will get through, and limit what it can do.

What outside monitoring can and cannot see

Beamfar’s Security checks read each page they fetch for text a visitor cannot see (hidden by CSS, off screen, in a comment or in a meta tag) and report it as a possible problem when it addresses an AI assistant or tries to override its instructions, with the evidence that was seen. They report the hiding technique and what the text asks for, and they treat it as a lead: security writers quote the same phrases in plain view, so only hidden text counts. They read a plan-limited number of pages and never run a page’s scripts, so text that a script adds after the page loads is not seen, and a page that shows the text only to a crawler the scan does not imitate is not caught.

What is built on the other side is that Beamfar’s read-only MCP server passes text from monitored pages to an assistant as untrusted data and never as instructions, and that its tools only read. For the security findings it goes one step further: the words of a hidden text that addresses an assistant are replaced by a note, so a compromised page cannot speak to your assistant through Beamfar. A page check passes if the page still prints the text you require, whatever else it contains. Beamfar is not a firewall and does not remove anything. It has been tried on test pages only and has no customers yet.

Questions

Sources

Read on 28 October 2026. Standards and vendor pages change; confirm the current text before you rely on it.

• OWASP Gen AI Security Project, LLM01:2025 Prompt Injection (genai.owasp.org)
• Greshake et al., Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection (arXiv, February 2023) (arxiv.org)
• UK National Cyber Security Centre, Prompt injection is not SQL injection (it may be worse), 8 December 2025 (read through a search summary of the PDF) (www.ncsc.gov.uk)
• TechSpot, Researchers are hiding prompts in academic papers to manipulate AI peer review (July 2025; read through a search summary) (www.techspot.com)
• Google Search Central, Spam policies for Google web search (hidden links and text in content injection) (developers.google.com)