You trust software to keep your data safe. When a vulnerability is found, you expect it to be fixed, especially if it's a serious risk like remote code execution (RCE) or unintended data exposure. But what if the developers decide that the risk is acceptable? What if they patch the easy problems like a one-line SQL injection fix, giving the illusion of security, while leaving a gaping hole because it would require real effort?
That's the reality of "intended behavior" flaws. These aren't bugs; they're deliberate design choices that put users at risk. And the worst part? The people who write the software get to decide which risks are worth fixing, which ones they'll ignore, and which ones they will tell you about.
I've seen this play out more than once.
The Module Upload Function
A seemingly harmless admin upload feature allows modules to be added; but with strategic manipulation, it becomes a full remote code execution (RCE) vector. When provided with a completely automatic proof of concept demonstrating the criticality, the response was: "the ability to upload modules has long been a feature of REDACTED, and bad modules can do bad things" The irony? They issued CVEs for that same admin interface for command injection, SQL injection, and several others. If those were vulnerabilities, why isn't the module upload RCE? And if there was already a free ticket to full system compromise, why fix the others at all?
The Web Administration Tool
A config editor in a web administration tool, meant for legitimate use, can be weaponized for RCE. I submitted a detailed report with a working exploit, and the initial response was promising: "well that's a basic php setting any admin/root-user could set/use ... what's your idea to "fix" that?" Since the answer was complicated, the next response said "this is a system-manangement-panel and of course it's in its nature to have "dangerous" settings that can harm the server" and the issue was closed. Later, when I asked if I could use this example in my research, I was met with: "So do you also publish that on any linux system, as privileged user, you could run rm -rf /"
The implication was clear: if it wasn't an easy fix, it was a feature. The maintainer previously issued a CVE for that admin portal for command injection... so why does this RCE flaw not count? Perhaps because that one was a one-character change and didn't require any real effort.
The AI Knowledge Base Leak
A widely used AI/LLM system allows users with access to the model to extract and reconstruct its entire knowledge base, in some cases without even querying the chat endpoint; when reported, maintainers insist this is "intended behavior." While other parts of the system correctly restricted direct file and knowledge base access, a specialized proof of concept can still easily reconstruct all the files. Worse yet, there is no warning for users, and they claim that this does not cross the security boundary.
A Systemic Problem
These aren't edge cases; they're symptoms of a deeper problem. When features are hard to secure, even well-meaning ones can become liabilities. The real question isn't just "How do we fix this?" but "Why are these "intended behavior" vulnerabilities allowed to exist without properly notifying users or security teams?" Until developers, maintainers, and businesses recognize that "intended behavior" doesn't always mean "safe behavior," these flaws will keep silently existing in our software.
The dismissive slight: "Do you publish rm -rf / as a research finding?" wasn't just a rhetorical jab; it was a reminder of who holds the power in this system. Maintainers and corporations, not researchers, ultimately decide what qualifies as a vulnerability and whether it's worth fixing. If a flaw is deemed "too complicated" or "not severe enough," it gets closed, sidelined or ignored, and never mentioned to users. Then those exact flaws end up being chained with credential compromise or authentication bypass, leading to full system compromise.
It isn't simply whether these flaws are vulnerabilities or features. It's whether we're okay with developers, maintainers, and corporations unilaterally deciding which risks are acceptable; and who gets to pay the price when they're wrong. It's the users whose data gets stolen. The businesses that face lawsuits. The researchers whose warnings are dismissed. And the public is left to clean up the mess when "intended behavior" becomes a liability.
The current model relies too heavily on goodwill and profit motives, which aren't always aligned with public safety. Perhaps it's time for external oversight, whether through regulation, standardized reporting frameworks, or even government-mandated audits; to ensure that "intended behavior" doesn't become a loophole for neglect.
Because if we don't change the system, the only thing that's certain is that the next vulnerability won't be the last. And the next time, it might be your data on the line.