Vulnerabilities Are Just Allowed Access Policies

This article was written by Numberline CTO, Jerry Chapman

We keep pretending vulnerabilities are mysterious, unpredictable events, ghosts in the machine that appear out of nowhere. But the longer I have built and broken systems, the more obvious the truth has become: A vulnerability is nothing more than an allowed access policy that nobody realized they wrote.

Every CVE, every zero-day, every “critical” advisory is just a condition the system was never tested against, an implicit allow rule that slipped through development, QA, deployment, and UAT. Not because someone was lazy or malicious, but because the condition simply was not tested. And when a condition is not tested, the system defaults to the most dangerous possible answer: allow.

That is the part we don’t like to admit. It’s the part where we keep having to scramble in reactive mode. It’s the part that’s unnecessarily stressful, and puts our enterprises at risk.

The Daily Struggle: Cleaning Up Unintentional Allow Policies

Every day, defenders find themselves fighting the same battle: discovering and mitigating the “allow” rules that were never meant to exist. CVEs and Zero-days are the same thing: allow policies nobody knew were there. Supply-chain compromises are allowed execution paths and privilege escalations are allowed transitions between trust levels.

We do not have a vulnerability problem, we have an unbounded allow-surface problem and the only reason attackers win is because they find the allow rules before we do.

Example 1: SolarWinds, the Egress Policy Nobody Wrote

When SolarWinds Orion was compromised, the injected SUNBURST backdoor did not magically teleport data out of the environment. It did not brute-force its way through a firewall. It did not break TLS. It simply made outbound HTTPS connections to attacker-controlled domains, and the network said: “Sure, go ahead.” That is the unspoken truth: the breach succeeded because Orion was allowed to talk to unknown, unexpected destinations on the Internet.

If a Zero Trust egress policy had been wrapped around Orion, even something as simple as restricting it to SolarWinds update endpoints and internal systems while denying all other outbound Internet traffic, then the malicious update still would have installed, the backdoor still would have executed, but the exfiltration step would have slammed into a wall.

The vulnerability was not just the malicious code, it was the untested allow policy: “Orion can talk to anything on the Internet.”

Example 2: A Modern Supply-Chain Breach, Trivy and Default Allow

A recent case is the Trivy supply-chain compromise of March 2026. Threat actors poisoned 76 of 77 GitHub Action tags, pushed trojanized binaries to Docker Hub and GHCR, harvested secrets from CI/CD pipelines, and exfiltrated them to attacker infrastructure. The exfiltration was not theoretical. During the 3 to 12 hour exposure windows across distribution channels, real victims lost API tokens, cloud credentials, SSH keys, Kubernetes tokens, and Docker configurations before maintainers could revoke the malicious artifacts.

Why did it work? Because CI/CD runners across the industry are typically granted full outbound Internet access. That is the real vulnerability, not the malicious code, stolen credentials, nor the poisoned tags. The real vulnerability was the implicit allow policy: “CI/CD runners may exfiltrate secrets to any domain they want.“ This may not have been an explicitly defined policy, but it was certainly implicit!

A default-deny egress policy would have killed the primary exfiltration channel, which used a typosquatted domain (scan.aquasecurtiy[.]org). Allow only registries, artifact stores, and vendor APIs, deny everything else and log every blocked outbound attempt.

The harder lesson is in the fallback channels: the attackers also routed data through an ICP blockchain canister and Google Forms, precisely because legitimate SaaS endpoints defeat naive allowlists. The next generation of egress control needs to inspect not just the destination, but the behavior. A build runner posting form-encoded payloads to Google Forms is not normal traffic, even if google.com sits on the allowlist.

The Result? Malware still runs and steals secrets locally, but containment shrinks the blast radius from global compromise to noisy local incident.

Example 3: Linux Privilege Escalation, the su Path That Should Never Have Been Allowed

Take the recent Linux kernel LPE known as Fragnesia (CVE-2026-46300), disclosed on May 13, 2026. This one is particularly elegant and dangerous. The root cause is a logic flaw in the networking subsystem. When the kernel coalesces socket buffer fragments, it fails to preserve a flag that marks certain pages as shared with the page cache. The impact is what gets attention: an unprivileged local user can write arbitrary bytes into the in-memory page cache of read-only binaries, including /usr/bin/su. The attacker effectively rewrites su in memory so that invoking it drops a root shell.

But again, the kernel bug is only half the story. The real vulnerability is the chain of allow policies that must already exist around it: allowing untrusted users to obtain interactive shells on the host, allowing those users to execute su or other privileged binaries, and allowing the host, once compromised, to reach sensitive internal systems.

Zero Trust cannot patch the kernel. But it can eliminate the conditions that make the kernel bug meaningful. It can keep untrusted users off sensitive hosts and eliminate direct “su” in favor of tightly scoped sudo with MFA and logging. Use a tool (PAM integration) to restrict execution paths and bind downstream access to identity, so that even root on the box is not enough to move laterally.

So What Do We Do?

We stop pretending we can test every condition, eliminate every bug, and predict every exploit path. Instead, we focus on the only thing we can control: we aggressively shrink the implicit allows. That means default-deny egress everywhere, identity-bound access to every resource, explicit allow-lists for system-to-system communication, no implicit trust transitions whether local or network, and continuous testing of what happens when a component tries to do something it should not.

The Path Forward: AI-Assisted Allow Surface Testing

If vulnerabilities are just allow policies we did not know we wrote, the answer is to find them before the code ships. Human review cannot enumerate every implicit trust transition in a modern system. A single microservice with a dozen dependencies and a pipeline touching forty-seven external endpoints has an allow surface no architect can hold in their head.

AI belongs in the pre-release pipeline as an autonomous testing layer. An agent that models the system the way an attacker does: enumerating reachable destinations, mapping privilege transitions, and asking the one question we keep forgetting: “What is this component allowed to do that nobody intended?”. And making the necessary changes to the underlying code, then also documenting and pre-hardening deployment configurations and guides.

Make it a part of the CI, release gate, and feed every unintended allow rule it surfaces back into policy as code before the artifact is signed. The team that disclosed Fragnesia credited agentic AI tooling,V12-Security, for accelerating their discovery cadence. If we do not match that pace, manual review stops being a security control and becomes a delay tactic.

Find the allow policies, test them, deny them, and ship it!

---

Want these in your inbox? Subscribe for free and receive every new posts via email at: https://absolutezerotrust.substack.com/

Want to learn more about how our Zero Trust Blueprint can help you define and enforce default-deny access policies?
Sign up for a free 30-minute briefing here.