BSidesSF 2026 - MCPwned: Hacking MCP Servers with One Skeleton Key... (Jonathan Leitschuh)

For our next presentation, we have Jonathan Lishu and the titles is MC Pong hacking MCP servers with one skeleton key vulnerability. Thank you, Jonathan.

Can you hear me? Hi, you can hear me. Amazing. Um, yes. So, welcome to MC Pone. hacking MCP servers with one skeleton skeleton key vulnerability. Who am I? Uh my name is Jonathan Lechu. I'm a software engineer turned security researcher. Um I was honored to be the inaugural Dan Kaminsky fellow um after Dan passed away um at human security. Um I am a GitHub star. I was a GitHub security ambassador for the time that that existed. Um you can find me on Twitter at J Lechu. I don't use it. It's now X. I know yada yada yada. uh GitHub, uh LinkedIn. Um so why MCP servers? Um and uh I I had a boss. I was working for socket at the

time and uh he said to me, "I bet you there are interesting vulnerabilities in AI systems." And um uh you uh you know uh security researchers uh we have a tendency to, you know, chase the uh shiny thing. Um uh um uh so yeah so and also the media likes it the hype yada yada yada. So um how did this research start? Um I have a particular fascinating fascination with locally running servers and attacks via the browser. Um I have some history here. Um the uh the vulnerabilities in this area people uh run local web servers. Uh they build local web servers and they ship them in products. And the thing about these local web servers,

they tend to have a lot of permissions on the local machine. Um, and so when you're able to hack one of these things, you can have a lot of fun. Um, so, uh, let's talk about the basis of this talk is, let's talk a little about the same origin policy. So, the same origin policy was implemented inside of browsers as a way to keep website A from talking to website B via JavaScript. Um, so if you're, you know, pirating a movie from a website, you don't want that same website that might have fishy ads running on it to be able to attack your bank. Um, and this is a fundamental security set of guard rails that was

that are implemented in the browser. And the same origin policy um blocks uh certain blocks um some domains or blocks JavaScript running on certain domains from cross-talking onto other domains. um following a set of rules. Um it must match the same port. It must match the same pro uh the same scheme and it must match the same protocol. Um so what can bypass the same origin policy? Well, in in in the web land, so I've got a browser and the browser has JavaScript running inside of it and the JavaScript is able to make outgoing HTTP requests. And frequently you're just talking to the server that served you the HTML to begin with. But um often you know

websites are making cross requests in onto other domains. And so what can cross this boundary? Um so in in browser land uh requests fall into two categories. Um the there's pre-flighter requests and pre-flighter requests um were introduced in cores and so they're put, post and delete requests. um and uh sorry put post and delete requests in particular post requests with complex bodies. So anything with content type other than um this form encoded URL uh form data and text plane and then there are simple requests um and simple requests are considered you know safe. So they don't trigger a pre-flight request and so a pre-flight request if you're making any of these requests. If you're making any of these requests,

my clicker's a little slow. Uh, nope. Do the keyboard. Okay, there we go. If you're making any of these requests, the browser is going to make a pre-flight request to the server and say, "Hey, this um this uh web page is trying to make a request." It's going to send an options request and say, "Hey, is this allowed?" And the server needs to respond with a with an header that says, "Yes, I will allow allow requests from that domain." Um, and if if it doesn't, um, then the browser will block the request. And this makes it so that websites that weren't aware of cores maintain security, but any servers that want to opt into this cross origin

request um, can. And then we also have simple requests. And simple requests are considered safe. So head, get, options, trace, and post requests that um if you remember that same list of uh content types that we had originally, if you're using requests with those content types, those are simple requests and they can happen cross origin. Um and the reason that the post requests continue to be sorted support is for legacy reasons because before cores existed, you know, browsers had these behaviors and they didn't want to break backwards compatibility. Um so the question arises then is what happens when a server exposes a vulnerable endpoint via getter post. Uh it's like one ser one one uh one website

