The Most Dangerous Software May Be the Software You Never Use
Software that sits installed but unused can still become executable attack surface. Security architecture must account for what exists, not only what teams intend to operate.
When organisations assess cyber risk, the conversation usually begins with an inventory.
Which applications are running?
Which services are internet-facing?
Which software versions need patching?
Which systems are considered critical?
That approach makes sense.
After all, you cannot secure what you do not know exists.
But there is another category of software that often receives far less attention.
Software that is installed, present and potentially executable, but never intentionally used.
The recently disclosed OVSwrap vulnerability, CVE-2026-64531, is a useful reminder that forgotten software can still become part of the attack surface.
“We Don’t Use It” Is Not Always A Security Answer
When the OVSwrap issue became public, one understandable reaction was:
“We don't use Open vSwitch, so this should not affect us.”
Unfortunately, security is rarely that simple.
OVSwrap is a local privilege escalation vulnerability involving the Linux kernel's Open vSwitch datapath. Open vSwitch is normally associated with virtualisation, cloud networking and software-defined networking.
The important detail is that the vulnerable component may exist on Linux systems even where administrators never intentionally deployed or configured Open vSwitch.
The technical reporting on OVSwrap highlights exactly why this matters.
Attackers are not interested in whether an organisation intended to use a component.
They are interested in whether that component exists and whether vulnerable code can be reached.
That distinction changes how we should think about attack surface.
Installed Software Is Still Software
Security teams naturally focus on systems they know are active.
Web servers.
Databases.
Identity platforms.
APIs.
Remote access gateways.
These systems are visible.
They appear in inventories.
They appear in architecture diagrams.
They are monitored, patched and regularly reviewed.
But modern operating systems contain much more than the applications organisations actively use.
There may also be:
- optional kernel modules
- dormant services
- compatibility components
- legacy packages
- debugging utilities
- automatically loadable drivers
- software installed as dependencies
Many of these components may remain untouched for years.
Until someone discovers a vulnerability.
At that point, something the organisation never considered part of its technology landscape suddenly becomes part of its security problem.
The Attack Surface Is Bigger Than The Application Inventory
Security architecture often talks about attack surface reduction.
But many organisations still define attack surface around what they intentionally deploy.
The real attack surface is broader.
It includes anything that can potentially execute or become reachable.
A package installed by default.
A driver that can load automatically.
A service disabled today but easily enabled tomorrow.
A dependency inherited from another software package.
A component that nobody remembers installing.
These things may never appear in a project architecture diagram.
Yet they remain part of the environment.
That is why software inventory and attack surface inventory are not exactly the same thing.
An application inventory tells you what you believe you operate.
An attack surface inventory should tell you what an attacker may be able to use.
That is a much more important question.
Local Access Should Not Be Dismissed
Local privilege escalation vulnerabilities are sometimes treated as lower priority because the attacker must already have some level of access.
That assumption deserves more scrutiny today.
Low-privileged execution environments exist almost everywhere.
Containers.
CI/CD runners.
Developer workstations.
Application service accounts.
Automation platforms.
AI agents.
Compromised workloads.
Initial access is often only the first step.
Once an attacker reaches a low-privileged environment, the next objective is usually straightforward:
Gain more privilege.
The OVSwrap discussion is therefore relevant even though the vulnerability is not simply a remote internet exploit.
Local privilege escalation matters because attackers rarely stop after gaining the first foothold.
They look for the next trust boundary they can cross.
Security Architecture Is About Challenging Assumptions
The most important lesson from OVSwrap is not the vulnerability itself.
It is the assumption behind it.
We don't use that feature.
That module is not enabled.
Nobody should have access there.
That service is only available to administrators.
Those statements may all be true today.
But security architecture cannot rely entirely on today's assumptions remaining true forever.
Good architecture asks a different question:
“What happens if this component becomes reachable?”
That mindset is closely related to another principle I discussed in Good Security Architecture Assumes Every Control Will Eventually Fail.
The objective is not to assume that every component is dangerous.
It is to avoid building security around assumptions that have never been challenged.
Reduce What You Do Not Need
One of the simplest security architecture principles is also one of the oldest.
If something is not required, remove it.
If a service does not need to run, disable it.
If a package is unnecessary, uninstall it.
If a kernel module is not required, prevent it from loading where practical.
If an administrative interface serves no business purpose, do not expose it.
This is not glamorous cybersecurity.
There may be no new security product involved.
No dashboard.
No AI.
No sophisticated detection capability.
It is simply attack surface reduction.
And sometimes reducing what exists is more valuable than adding another control to protect it.
This also reinforces a broader theme from Shadow IT Is Not the Problem. Invisible Risk Is: risk becomes harder to manage when organisations do not know something exists.
The same principle applies to software buried deep inside operating systems.
Final Thoughts
Every vulnerability eventually disappears from the headlines.
The architectural lesson should remain.
The most dangerous software is not always the software everyone uses.
Sometimes it is the software nobody remembers installing.
Security is therefore not only about protecting active systems.
It is also about understanding everything within the environment that could unexpectedly become active, reachable or useful to an attacker.
Because attackers do not care what the organisation intended to use.
They care about what is available.
And sometimes the attack surface begins with software you never realised you had.
Question assumptions. Share knowledge. Build trust.
Share this article
If this perspective was useful, share it with your network.