AI Agents + Browser MCP: Finding XSS in 8 Minutes

Until I saw this reply by @dhakal_ananda.

So I tried to reproduce what he did.

The target was an intentionally vulnerable XSS challenge created by @hash_kitten: https://xss.hashkitten.io/xss1.html

What Is "Browser MCP"

MCP (Model Context Protocol) is the interface layer that lets an AI agent call tools rather than just generate text. A Chrome DevTools MCP server specifically exposes the Chrome Remote Debugging Protocol as a set of tools the agent can call: navigate to a URL, read the DOM, inspect network requests, execute JavaScript in-page, take screenshots, read console output.

In practice, this turns the agent from "an assistant you paste HTML into" into something that can:

• Walk a page's DOM tree and identify every input, form action, and event handler without you manually viewing source
• Read actual network traffic (headers, response bodies, CSP policies) rather than guessing at them
• Iterate — try something, observe the resulting DOM/console state, adjust — without you being the copy-paste intermediary every single loop

That loop-without-a-human-in-the-middle is the actual value proposition. It's not that the agent finds bugs a skilled researcher wouldn't — it's that it removes you from being the bottleneck on mechanical.

Where This Is Genuinely Efficient

1. Recon and attack-surface mapping at scale.
2. CSP and header analysis.
3. Report drafting.

Setting Up Browser MCP with an AI Agent

This is a baseline setup:

1. Install a Chrome DevTools MCP server
2. Launch Chrome with a dedicated debug profile
3. Point the MCP server at Chrome
4. Register the MCP server with your agent

I'm keeping the setup part short because the exact steps depend on the agent, MCP server, and operating system you use. If you want to reproduce it, ask ChatGPT, Claude, or your preferred AI assistant to walk you through setting up a Chrome DevTools MCP server for your environment.

The Prompt

I didn't give Codex any hint just gave it the objective and access to the browser:

"Use the chrome-devtools MCP server tools to interact with my running Chrome instance. Inspect the site at https://xss.hashkitten.io/xss1.html. Your objective is to find a Cross-Site Scripting (XSS) vulnerability. Evaluate the scripts on the page, alter URL parameters automatically, inject strings, and trigger an alert() window execution box."

And then I let it work.

After 8 minutes it it was able to identify the XSS and trigger the alert()

What Happened

It started to inspect the challenge page directly instead of just guessing payloads.

The page was very small, but the interesting part was this logic:

const url = new URLSearchParams(window.location.search).get('url');

if (url && URL.parse(url)?.protocol != 'javascript:') {
    targetForm.action = url;
    targetForm.submit();
}

const url = new URLSearchParams(window.location.search).get('url');

if (url && URL.parse(url)?.protocol != 'javascript:') {
    targetForm.action = url;
    targetForm.submit();
}

At first, this looks safe because it checks the url parameter and blocks normal javascript: URLs. So a basic payload like this does not work:

javascript:alert(document.domain)

javascript:alert(document.domain)

The important observation was that the page checks the URL with URL.parse(), but then passes the same value into form.action and submits the form. That means there are two different browser behaviors involved: URL parsing and form navigation.

After testing different payloads in the real Chrome tab, the working one was:

javascript://://-alert(document.domain)//

javascript://://-alert(document.domain)//

In short the reason it works is that the URL is malformed enough to bypass the URL.parse() protocol check, but when Chrome submits the form, it mutates/re-serializes the action URL into a valid JavaScript navigation. That is where the alert pops.

If you want to understand the deeper browser behavior behind this trick, I highly recommend reading hashkitten's research here: https://www.slcyber.io/research/two-bypasses-for-chromes-sanitizer-api

My Takeaway

I hope you learned something new from this write-up, and maybe got an idea of how AI agents with browser access can be useful for bug bounty and security research.

This was a small experiment, but I think giving an AI agent the ability to actually interact with a browser makes it much more interesting than just asking it questions.

Thanks for reading!

If you enjoyed the write-up, feel free to connect with me:

• X: @fobokin
• LinkedIn: Abdulrahman Ahmed