attacking another one bad happens. Um and this also is how you can attack localhost servers or servers running inside of a private network. Um, basically using the browser as a pivot or confused deputy to attack inside of a private network. Um, so let's cover some local host and private network attacks and the history here. Um, as it turns out, uh, malicious websites can talk to local host and private network servers. Um so uh if you're making a simple request or you're able to use I will talk about this eventually but DNS rebinding um you can get your uh you know this this JavaScript that's been served from this malicious website to then make a request

to localhost down here. And this is a 19-year-old vulnerability. Um there was a report opened uh Bugzilla uh for Mosilla back in uh 19 years ago about trying to mitigate these sorts of attacks from local like basically public websites attacking local uh local addresses. Um I've uh this is remains open. Um uh I tried to get MITER to issue a CVE number for this. Um, and their response was, "This behavior is required by the W3C standard and has multiple use cases, but of course can be abused, yada yada yada." Um, it's not a violation of the browser security model. I Well, there's a lot of history here. Um, developers don't know about this behavior. Like, they really don't know

this this this behavior exists. And I have a lot of examples that demonstrate how this goes poorly. Um the first case of this that I was able to find um was in 2006. Um drive by farming. Um uh basically the ability to change the DNS record or sorry the DNS server that a router is configured. Um, and all that was required was just throw this JavaScript in or throw this HTML in your browser and that goes and reconfigures your uh yeah um in uh 2015 um more vulnerabilities are found in DNS uh or sorry in Wi-Fi on Wi-Fi routers. Um you could uh exploit yeah exploit the uh browser origin restrictions and access private networks stealing Wi-Fi

credentials and DNS rebinding and doing and can reconfiguring the router admin interfaces. Um in 2016 um Jordan Mily found that your Jet Brains IDE was running a local web server inside of it. Um, and uh, you could get remote code execution by sending a request to this thing and saying, "Hey, load this project from an SMB drive." And when Jet Brains's ideides loaded your uh, your project from an SMB drive, um, as it turns out, loading a a project into an IDE runs setup code. And so you had code execution via that. And that's all the payload that was required to do that. Um, in 2016, uh, Tavis Ormandy found that the Trend Micros manager had a

remote code execution vulnerability in it. Um, in 2018, uh, a Princeton team found that you could attack IoT devices on the private network via the browser. Um, in 2018, uh, Port Swigger and Gareth Hayes, uh, built a proof of concept that would let you do intranet port scanning via the browser using the timing differential between the errors that come back from making requests with JavaScript and iframe loading. Basically be determining what ports are open on systems. Uh, I uh found a vulnerability in Zoom in 2019 that let anybody hijack your webcam and join you to a video call without your permission. um using this same vulnerability um and that made international news and got covered in

Forbes and Wired and Techrunch and NPR and BBC and all over the internet. Uh and then two days later that same web server was found to have a remote code execution vulnerability in it thanks to asset note. Um uh in 2019 Dell support assistant had a local host remote execution vulnerability founded by Bill Dempkkey. in 20 missed one. Uh missed two. Uh eBay was found to be port scanning your machine in 2020. Uh in 2024, uh uh Avy who just presented um found that uh there was a 0.0.0.0 day exploit. A lot of zeros um that bypasses fundamental understandings that we had about uh and browsers had started putting controls in, but you could just

bypass it using that instead of localhost or 127.0.0.1. Uh last year there was a paper published by a research team that found that um uh the Facebook and Yandex apps on Android were running on the phone and Facebook for example had the meta tracking pixel and they were using a local host running server inside of your Android app to deanonymize you as you were walking across the internet. So, if you had the Android app installed, the Facebook uh app installed on your phone, anytime you visited a website with the meta tracking pixel, it would make a local host request to your Facebook app, deanonymizing you. Um, and X was doing the same thing. Um, uh, ASUS had a remote code execution

