content warning: this post mentions csa in the context section. skip to “view source” if you want to avoid that.
how i got here #
so i was investigating something completely different.
there’s a mastodon instance that’s… well. let’s say it hosts content that normalizes harm to children. i was trying to figure out who runs it, what infrastructure they use, how to report them.
the usual stuff. whois, dns lookups, checking their impressum.
german law requires websites to have an impressum - your real name and address, publicly visible. people who don’t want stalkers, me included, use “impressum services” that let them list a c/o address instead.
this particular site used one called versteckmich.de. “hide me.” cute name.
so i went to look at their impressum page.
view source #
i don’t even remember why i opened view-source. probably habit. probably checking if there was any metadata i could use.
and then i saw it.
the entire database record. right there. in the html.
not just what was displayed on the page. everythign. the billing name. the billing street. the billing city. the paypal subscription id. the bcrypt password hash.
you know. the home address they were specifically paying to hide.
wait what #
okay so versteckmich.de - you’re a streamer, youtuber, etc.
so you pay this service ~50€/year and they let you use their address. “c/o SourceArt, Tuttlingerstraße 45, 78333 Stockach” - a legitimate mail forwarding service. your real address stays private.
except. when you went to versteckmich.de/username, the page source contained:`
"billingName": "Peter [REDACTED]",
"billingStreet": "[REDACTED]straße 14",
"billingZip": "2****",
"billingCity": "[REDACTED]",
"password": "$2b$12$s1a41lj7...",
"paypalCustomerId": "3BH**********"
for every. single. customer.
their homepage says “1000+ Creator vertrauen uns”. if true, that’s a lot of ppl whose home addresses were sitting in publicly accessible html.
how #
next.js. that’s how.
if you’re not a web dev: next.js is a react framework. it does server-side rendering. the server generates html, sends it to the browser, and then react “hydrates” it - takes over and makes it interactive.
what they probably did:
// fetch the entire user profile from the database
const profile = await prisma.profile.findUnique({
where: { username },
include: {
user: {
include: { subscription: true }
}
}
});
// pass it to the component
return <ProfilePage profile={profile} />;
next then serializes that entire object into the html for hydration. every field.
what they should have done:
const { creatorName, displayAddress, publicBio } = await getPublicProfile(username);
return <ProfilePage profile={{ creatorName, displayAddress, publicBio }} />;
kind of like when you console.log an object during debugging and you see way more fields than you expected? imagine doing that to production. to every page load. for a privacy service.
the red flags were everywhere #
once i found this, i started looking at the rest of their setup. and hoo boy.
no rate limiting. i wrote a quick script to hit their server 1000 times parallelized. all 200 OK. no throttling, no captcha, nothing. you could scrape every customer’s home address in an afternoon.
origin ip exposed. they use cloudflare for dns but not the proxy. their hetzner server ip is right there. no WAF, no edge protection.
the vibes. #
just look at this:
you know what this looks like. it’s what you get when you prompt “create a modern landing page for a privacy service” and ship the first result.
their emails had the same energy. “KI-gestützte Prüf- und Erkennungssysteme”. enterprise words strung together.
none of this proves anything on its own. but you know the vibe when you see it.
the vibecode problem #
this has been stuck in my head since i found it.
ai makes it trivially easy to build something that looks professional. you can ship a whole saas in a weekend now.
but the llm won’t tell you what data you’re accidentally sending to the client.
the code that caused this bug probably worked fine. it displayed the right information on the page. the tests passed (if there were tests). the feature was complete.
but nobody thought about what data was actually being serialized. that requires understanding the system. llms help you make things work, they don’t help you understand what you’re building.
and now we have a generation of services built by people who can ship but can’t threat model.
i use ai constantly - mostly to point me in directions, write me a regex, or deal with bureaucratic letters when i don’t have the energy. but i also know what a next.js hydration payload is. i know to check what data i’m serializing. the person who built this service apparently didn’t, or didn’t care to check, and the llm didn’t flag it either.
what to watch for #
so if you’re trusting a service with sensitive data:
ai vibes. sleek landing page + zero track record + launched last month = maybe don’t give them your home address. if support emails read like chatgpt, the code might too. “enterprise-grade security” from a startup with no security page is a yellow flag.
you can usually tell.
the disclosure #
i sent them a responsible disclosure on december 15th. (my very first one! that was scawy.)
detailed the vulnerability, provided examples, suggested fixes.
they fixed it within 24 hours. no defensiveness, no “we take security seriously” corporate non-response, no weeks of silence. just fixed it.
was a bit scared it could have taken weeks and involved lawyers. these folks just patched it. so kudos.
the wayback machine had already crawled a few leaked profile in october, so the vuln existed for at least two months. but it’s closed now.
anyway #
an address-hiding service that exposed every address. found by someone who was just trying to figure out who runs a pedo website.
the internet is weird.
i’m not naming the original site i was investigating yet. that’s a different story, still ongoing. versteckmich.de is fixed.