The Bug Did Not Arrive Wearing a Hoodie
Some bugs are loud. They crash the app, throw angry errors, and basically shout, “Hello, I am broken. Please investigate me.”
This one was different.
This bug walked in quietly, wearing a tiny colon in its name, and somehow convinced the security guard that everything was fine.
That tiny colon eventually became CVE-2026-40893.
The Place Where The Story Begins
The project was Gotenberg, an open-source tool used to convert documents, HTML, and other files into PDFs. Under the hood, it can use a tool called ExifTool to read and write metadata.
Metadata is the extra information inside a file. For example, a PDF or image may contain things like title, author, creation date, and other details. Most of the time, metadata is boring. Very useful, but boring. Like a spreadsheet with better PR.
But some metadata fields are not boring at all.
ExifTool has special fields such as FileName and Directory. These do not just describe a file. They can rename it or move it.
So Gotenberg did the sensible thing: it blocked dangerous fields.
The idea was simple:
- If someone sends
FileName, block it. - If someone sends
Directory, block it. - If someone sends other dangerous file-moving fields, block those too.
That sounds reasonable. The bouncer has a list. The bouncer checks the names. The bouncer keeps trouble outside.
Except trouble brought a fake mustache.
The Tiny Detail
While looking at how ExifTool understands metadata names, I noticed something important: ExifTool allows group prefixes.
In simple words, ExifTool can understand a tag like this:
System:FileName
To a normal string comparison, System:FileName and FileName are different.
But to ExifTool, they can still point to the same dangerous action: rename the file.
That was the whole trick.
Gotenberg was checking the exact name. It was asking, “Is this exactly FileName?”
The answer was no, because the value was System:FileName.
So the input passed the check.
Then ExifTool received it and said, “Ah yes, FileName. I know what to do.”
And just like that, the file could be renamed.
It was like telling a nightclub bouncer:
“Do not let John in.”
Then John arrives and says:
“Actually, I am System:John.”
And the bouncer says:
“Understandable. Have a great night.”
Security is fun until the bouncer learns string comparison.
Why This Was Serious
This was not just a small display issue. It affected how files were handled on the server.
The advisory was rated High severity with a CVSS score of 8.2.
The affected package was gotenberg/gotenberg, and the issue was classified as CWE-20: Improper Input Validation.
In plain English, the application accepted input that looked safe to its own check, but was still dangerous to the tool that processed it later.
That difference matters a lot.
One part of the system said, “Looks fine.”
Another part of the system said, “Time to move files.”
That is not teamwork. That is a group project where one member did not read the assignment.
The Missing Piece
There was another small finding too: FilePermissions was not blocked.
That means file permissions could also be changed through metadata handling.
Again, the big lesson was the same: when an application passes user input to a powerful tool, it must understand that tool properly.
If the tool supports aliases, prefixes, case-insensitive names, or special behavior, the validation must account for that.
Otherwise, the validation is not really protecting the system. It is just standing there with a clipboard.
Responsible Disclosure
After confirming the issue, I reported it responsibly through GitHub Security Advisory.
The vulnerability was published as GHSA-62p3-hvxx-fxg4 and assigned CVE-2026-40893.
The affected versions were Gotenberg <= 8.30.1.
The patched version is 8.31.0.
Seeing my name listed as the reporter was a proud moment. Not because “I broke something,” but because the report helped make an open-source project safer for everyone using it.
That is the good side of security research.
You find the sharp edge, report it carefully, and help someone sand it down before users get hurt.
The Real Lesson
The most interesting part of this CVE is that it was not some movie-style hacking scene.
No dark room. No green text raining on the screen. No dramatic music. Sadly, no hoodie sponsorship either.
It came from reading code, reading documentation, and asking one simple question:
“Does the application understand this input the same way the downstream tool understands it?”
That question is powerful.
Because many security bugs live in the gap between two systems.
The web app thinks one thing.
The library thinks another thing.
The operating system does something else.
And attackers love those gaps.
Final Thought
CVE-2026-40893 was a reminder that small details can have big impact.
In this case, the small detail was a colon.
Just one little :.
Tiny character. Big attitude.
Security is often not about finding the biggest, loudest bug. Sometimes it is about noticing the quiet little thing sitting in the corner, pretending it belongs there.
And sometimes that quiet little thing gets a CVE number.