vulnerability in 2025 discovered by Mr. Bra. Um, Anthropic had an MCP inspector remote code execution vulnerability. Uh, so all of this to say this is a longstanding problem. Wait. Yeah, this is a long-standing problem in browsers. Um, and I have all of those examples and the hit like if you want to cross reference that is a link to the GitHub post that I have against a specification. It'll ruin the punch line a little bit, but like if you want to read through all of those blog posts, I have a list of all of them there on a GitHub issue. Um, so, um, and come find me if you don't get this right now. I'll show it. I can show it later. So, let's

talk about DNS rebinding attacks. Um, I've mentioned them a couple times. I talked about the same origin policy, but I haven't talked about DNS rebinding. Um, so you remember the same origin policy. Uh, DNS rebinding attacks bypass the same origin policy. Yay. Um, so how does that work? Um, so let's say you're a user, um, and you accidentally visit a malicious website. Never done that before. Um, so, uh, what you're doing is you're actually interacting with both the malicious server, but also the malicious DNS server. And you think, oh, like I thought, oh, getting someone to interact with a malicious DNS server, that'll be hard. It's not. Um, it surprised me. You can run your own

DNS server, as it turns out. Um uh so it like what's the IP of attack.com and the IP of attack.com is this 5.67.8 right and so then this loads javascript into the browser um now you've got this binding script that's talking to 5.67.8 and then the second request comes in the browser says what's the IP address of attack.com and the brows this thing this DNS server responds with it's 1 192.0.0.1 or27.0.0.1 0.1 or whatever. And then suddenly this code that was running that was talking to this public server is now suddenly talking to this private web server on your machine or on your private network and it's routed over attack.com. So the domain has not

changed but that domain suddenly points to a different IP address. And you might be like okay but how long does that take? Well there are two DNS rebinding strategies that have been discovered by security researchers way smarter than myself. Um, and the first one is first then second with cache flooding, which basically means shove a bunch of uh records into the response and fill up the cache in Chrome. And that takes about 15 to 45 seconds. And I have some demos of that and it takes that much time. And then I realized how to use the faster solution which is multiple answers and that works in about 3 seconds. Um, so does not take that that

long. And this is a fundamental vulnerability in browsers. There have been discussions about how to fix this with DNS pinning and stuff like that seem to not work because the vulnerability still continues to work to this day in many browsers. Um and again we are violating this fundamental belief and understanding that developers correctly assume that locally running means only locally accessible. It's not how the world works. Um so let's weaponize uh DNS binding. So NCC group helpfully built this wonderful tool called singularity of origin. Um, it's this really really cool uh DNS uh DNS um hijacking uh uh DNS rebinding attack framework. Um it comes with two components. A web server that hosts the htm uh the html and the the ability to

configure it and test it out and a malicious DNS server um written in Go. Actually, the whole thing's written in Go. Um both the backend server and the DNS server are both meshed together. Um and it comes with a really really helpful list of attack payloads um for so you can configure you know you had an attack domain attack host the port um and it comes with a list of attacks that have already been published for leveraging DNS rebinding and these were all examples of real DNS rebinding attacks that also worked um over the years. Um okay so let's put a pin in DNS rebinding and take another let's go a little bit uh let's talk about MCP servers. So

stock is called MC poned. Um some of you I hope know what MCP servers are but for the rest of you what is MCP? MCCP stands for model context protocol and um the model context protocol standard is a way for um claude and you know open AI and cursor and all these different tools to talk to in a standardized way your uh databases your git your sentry or all of these different things. It's a standardized glue that that can be used to very easily get your get data out of these systems and stuff like that. And there are two primary communication channel or well actually there's three primary communication channels for these things. Um there's standard IO um which

is basically uh standard IO it you're not it's not going to be vulnerable to uh attacks via HTTP because you're it's all local processes. Um there's HTTP with server side events um which is deprecated but some SDKs still support it. and the streamable HTTP HTTP and that is the standardized version that everybody uh it's the expectation that every everything supports these days. Um MCP speaks JSON RCP under the hood. So you'll see sort of like when you're looking at the communication you'll see like you know these calls that go back and forth like this. Um and there's this really helpful tool called the MCP inspector. Um show of hands who's used MCP inspector. Okay so yeah some people some people

