The Problem

<rant>

Why is everyone so insanely terrible at explaining security vulnerabilities? I don’t care how technically clever it is, or how many different steps you had to go through in order to achieve this. Well, that’s not true. I do care actually. I do appreciate a good high-quality vulnerability. But right now, what I want to know is:

  • How bad is this?
  • What is the risk?
  • How fast do I need to deal with this?
  • What is going to happen if someone exploits this?

These are the questions that I need answered if I’m going to decide how fast to fix it. Do I walk? Do I run?

Stylized digital illustration showing two contrasting paths: one path labeled 'WALK' with a relaxed figure strolling, and another path labeled 'RUN' with a figure sprinting urgently. The paths diverge from a central point marked with a vulnerability icon. Use a split-screen composition with cool blues for the 'walk' side and urgent reds for the 'run' side. Modern vector art style with clean lines and strategic use of negative space.

I’m currently dealing with two cases in parallel where I am struggling desperately to understand: What is the problem here? What could actually go wrong?

Case Study 1: The DLL Hijacking That Wasn’t

In the first case, from the initial explanation, I thought it was like DLL hijacking on Windows—where a low-security process could write a malicious DLL file to a location on disk, and the vulnerable application would read that DLL file before it gets to the actual DLL file it should be reading, and therefore execute some code in the context of the application.

Technical illustration showing a Windows file system with DLL files in a directory tree structure. Show a malicious DLL file (in red) being placed in a folder, with an arrow showing it being loaded before the legitimate DLL file (in green). Include folder icons, file paths, and a simplified application icon attempting to load the DLL. Use a clean technical diagram style with a white background, blue system elements, and red/green color coding for malicious vs legitimate files.

Now, yes, that would be bad. That is an understandable outcome.

But no, that’s not quite the case. After much digging, it turns out that the risk is that if an attacker is able to write into the application folder itself, then they can escalate to code execution—effectively escalating a write primitive to a code execution primitive.

Now, that is not ideal. I’d rather that didn’t happen. But it certainly doesn’t require me to run and fix this, especially because the only way of doing this bypasses various other platform-level controls we wouldn’t expect a regular user to be using anyway.

The amount of back and forth it took to discover that that was actually the case was just ridiculous.

Case Study 2: The HTTP Smuggling Mystery

The second case related to a bug bounty with an HTTP smuggling vulnerability—or maybe it was a desync. It doesn’t really matter. I’ve got two levels of triage investigating this to decide whether it’s a real issue or not.

Abstract digital illustration of HTTP request smuggling concept. Show two HTTP requests (represented as stylized data packets or envelopes) being combined or overlapping in an unexpected way, passing through a server/proxy gateway. Use flowing lines to represent data flow, with one request 'smuggled' inside another. Color scheme of purple and cyan for the requests, dark gray for the server infrastructure. Modern tech illustration style with glowing effects and clean geometry.

All I want to know is: What can an attacker actually do in our application with this vulnerability?

I understand how these attacks work. I just want to know what is going to happen in this case. What is the attack scenario? What is the step-by-step?

The Toilet Plunger Parable

In the end, I tried to come up with a parable to try and illustrate to the people in both cases what I am talking about. The parable is as ridiculous as I felt the situation warranted.

  1. The attacker throws a toilet plunger very hard at a wall
  2. It sticks to the wall
  3. The attacker calls the user’s name
  4. The user runs towards the attacker who is standing near the wall
  5. The user runs into the handle and knocks themselves out, Looney Tunes style
  6. The attacker steals the unconscious user’s wallet

Whimsical cartoon-style illustration in the style of Looney Tunes showing a sequence of events: An attacker throwing a red toilet plunger at a wall where it sticks.

Now I don’t care:

  • What the wall is made out of
  • What glue was on the head of the plunger
  • Whether a normal person could throw hard enough to make this work

I just want to understand: What is the attack scenario? What is the series of events that has to happen in order for this to become a problem?

The Bottom Line

I cannot understand for the life of me why people are so bad at explaining this.

When you’re reporting a security vulnerability, please, for the love of all that is holy:

  1. Start with the impact - What can an attacker actually do?
  2. Describe the attack scenario - What sequence of events leads to the bad outcome?
  3. Explain the prerequisites - What access or conditions are needed?
  4. Then, and only then, dive into the technical details

Clean infographic-style illustration showing a numbered pyramid or hierarchy with 4 levels. From bottom to top: Level 1 'Impact' (with shield/explosion icon), Level 2 'Attack Scenario' (with step-by-step arrows icon), Level 3 'Prerequisites' (with checklist icon), Level 4 'Technical Details' (with code/gear icon). Use a professional color gradient from urgent red at the bottom to calm blue at the top. Modern minimalist design with clear typography and iconography.

Your job as a security researcher or engineer isn’t just to find the vulnerability—it’s to communicate it in a way that allows stakeholders to make informed decisions about risk and remediation priority.

The coolest vulnerability report in the world is worthless if nobody can understand what they need to do about it.

Rant over.

For now.

Update 4-Dec-2025: Further to this, Jeff Williams wrote a great article a few years ago about how to report vulnerabilities in a clear way! https://www.linkedin.com/pulse/how-vulnerability-jeff-williams

Updated:

You may also enjoy

What’s going on with (Sem|open)grep?

This post discusses the recent changes in Semgrep, the creation of the Opengrep fork, and the implications for the open-source community.