Rosecurify

Two CVEs, Zero Ego: A Mailpit Story

Today I want to share a positive experience from security research, not the "dark side" but the collaboration and mutual respect side. I found two vulnerabilities in Mailpit and how the maintainer and I worked together to fix them.

As security researchers, we sometimes get perceived as the "bad guys." But our job is actually making software more secure and helping developers. And you know what the most critical part is? Communication.

My experience with Ralph Slooten, the Mailpit maintainer, was a textbook example of how responsible disclosure should work.

What is Mailpit? #

Mailpit is a lightweight email testing tool designed for development environments. It works as an SMTP server, catches incoming emails, and lets you view them through a web interface. Written in Go, single binary, fast and handy. You can easily run it with Docker too. In short: an awesome tool that lets you test email flows without actually sending real emails in development.

Technical Details: What Did We Find? #

1. Server-Side Request Forgery (SSRF) - CVE-2026-21859 #

The first vulnerability was a classic SSRF case. Mailpit's /api/v1/proxy endpoint wasn't validating user-supplied URLs properly. What does that mean?

GET /api/v1/proxy?url=http://169.254.169.254/latest/meta-data/ HTTP/1.1
Host: mailpit.target.com

With this simple request, you could access AWS metadata endpoints. Meaning you could reach internal network resources, databases, and APIs through a Mailpit instance running in the cloud.

Fix: v1.28.1

2. Cross-Site WebSocket Hijacking (CSWSH) - CVE-2026-22689 #

The second vulnerability was more interesting. Mailpit's WebSocket server was accepting connections from any origin. The code looked like this:

var upgrader = websocket.Upgrader{
    CheckOrigin: func(r *http.Request) bool {
        return true  // Everyone's welcome! 
    },
}

What does this mean? An attacker could run malicious JavaScript on their own site, establish a WebSocket connection to the victim's Mailpit instance, and steal all email contents in real-time. No authentication required.

Fix: v1.28.2

Communication with the Maintainer: This is Where it Matters #

First, I emailed Ralph and suggested he enable GitHub Security Advisories. He enabled it right away! Then I reported the vulnerabilities through there and the process moved incredibly fast. The nice thing about this approach:

  • We could communicate securely through a private channel
  • Vulnerabilities were quickly validated and acted upon
  • CVE processes went smoothly

Note to developers: Keep GitHub Security Advisories enabled! It's the safest and most professional way for security researchers to reach you.

What impressed me most while working with Ralph: zero ego. I reported the vulnerability, he accepted it straight away, no "is this really a vulnerability?" type questions. We discussed together, he asked questions, took my input. Everything was fixed in 2-3 days. That's how simple it should be, really.

Takeaways #

  1. Keep GitHub Security enabled, developers need a secure communication channel
  2. Leave ego at the door, vulnerability reports from whitehat hackers aren't personal attacks, they're contributions
  3. Work together, researcher and developer are on the same team
  4. Act fast, protecting your users is your responsibility

As security researchers, our goal isn't to break software, it's to make it more secure. Developers like Ralph make this process enjoyable.

By the way, special thanks to Ralph for being a sponsor on GitHub.

See you in the next post! : >