have done this. Um, and so this MCP inspector is a really really helpful tool. You can hook it up to your MCP server um that you're building or testing and instead of requiring that the your chatbot is appropriately calling the right MCP tools or you know whatever, you can just be like, I want to make sure this thing works properly the way I expect it to. Um, and so it lets you like debug and test running tool calls and all that stuff. Um, and so the MCP is built on a set of specifications. Um, and one critical line in the MCP specification, uh, is this little one here. Um, servers must validate the origin header on all

incoming connections to prevent DNS rebinding attacks. If the origin header is present, uh, and invalid, servers must respond with an HTTP 403 forbidden. The HTTP response may in uh, comprise a JSON RCP error response that has no ID. I'm going to take a drink. Critically, without these protections, attackers could use DNS rebinding to interact with local MCP servers from remote websites. So, um, the most popular SDK out there for building an MCP server is the TypeScript SDK. This is the how to guide for uh your MCP server. Like this is like all the code that you need to get your MCP server running. And you'll notice this this critical line right here uh in particular uh that one DNS rebinding

protection is disabled by default for backwards compatibility. If you're running this server locally, make sure to set these things. Care to guess how many servers do this? Not many. as I found out. Enter MC pawned. Let's hack all the things. So, um let's start with the basics. Uh model context protocol server everything MCP. So, this is um an MCP server that's not actually practically intended to be used. Um but it's intended to exercise all of the features of the MCP protocol. Um and it's a test for your MCP builders. Um, it implements prompts, tools, resources, yada yada yada. Um, and there we go. Um, I'm adding an additional environment variable to the launch of this thing. Uh, I'm running

Singularity of Origin with my custom payload here on the on the left side. Um, and this is the server logs for uh um uh the um uh Singularity. Um, this is using the DNS rebinding uh uh first then second uh which is why I have the 8x speed up because the dang thing takes a while and I don't want to bore you all. Um, but eventually there it goes. It pops and I get all the environment variables out of the um uh off the MCP server. Um, so that that was um that's server everything. Um, the second place that I found this vulnerability was Google's OSS fuzz. Um, and Google OSS fuzz, uh, they were they had an they had an NCPC

server built into it, um, uh, that exposed, as it turned out, a remote code execution endpoint. Um, so yes, you launch the server, uh, put the payload in. This is when I'd figured out how to use multiple answers and because it's significantly faster. Uh, and you hit submit and about no time at all. There you go. Pops and calculator. Hey. Um, thank you. Um and for this uh Google awarded me experimental out of scope.

Um so yeah um anywh who uh but regardless after this inspiration sp struck um and do you all remember the MCP inspector uh this thing that lets you debug? I was like, "Hey, what if I, you know, run MCP spec inspector but over DNS rebinding? That'd be fun." So, after several cursor prompts later, I have a shiny user interface built on top of NCC Group Singularity that gives me tools, prompts, resources, logs for the MCP server that I'm connected to, all running over DNS rebinding as a communication protocol. Um, uh, so once I have this, now I can go hack some other things. Um, so Google Cloud Run is uh has the it exposes the ability to

upload arbitrary files into a Google Cloud Run instance. And uh when I connected to that um we'll see that once I get the port I can hit start DNS binding attack. I've also set the defaults now at this point because I hated myself punching in those code those numbers all the time. And now we can connect and it lists out all of the capabilities of the server. Um, you can list the tools. You can make tool calls to any of the tool call endpoints on this thing. Um, and this is just a great way of creating a video to demonstrate, hey, by the way, you've produced an MCP server that I can hack uh just by

