Mangabats Exposes Every Commenter's Email in Plain Sight

Mangabats is one of those sites where you go to read manga, manhwa, and manhua for free. Millions of chapters, a decent reader, and a comments section under every comic. Standard stuff.

What's not standard is the comments API returning every commenter's email address and phone number in the response body. No authentication. No special headers. Just a plain GET request that anyone can make.

The Vulnerability

If you open DevTools on any comic page with comments and watch the network tab, you'll see requests going to:

https://www.mangabats.com/api/comments/list?commentable_type=comics&commentable_id={comic_id}&page={page}

The response is JSON. Each comment includes a commenter object, and that object contains everything the server knows about the user:

{
  "commenter": {
    "username": "some_user",
    "name": "John Doe",
    "email": "johndoe@gmail.com",
    "phone_number": "+1234567890",
    "is_admin": false
  }
}

The frontend only renders the username and avatar. But the API hands over the full user profile to anyone who asks. No login required. No rate limiting. Nothing.

This is textbook over-exposure. The backend serializes the entire user model into the API response instead of stripping it down to what the frontend actually needs. A select statement or a serializer allowlist would've prevented this entirely.

The Scraper

To demonstrate the scope of this, I wrote a Python script that scrapes every comic on the site and pulls the comment data for each one.

The flow is straightforward:

1. Paginate the manga list. Hit https://www.mangabats.com/manga-list/latest-manga?page={N} and parse the HTML with BeautifulSoup to get comic links and their IDs.

2. Resolve comic IDs. Most comics have a data-id attribute on their list element. When they don't, the script fetches the comic page and pulls the ID from the bookmark button's data-url.

3. Fetch comments. For each comic ID, paginate through the comments API and extract the commenter object from every comment and reply.

4. Deduplicate. Store users by their user ID so each person only appears once in the final output.

The core of it is just a few lines:

params = {
    "commentable_type": "comics",
    "commentable_id": comic_id,
    "page": page
}
response = requests.get(COMMENTS_API, params=params, headers=HEADERS)

I used ThreadPoolExecutor with 5 workers to speed things up since there are thousands of comics to process. The whole thing runs with just requests and beautifulsoup4.

Results

After scraping the entire site:

Metric	Count
Unique users	3,249
Users with emails exposed	3,249 (100%)
Users with phone numbers exposed	25

Every single user who has ever left a comment on Mangabats has their email address sitting in a public API response. The phone number field is optional, so only 25 users had one on file, but for those who did, it's just as exposed.

Some of the phone numbers included international formats from multiple countries. A few users had entered things like "nokia 3310" into the phone field, which is funny, but the ones with real numbers aren't laughing.

Why This Matters

3,249 emails might not sound like a massive breach, but consider:

• Anyone can do this. The script is trivial. You don't need to hack anything. You don't need credentials. You just call a public endpoint.
• The emails are tied to reading habits. Manga piracy sites aren't something most people want linked to their real email. This is the kind of data that's useful for targeted phishing or social engineering.
• Phone numbers make it worse. Even a small number of exposed phone numbers turns this from an email list into something that enables SIM swapping, spam calls, or identity correlation across services.

The fix is simple, stop returning email and phone_number in the comments API response. Serialize only the fields the frontend needs. This is a backend change that would take minutes.

Update: This has since been fixed. The comments API no longer returns email addresses or phone numbers in its responses. The vulnerability was live when I originally tested and scraped the data, but at some point after that, Mangabats patched the over-exposure. The 3,249 users whose data was already publicly accessible for however long it was exposed aren't un-exposed, but at least new comments aren't leaking PII anymore.