Real Prompt Injection Attack Examples in Production Tools

Four disclosed prompt injection chains in Salesforce, GitHub, ChatGPT and Grafana. Separate researcher demonstrations from confirmed breaches and examine the data paths each chain used.

Published: Sep 8, 2026

6-9 mins

By Grace

The real prompt injection attack examples below are researcher demonstrations against shipping products. They show exploitable paths under stated conditions; they do not, by themselves, establish attacks on customers.

Their shared lesson is to inspect the complete path from untrusted input to sensitive output. An image proxy, URL restriction or cloud-hosted agent can change that path without necessarily closing it.

Case Untrusted input Demonstrated outbound path
ForcedLeak Salesforce Web-to-Lead description An image request to an expired domain still allowed by CSP
CamoLeak Hidden text in a GitHub pull request description Pre-signed image URLs through GitHub’s Camo proxy
ShadowLeak Email retrieved by a connected ChatGPT agent A web request originating from OpenAI infrastructure
GrafanaGhost Content reached through logs Image rendering after a URL-validation bypass; user prerequisites disputed

ForcedLeak prompt injection through a sales lead

In its September 2025 disclosure, Noma Labs described placing instructions in a Web-to-Lead Description field, which allowed 42,000 characters in the tested setup. An employee request to process the lead caused Agentforce to consume the payload. The demonstration combined instruction-following failure with an outbound image path; field length alone was not an exploit.

Noma found an expired domain on the image Content Security Policy allowlist and bought it for five dollars. An image request could then carry CRM data to a domain the researchers controlled. This was a browser image-policy bypass, not proof that the CSP governed every network operation an agent could perform.

Noma rated the chain CVSS 9.4, reported it on July 28, and records Trusted URLs enforcement on September 8, before publication on September 25. It says Salesforce re-secured the domain and also recommends customer configuration review and auditing suspicious lead data. Do not infer that customers had no follow-up work.

I had never inspected a URL allowlist in a tool I administered before reading this write-up. It made me question who maintained those entries and whether their ownership was being checked.


CamoLeak attack: hidden Markdown and a permitted image path

Omer Mayraz of Legit Security reported finding CamoLeak in June 2025. His demonstration placed instructions in an HTML comment in a pull request description. Another user asked Copilot Chat to explain the PR, bringing those instructions into context. Simply visiting a page is not the complete trigger demonstrated here.

GitHub documentation showing how HTML comments hide content from rendered Markdown

My capture of GitHub’s documentation. Hidden in the rendered view does not mean removed from the source.

I use GitHub and had not known this was a documented formatting feature. Reviewing the rendered description alone would not show the comment.

The research used Copilot’s access on behalf of the requesting user; it did not grant the attacker a general login to the private repositories. To extract information, the payload used a pre-generated dictionary of signed Camo image URLs. Requests for transparent images encoded the data in their sequence.

Legit’s disclosure rates the chain CVSS 9.6 and says GitHub disabled image rendering in the affected Copilot Chat experience, with the vulnerability fixed as of August 14, 2025. That is the reported historical remediation, not a statement about every current Copilot interface.


ShadowLeak attack: the outbound request ran in the provider’s cloud

Radware’s September 2025 advisory describes ChatGPT connected to enterprise Gmail and permitted to browse the web. A malicious email was retrieved during an ordinary mailbox task; the recipient did not need to open the email or click an attack link. The connected mailbox, web access and agent processing were still prerequisites.

The demonstrated request carrying private data originated from OpenAI infrastructure. Customer perimeter monitoring would not see that provider-to-attacker request crossing the customer’s own network. That does not establish that mailbox records, agent traces, provider logs or other evidence could not exist.

Radware’s own press release dates its report to June 18, 2025 and the notification of a fix to September 3. Notification establishes when Radware was told, not necessarily when OpenAI deployed the remediation.

For the input-path distinction, see direct versus indirect prompt injection.


GrafanaGhost: a validator bypass with disputed prerequisites