getting my website you getting a malicious uh getting a user a naive user to connect to a malicious website. I can now hack your MCP server your local machine. And for this, Google awarded me 200 bucks. Um um uh G GKE is Google Kubernetes Engine. Um uh exposes full cluster data and allows for quering the logs. Um similarly, I'm just going to skip through this a little bit more, but uh basically, yeah, I can There we go. Um when you connect to it, uh it lets you dump all this stuff, yada yada yada. tools. Yep. Fun. Um the one this one's actually more interesting. Uh yeah, they also awarded me $200 for this one. Yay. So that's

over $400 now. Um Google also has this really cool thing called geni toolbox. This connects your MCP servers to databases. Um, you can also give it a set of HTTP uh endpoints that you want to be able to make give your MCP server the capabilities of being able to call. Um, and uh, so uh, this is actually as a developer tool a pretty juicy target because it basically means that if you've got any databases hooked up to this thing um, I can now make all the STS SQL calls as if I'm a developer. I can um, make any of the HTTP calls inside of your network as if I'm your developer. Um, this is a pretty juicy

target and you can see that I'm actually, you know, talking to the server um, on the left side using this DNS rebinding as a as a communication target. I, uh, I set up this thing, the toolbox with like simple calls. By a show of hands, who's used, uh, Google's MCP toolbox one. Wow. Okay. Less than I expected. Um, for this one, Google awarded me 200 bucks. So, we're at 600 bucks now. Yay. Um, uh, Apollo Graphical. I'm not going to do another video demo of this. Apollo uh basically um their uh full GraphQL API with credentials. So if you have if you have a GraphQL API hooked up to uh uh Apollo's MTC MCP server, you can make

calls authenticated. Um Docker was interesting. Docker had an MCP gateway which was um uh they actually had a blog post that they detailed how the MCP gateway would prevent this attack from being able to be possible. um because they were talking about the MCP inspector attack. They're like, "Yes, MCP gateway can totally prevent this because the browser is not able to reach your Docker container because it's running in Docker." And I saw this as a challenge. Uh and so of course I found that this vulnerability was a possible with MCPS. So, uh if you're running with transport streaming, um you were always vulnerable to this. Uh this has a CVE number and Docker graciously awarded me one

t-shirt. and some swag. I got a lot of like I think I might got a mug or like you know some photo and some stickers. But yeah, um AWS Labs uh I could make every single SDK or any so basically the AWS CLI fully exposed. So if you were running this server on your local machine as a developer, I could call into all of your AWS infrastructure via your browser. Um so how is this fixed? Um after a long time um Anthropic actually added a tier system to their SDK to to their I should this should say SDKs. So the maturity for their SDKs um and you can see it here. Um so TypeScript, Python, C all

these ones. Um these are all in tier one, Java, Rust, Swift, tier 2. Um so and they've added conformance tests and basically in order to achieve these higher tiers of available SDKs you have to pass these conformance tests and some of these conformance tests now include testing for DNS rebinding as a as enabled by default. So all tier one are safe. I have not had the time uh to sit down with tier two or tier three to check these other ones. I knew that when I looked at all of them across all the use cases, they're basically all vulnerable. So at least tier one is now safe. Um, and uh, Anthropic actually for uh, for the TypeScript SDK assigned this

CV number which is not published yet. I need to get actually probably CVS for a bunch of the other ones. Um, I've been busy traveling so I will take care of this. But Enthropic was gracious enough to for this overarching research looking into the SDKs in total award me with a bounty of $1,500 which is pretty nice. Um, yeah. So, that brings the total award to uh $2,100 plus a t-shirt. I did miss my flight here though, the other day, and that cost me an additional $450, so I'm down 450. So, I don't know, whatever. Um uh so, okay, what about browsers? Um let me check the time. What do I have for time? We're Yeah,

