Three Security CVEs: Small Mistakes, Big Consequences
Brief breakdown of three CVEs I found in Mailpit, Deno, and Fast-JWT — and how tiny oversight leads to security vulnerabilities.
Finding a security vulnerability is often less about complex exploits and more about finding that one "oops" moment in the code. Over the last few months, I’ve had the chance to report several CVEs in popular open-source projects.
Instead of a long, dry security report, here is a short, human-friendly summary of three of my favorite finds and the simple logic that made them possible.
1. Mailpit: The "Link Check" SSRF
GHSA ID: GHSA-mpf7-p9x7-96r3
Mailpit is a great tool for email testing. It has a feature that lets you "check" links in an email to see if they're alive. The problem? The server was doing exactly what I told it to.
If I told it to check a link pointing to http://localhost:8080/admin, it would happily make that request. Since the server is usually sitting inside a protected internal network, this allowed me to "reach through" the server and talk to internal services that were never meant to be exposed to the public internet.
Lesson: Never trust a URL provided by a user without strict validation against an allowed list of domains and IPs.
2. Deno: Bypassing the Blocklist
GHSA ID: GHSA-4c96-w8v2-p28j
Command injection is a classic vulnerability, and modern runtimes like Deno have strong protections against it. But when Deno tried to fix a previous command injection bug, it missed a small edge case in how shells expand variables.
By using the subshell syntax $() (e.g., $(touch pwned)), I was able to execute arbitrary commands even though the primary command was supposedly "blocked." It was a classic case of an incomplete fix — a reminder that shell metacharacters are a minefield.
Lesson: Blocklists are almost always a losing game. It’s better to use safer APIs (like passing arguments as an array) rather than trying to sanitize a shell string.
3. Fast-JWT: The Whitespace Trick
GHSA ID: GHSA-mvf2-f6gm-w987
JWT (JSON Web Token) security depends entirely on the algorithm and the key used to sign it. In fast-jwt, there was a check to ensure that the public key being used was actually an RSA key. It used a regular expression that looked for a line starting with -----BEGIN PUBLIC KEY-----.
The regex used a ^ (start of string) anchor. However, I found that by adding a single space or a newline before the key content, the regex would fail to match, allowing me to trick the library into using "Algorithm Confusion." This let me forge valid tokens by treating a public key as a HMAC secret.
Lesson: A single space can be the difference between a secure system and a wide-open vulnerability. Always trim or normalize input before validating it with regex.
Searching for bugs is a game of patience and finding where the developer's assumptions diverged from reality. Whether it's a whitespace character, an overlooked shell expansion, or a overly-helpful "link checker," the smallest details are usually where the most interesting bugs reside.
Happy hacking!