Noma’s April 7, 2026 report describes an initial external-image attempt that was blocked. It then found that a check intended to permit local image paths also accepted protocol-relative URLs, which can point to another host. A string beginning with a slash is not necessarily local.

Noma also reported that adding the keyword INTENT to its tested injection helped overcome a model refusal. That is a result for that payload and setup, not evidence that one word disables safeguards generally. Noma says Grafana worked with it and shipped a fix.

The user-interaction requirement is disputed. In a statement given to CyberScoop, Grafana CISO Joe McManus rejected the zero-click framing. He said success required repeated user instructions to follow malicious content despite the assistant’s warnings. At the time of that April response, he also said there was no evidence of exploitation in the wild and no Grafana Cloud data leak.

Those accounts disagree on a material prerequisite. This article cannot resolve the disagreement from the published descriptions. My preference is to read the vendor’s response alongside the research before judging exposure.


What these real prompt injection attack examples show

The common issue is a trust boundary: text supplied for a task influenced behavior that could expose data. Some chains exploited existing controls; others used an ordinary provider-side execution path. It would be inaccurate to call every outbound path a security control.

The lethal trifecta is a useful way to examine exfiltration risk: sensitive access, untrusted input and an outward communication path. It is not a definition of every prompt injection outcome. Corrupting an answer can matter even without an external leak.

An allowlist or proxy can reduce risk. Its existence alone does not establish that the remaining path is safe, nor does one allowed destination automatically create an exploit. Review destination ownership, redirects, URL parsing, request parameters and the data accessible to the workflow.


Questions to ask before an AI tool reads untrusted input

For each feature, identify what outsiders can influence, what sensitive data the agent can access, and how it can send or display that data. Include tool calls, rendered images and provider-side requests. Then ask which checks enforce the task’s authorization and which records would support an investigation.

When I first reviewed my own setup for this post, WordPress and Notion were straightforward because I had no AI features enabled there. Claude Cowork had access to local folders and could read web content when requested. Browser extensions were less clear: I had installed several, including a video summarizer, and had not checked which remained enabled.

That was an inventory gap, not evidence that those tools were vulnerable to these specific chains. A summarizer sending a page to a service does not by itself imply access to unrelated private data. Permissions and actual behavior need checking separately.

Review vendor advisories and apply the customer actions they specify. Provider fixes do not replace your decisions about connectors, permissions and sensitive material. Prompt injection detection explains how to assess another layer, and vetting AI vendors covers broader vendor questions.


FAQ

Q

Do these examples prove real companies were breached?

No. These sources document researcher demonstrations and remediation accounts. They are not enough to establish customer victims, and absence of a victim in a disclosure is not proof that exploitation never occurred. The Grafana statement above is explicitly dated to its response.
Q

Why did my assistant show an injection instead of following it?

Recognizing or surfacing suspicious content can be a useful defensive behavior. Check the proposed action and its source rather than treating either a warning or a normal-looking answer as proof of safety. Do not override a warning solely because the retrieved material tells you to.
Q

How do vendors fix these findings?

The reported remediations differ: restricting output paths, changing rendering behavior or addressing provider-side processing. A research disclosure may describe only part of a fix. Follow the affected vendor’s current advisory for your product and configuration rather than assume every repair is automatic.
Q

Will company security monitoring catch an attack like this?

It depends on the available telemetry and where execution happens. Endpoint and perimeter tools may miss a request originating entirely inside a SaaS provider. Mailbox auditing, application logs and vendor-provided traces can offer different evidence. Test the visibility you actually have; these cases do not justify a blanket claim that monitoring cannot help.

Sources

Sources rechecked in October 2026. Technical outcomes describe the researchers’ tested setups; vendor responses and remediation dates are historical statements, not guarantees about all current deployments.

Written by Grace

I test AI tools and agents in my own workflow, and write down what I find, including the settings that surprised me. About Grace and how posts are verified

Leave a Comment