great. Amazing. 18 minutes. Um so, what about browsers? Um so back in 2022 um Chrome announced private network access introducing pre-flights. Um and in this blog post that Chrome published they said this Chrome is deprecating direct access to private network endpoints from public websites as part of private network access part of the uh private network ex uh part of the private network access PNA specification. So this is it right? we've won. Like we're we're doing it. Like we're actually going to fix this vulnerability, right? Uh well, uh as it turned out, uh in March of 7th, they had to roll it back because it broke too much stuff. The goal of this specification was to send

pre-flight requests to basically ask local servers, hey, are you okay with something on the public internet talking to you? But there's a bunch of stuff that we've shipped as engineers out in the world already running that expects the browsers to be able to talk cross origin like this and it broke a bunch of stuff. So unfortunately this guardrail was not shipped and has not rolled out around the world. So, attempt number two, um, this blog post, uh, when it came out June 9th, uh, 2025, and my understanding that was that this actually was pretty much in response to, uh, Meta's, uh, local mess and Yandex's local mess was this. That was actually the fire that

got the browser developer to finally move forward on fixing this. And in this blog post they say local network access or restricts the ability of websites to send requests to servers on a user's local network including servers running locally or on the user's local uh machine requiring the user to grant the site permission before such requests can be made. And what does that look like practically? A more prompts. Um but finally the browser is asking you similar to hey can I access your camera or hey can I access your microphone or hey can I like send you notifications like we're now getting at least a prompt in the way of your browser hack or a most website hacking

your internal network systems. So we have stepped it down in terms of CVSS score. It's now you have to be prompted to do this. Um so what's the support of this currently? Um currently uh these percentages are the percentages of uh the um uh usage percentages uh by uh stat counter browser market share. Um Chrome prompts yay. Edge which is based upon the Chromium engine prompts yay. Firefox does not. and uh Safari does not. And I did I actually tested DNS rebinding um yesterday. These are results from yesterday. I sat down and I was like I wonder and yes so DNS rebinding um and by you know necessity local attacks like this continue to work. And as we've seen

we can't guarantee that this will remain fixed because Chrome already rolled this back once. Um hopefully this will stick. Hopefully that permission prompt will roll out. I would love to see it across the entire I've hope I've hoped for that permission prompt that we saw since the Zoom vulnerability I found in 2019. I reached out to Firefox and Chrome uh back in 2019 and I'm like how why why is it possible that a website can talk to a local host process on my machine without being me being prompted? Like that seems not what I would expect. Um and their response was years of history. Um we can't fix it right now. Thankfully, we're finally seeing movement on that.

So, some key takeaways, um hopefully um this will remain fixed, but unfortunately developers don't come to talks like this. They don't learn about DNS rebinding. They don't learn that like our browsers can do these weird esoteric things. And so, I think that these vulnerabilities are unfortunately going to continue to arise. Um and and we're going to have to continue to deal with it. And the problem is that a lot of these local host servers are running. I mean, how many times did I say this led to a remote code execution vulnerability on local people's machines very consistently and I don't know I don't know how to fix that but hopefully we can get browsers to at least make it a

little bit harder over time. Um, so I want to give some special thanks. Um, Socket who employed me. Uh, I was a contractor for them for 3 months while I was doing this research. Um, Avy uh, Luminsky from Algo who I was speaking to a lot about this and kind of inspired some of this. Gerald Dalt at NCC Group who I was talking to about working with Singularity at the time. Um, and uh, this is me. That's my LinkedIn. Um, not trying to get you to visit malicious local servers that are going to attack you. Promise. Um, yeah. So, uh, I have time for questions. Hit me.

Thank you so much Jonathan. We have two questions in Slido. >> I'm also happy to take questions from the audience too raising your hand but let's do the slidoh first. >> Okay. So are most developers safe from this class of attack because VS Code runs MCP servers via studio by by default? >> Uh yes. So if you're using standard IO for MCP servers then you're not vulnerable. Um uh that is by default. Um, but you'll see that companies are shipping products like um I don't know I I saw like I've seen um you know um companies will sometimes ship like uh local electron applications and they'll instead of saying connect via standard IO they're like here we're

