Most of the software your vendors ship you was never written from scratch. It was forked. Open-source code taken, modified, and built into the product you deploy.
When a vulnerability is found in that original library, that fork becomes your blindspot. The CVE names the original project. Every scanner checks the original project. But your vendor ships a modified version with a different name, different code, a different lineage. No advisory covers it. No scanner flags it. There is no process, anywhere in the security industry, that connects a published vulnerability to the fork carrying the same vulnerable code.
This is the problem that has never been solved.
The Code Behind the Code
Almost every enterprise software vendor builds on open-source. Not by using it directly, but by taking it, modifying it for their use case, integrating it into their product, and shipping it as part of what you buy. A networking vendor forks an open-source SSL library and adds custom certificate handling. A cloud platform forks a logging framework and strips out the parts they don’t need. A security tool takes an open-source parser, rewrites core functions, and ships it inside their product.
The fork is never disclosed. It doesn’t appear in vendor documentation. It doesn’t show up in a questionnaire. There is no standard that requires a vendor to tell you they forked a component, what they changed, or how far the code has diverged from the original.
You deploy the software. Somewhere inside it, a modified version of an open-source library is running. You have no idea it’s there, which version it started from, or what the vendor changed. And when a vulnerability is found in the original library, neither do they.
It goes deeper than that. The library your vendor forked was likely itself a fork of another project. Open-source code forks open-source code constantly, with no rules, no disclosure requirements, no central registry tracking what came from where. It’s a chain of modifications with no governance at any level, and your vendor’s software sits somewhere in the middle of it.
A CVE With No Address
Every vulnerability advisory is written for the original project: the package name, the affected version range, the fix. Every scanner uses that advisory to do one thing: match the name and version in your environment against the name and version in the database.
A fork breaks that match entirely. The vendor renamed the library. The version diverged. The advisory was written for the original, not for your vendor’s modified copy. No scanner flags it. No advisory lists it. There is literally no mechanism, in any tool or any process that exists today, to connect a CVE against the original to a fork that contains the same vulnerable code.
This isn’t a gap that better tooling can close. Every vulnerability management system ever built relies on the same assumption: that a name and version uniquely identify a piece of code. Forking destroys that assumption. The scale is staggering. Researchers traced over three million vulnerabilities copied across more than 700,000 projects, invisible to every scanner because none of them carried the original package name. Only 1.3 percent were ever remediated.
Meanwhile, attackers don’t need to trace fork chains. They see a CVE, use AI to generate a working exploit in hours, and probe vendor products directly. If the fork carried the vulnerability, the exploit works. They never needed to know it was a fork. You’re left trying to connect a CVE to modified code through metadata that was never designed to track it. They’re already testing whether you’re vulnerable.
Chrome Got the Fix. Slack Didn’t.
In 2025, a type confusion vulnerability in Google’s V8 JavaScript engine was discovered being actively exploited in the wild. CISA added it to the Known Exploited Vulnerabilities catalog. Google patched it in Chrome. Security teams pushed the update. The ticket was closed.
Except the CVE advisory said “Google Chrome.” It didn’t say Slack. It didn’t say Discord, or 1Password, or Cursor, or VS Code, or the dozens of other enterprise tools built on Electron, a framework that forks and bundles its own version of Chromium. Every one of those tools embeds its own copy of the same engine. None of them are named in the advisory. None of them are updated when Chrome is patched. Each one has to independently pull the fix into their own forked codebase, test it, and ship a new release, on their own timeline, with no requirement to disclose when they do.
Organizations that did everything right, patched Chrome immediately, closed the CISA alert, were still running the vulnerable engine inside tools sitting open on every developer’s machine. The scanners saw a patched Chrome install and reported clean. The forks carrying the same vulnerable code were invisible.
TARmageddon tells the same story at the library level. When a critical remote code execution vulnerability was disclosed in async-tar, a widely used Rust library, the upstream maintainers patched it. But the most popular fork, tokio-tar, with over five million downloads and no active maintainers, will never get the fix. No advisory names it. No scanner flags it. Every project that depends on tokio-tar inherited the vulnerability and has no way of knowing.
What Maze Does About It
The fork problem has one root cause: every security tool identifies vulnerable software by its label: the package name, the version string, the advisory entry. Forks change the label. The match breaks. The vulnerability disappears from every dashboard, every report, every alert.
Maze doesn’t use the label. It analyzes software at a level no other tool reaches. No source code required. No vendor cooperation needed. When a CVE drops against an upstream project, Maze looks for the vulnerable code itself, not the name attached to it. A renamed fork, a vendored copy, a library modified beyond recognition. If the vulnerable code is there, Maze finds it. And it gives your team clear remediation steps without waiting on a vendor who may not even know the open-source code they forked years ago and modified ever since is carrying a vulnerability.
Maze Dex continuously scans over 1,000 vendors — covering the forked and modified components buried in vendor software that no other tool can see into.
The code your vendor forked years ago is still running in your environment. So is the vulnerability it carried. No tool has been able to see it — until now.