TL;DR: OpenSea runs an undocumented MCP server at mcp.opensea.io/mcp. One of its tools hands out API keys to anyone who asks, and another lets you resolve any Ethereum address with an OpenSea profile to its owner's username. Reported to Bugcrowd, now sharing the story and a free recon kit. The Setup I was poking around OpenSea's tooling one afternoon — just trying to understand how some of their internal features worked. Nothing fancy, no scanners, no brute force. Just curiosity and a browser. That's when I stumbled onto something that wasn't meant for public eyes: an undocumented MCP server sitting at mcp.opensea.io/mcp. At first glance it looked like just another internal API. But one particular tool caught my attention: get_instant_api_key. The Discovery Turns out, that little endpoint was an unintended exposure of something far more valuable. By sending a straightforward POST request to https://api.opensea.io/api/v2/auth/keys, I could pull a valid API key straight out of the server. No authentication hoops — just a direct line to a credential that should have stayed hidden. With that key in hand, I called the get_profile tool and, suddenly, I could look up a username for any Ethereum address with an OpenSea profile. I tested it on my own wallet, then on a well-known one. Both resolved instantly. It felt like finding a master key to a building you weren't supposed to enter. Why This Matters Information disclosure like this isn't just a curiosity — it's a goldmine for attackers. Enumerating usernames might seem harmless, but it's often the first step in mapping out a target's footprint: Tie a wallet to a real identity (doxxing vector) Correlate multiple wallets to one person Build a profile for targeted phishing or social engineering For NFT holders, that's a real privacy concern. Your wallet is supposed to be pseudonymous — this tool quietly erases that. What OpenSea Did Right To be fair, not everything on that server was exposed. The sensitive tools — like cancel_orders — properly required a wallet JWT with write:orders scope. Trying to call them without it returned a clean MISSING_SCOPE error. So the architecture is sound. The gap was in the discovery layer: a handful of tools were reachable with just an API key that anyone could mint. The Responsible Disclosure I reported this to OpenSea's Bugcrowd program with a full write-up and PoC. It's now in their triage queue (self-assessed as P4 informational — username enumeration; official severity pending triage). If you're a security researcher: don't go poking at this yourself. It's been reported, and testing live systems without authorization is both against program rules and a great way to get banned. The Free Recon Kit I turned the whole investigation into a free PDF — the OpenSea MCP Server Recon Kit — with the methodology, the tools I enumerated, and the lessons learned. It's pay-what-you-want (free, $0 minimum), and it's the same playbook I use when auditing any undocumented API surface. The kit contains methodology only — no exploit code: 👉 Download the free recon kit The Bigger Lesson Undocumented internal APIs are everywhere. They're often overlooked during security reviews, yet they can leak exactly the kind of secrets — like API keys — that turn a minor misconfiguration into a real problem. The next time you're auditing a target, ask yourself: what endpoints exist that nobody documented? That's where the interesting stuff hides. This technique was reported to Bugcrowd and is shared here for educational purposes only. Found this useful? Follow me for more bug bounty write-ups and recon methodology.