running this we're running this local host server on this port connect to it via this way and they'll give you instructions for dropping it into VS Code. So, VS Code does support um uh VS Code does support um uh the the two HTTP standards for communicating with MCP servers. So, those are vulnerable. But yes, if you're using standard IO, you're not vulnerable. Um that you know is the best solution across the board is don't expose a port on your machine. >> Okay. So, the second one, we have two more. So, three. >> Yeah. Yeah. Uh and they mistook cap capability for wisdom and rapid APIs uh in the cloth of hubris is API MCP a

weighted gasoline soaked blanket or just 775 plus opportunities for fun. >> Sorry, what? >> Here it sketchy. >> Yeah. And they mistook the capability for wisdom and wrapped APIs in the cloth of hubris. Oh, okay. And they mistook the capability for wisdom and wrapped APIs in the cloth of hubris. Is API MCP a weighted gasoline soaked blanket or just 775 plus uh opportunities for fun? Um I'm uh okay. Um I'm not certain and I fully understand. So uh Mark, if you want to throw that one out there again, go for it. Can I >> Yeah, go for it. the ide

just just incredible news stories about this stuff. People just don't know what they're doing. How much of an impending dis Is it or might you be paranoid? >> Uh little A, little B. I don't know. I think I don't I think you're terribly paranoid. I think that I mean it's I mean one of the things we've seen is like uh the overexposure of um uh MCP servers like if you look at GitHub's MCP server, right? They tell you you have to turn off certain capabilities because the con supposed supposedly if you expose all of the MCP tool API things that the the server exposes, it blows out the context window too much. And so the MCP server becomes less useful

because it exposes too much functionality. So we have seen that sort I don't know what the I mean that was at least you know two three months ago and the world changes so rapidly with respect to AI systems that I have no idea how relevant that advice is nowadays. Um but there is I have read certain guidance and blog posts that basically said don't make your MCP server just expose your entire API. That's not useful. You want to like curate and cater what your MCP server is going to expose. Um, yeah. Next. Great. >> What are some legacy reasons why this is still a thing? >> Oh, yeah. I mean, uh, uh, the original model of the web didn't really consider

the difference between a private network and a public network. And like we so these I mean some of the reasons that like PNA uh private network access I mean there might be some like older older people in the audience who have a longer history than I can speak to but it seems like we just kind of assumed that everything was be able to talk to everything on the internet and so browsers have to encode these ideas now of what is a private network what is a local network as a new concept that was never captured to differentiate these networks and try to create these boundaries that the browser then tries to prevent from being violated. Um and

we're working with legacy like uh the same origin policy and uh simple requests right so simple requests it as an attacker if I can get my request into a simple request I don't need to consider cross origin uh uh cores right like that's why um we have crossite request forgery tokens everywhere if you like CSRF is a modern solution to solving a legacy a problem in browsers that basically means that browsers can make cross origin requests and servers don't have a really good way of guarding against that. So that's why CSRF so this is similar to the CSRF token solution but it just the downside is if you don't understand this stuff everybody needs to implement like

the the the the downside the negative thing is everybody needs to implement CSRF tokens to protect against cross-ite request forgery just like everybody needs to protect against if you're running a local host server you have to consider every single domain can potentially talk to my local host server if I'm exposing it in the wrong way. Does that make sense? Yes. Does that answer the question? I got a hand back there. Go for it. >> Advent. >> Yes. >> Supported by anthropic and open AI and having as part of their specific or unauthenticated end points. How excited and how many more dollars do you think you're going to get as a security? question. >> Uh yeah. So the question is is um uh

given given that part of the specification requires that certain API endpoints be exposed um without authentication in the MCP. Will that lead to more vulnerabilities? Um uh it depends. I think that one of the big things that'll depend upon is whether or not those API endpoints are encoded in the SDK or if they are something that people have to customize. So like if we can get them into the SDKs and then it's less likely that they'll lead to long-term vulnerabilities. But if it's something that every single person has to implement and implement, right, then you exponentially increase the likelihood that somebody's going to do it wrong at scale. >> On that just a quick thing, MCP servers

