Security Advisory: Prompt Injection Risk via Web Content in Authenticated Browser Sessions

[joergmichno]

Summary

BrowserMCP gives AI assistants control over the user's real Chrome browser profile, including authenticated sessions (banking, email, cloud services). When the AI reads web page content via MCP, any webpage can contain prompt injection payloads that hijack the AI's behavior — with access to the user's authenticated sessions.

Attack Vector

1. User navigates to a webpage (or AI navigates on user's behalf)
2. Page contains hidden prompt injection in DOM/text content (invisible to user, visible to AI)
3. AI reads page content via MCP → injection enters LLM context
4. Injection instructs AI to navigate to banking/email sites and perform actions using the user's authenticated sessions

Impact

• Session Hijacking: AI can access any site where the user is logged in (banking, email, cloud dashboards)
• Financial Fraud: Injected instructions could initiate bank transfers, purchases, or payment approvals
• Data Exfiltration: AI could read emails, documents, or credentials from authenticated services
• Account Takeover: AI could change passwords, add MFA devices, or create API keys on authenticated services

OWASP Classification

• OWASP LLM Top 10: LLM01 (Prompt Injection)
• OWASP Agentic Top 10: AG01 (Prompt Injection via Tool Results), AG06 (Excessive Permissions)

Recommendation

1. Add a prominent Security Warning to the README about the risks of browser automation with authenticated sessions
2. Implement a domain allowlist/blocklist for navigation
3. Add confirmation prompts before navigating to sensitive domains (banking, email)
4. Consider a sandboxed browser profile instead of the user's real profile
5. Implement content sanitization before passing page text to LLM context

References

---

Free compliance check: Run your own prompts through our EU AI Act compliance scanner — instant results, no account required: prompttools.co/report

Best,
Joerg Michno
ClawGuard — Open-Source AI Agent Security | 225 patterns, 15 languages

[Ram9199]

This is exactly the browser-agent risk shape I’ve been testing around MCP: untrusted web content reaches the model, then the model can trigger powerful authenticated-browser actions.

I maintain Agent_Sudo, a local MCP permission gateway focused on the tool-action boundary rather than detecting or sanitizing prompt injection. The five-minute proof is: a critical MCP action is blocked, delegated for one use, allowed once, blocked again after exhaustion, then verified in the audit log.

Guide: https://github.com/Kisyntra/Agent_Sudo/blob/main/docs/evaluate_5_minutes.md

I’m not claiming this solves web prompt injection. I’d value feedback from BrowserMCP maintainers/users on whether a separate permission/audit layer is a useful companion control for authenticated browser automation, especially for navigation, form submission, and other high-impact actions.