are required to list their required end. >> Oh, interesting. Oh, >> resources. >> That seems like a wait, you have to be able to list tools. You have to be able to expose the set of tools that you expose without authentication. That seems like a bad idea. Um, >> yeah. Yeah. Yeah. Yeah. Fair. Yeah. >> Yeah. Yeah. >> Um, we have four more questions. Maybe we don't get the time to do them all, but we'll try. >> Can you explain in Mosilla not fixing the issue? Isn't Firefox open source? >> Oh, >> you can answer. >> Oh, yeah. Yeah. Yeah. Um, so the question was, um, why has this issue not been fixed? Um, because there are

differing opinions on what fixed looks like. um uh the browser vendors will say I mean so I posted that link uh early on in my talk which was the like here's the history of uh all of this exploitation and there's a guy in that thread in that on that issue because it's it's on the the local uh uh local network specification uh GitHub repository and there's a guy that's kicking around that repository and he's building a uh system that relies upon this behavior. He I presume he runs a company that relies upon this behavior and so he's buil because he's building a company relying on this behavior having his end users get prompted that hey this website wants

to reach out to a local process or a local device on your network. Do you want to allow that? That's adding additional cognitive load and support load to him having to explain that to his end customers. And so if things just work right, it's way easier. And also that prompt doesn't really give like context on why this thing is doing that or what that behavior actually gives you like for example like this is potentially equivalent of giving access to your camera or your or your uh microphone depending upon right like that capability of I want to be able to make local web requests to your devices on your machine on your machine I mean your devices are you know touring

compete complete computers and if there's enough vulnerabilities in those systems they could get microphone access and that's not really clearly communicated to a naive user that doesn't understand devices connected to your network. Right? So we're dealing with varying levels of int like uh technical not intelligence but technical awareness for the use case and the user experience of this brow these browsers and also um wanting to uh this this conflict of uh wanting to see this fixed and uh uh you know not not getting in the way of legitimate functionality. I always think you know let's make sure the user I'm of the opinion that we want to this should be an opt-in. Yes, I want

this to be allowed to happen. I have been pushing for this. I think that it this is in its current form an insecure default that should be fixed. Um, and the CVE system actually has a rule that says insecure defaults should be considered vulnerabilities. There are some arguments that are going on there that I need to write a blog post about and it's in my, you know, queue. Um uh yeah so there are differing opinions on this and as security practitioners we will generally aim for can we please lock this down to make it so that people stop shooting themselves in the foot. I mean there's a clearly a long history of shooting yourself in the foot that I

would love to see stop. >> Okay so last question the other ones Jonathan will answer in the front of theater. >> Yeah I'll meet you in the hallway. >> Perfect. So what are you researching next? Uh, >> a good one. >> What am I researching next? Um, uh, I have no idea. Um, I I have this great line. Um, you know, what do you do when I say I do stupid on the internet and I managed to continue to get convince people to pay me. Um, I feel very lucky at that. Um, usually my research tends to be inspired by I mean the Zoom vulnerability for example was I was curious how Zoom let like how that

functionality worked and how it was done securely and the answer was it was not done securely and that was just because I was I was just I was you know like I saw the functionality of click a link it joins to a Zoom call now you're in a Zoom call how is that done? Um that's generally how my research process works. I I I have ADHD. I chase squirrels. Uh, the squirrels turn up nuts. Um, like you know, like I just and I get CVS for it. Um, my brain just works that way, which I feel really fortunate for, but it also gets in my way sometimes. But, you know, um, so I'm curious to find that out,

too, and I'll find that out with you. You can follow me on LinkedIn and you can see the stuff that I post about and some of the posting that I do about the CV system. >> Yeah. >> Okay. Thank you so much. >> Thank you all for coming. I appreciate it.