# Virtual Patching with Access Proxies: Shield Systems You Cannot Patch Yet

Source: https://adaptive.live/blog/virtual-patching-with-access-proxies
Published: 2026-11-05T00:00:00.000Z
Updated: 2026-11-05T00:00:00.000Z
Author: Adaptive Team
Category: General

Learn what virtual patching is, why the patch window keeps widening, and how Adaptive's database, SSH, Kubernetes, web and MCP proxies can block an exploit path before the vendor fix is installed.

**Virtual patching blocks the exploitation of a known vulnerability without changing the vulnerable system.** [OWASP defines it](https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html) as "a security policy enforcement layer which prevents and reports the exploitation attempt of a known vulnerability." The vendor patch fixes the code. The virtual patch changes what is allowed to reach the code while the patch is tested, scheduled, or still being written.

The window it has to cover is widening at both ends. According to [Mandiant's M-Trends 2026](https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026), exploits were the most common initial infection vector for the sixth year running, and the mean time to exploit was an estimated negative seven days: exploitation typically began before a patch existed. [Verizon's 2026 Data Breach Investigations Report](https://www.verizon.com/business/resources/reports/dbir/) found that only about a quarter of CISA Known Exploited Vulnerabilities were fully remediated during 2025.

Most virtual patching tooling sits at the web edge: a web application firewall (WAF) or intrusion prevention system (IPS) in front of a public website. Databases, SSH hosts, Kubernetes clusters, internal consoles and MCP servers rarely have an equivalent. Adaptive brokers every connection to those systems through its own proxy, and that proxy already parses the queries, commands, API requests and tool calls passing through it. A policy that denies the specific statement, command, path or tool an exploit needs is a virtual patch applied at one point, for every identity, without touching the vulnerable system.

*Published November 5, 2026. Statistics and vulnerability details are attributed to their sources. The proxy-based patterns and validation steps below are Adaptive's analysis.*

## What is virtual patching?

A virtual patch is a rule enforced somewhere between the attacker and the vulnerable code. OWASP's cheat sheet notes that the technique is also called "external patching" or "just-in-time patching," and that the enforcement layer is typically a WAF or web server plugin such as ModSecurity that analyzes transactions and intercepts attacks in transit, so malicious traffic never reaches the application.

Three properties separate it from a real patch:

- **It does not change the vulnerable software.** The flaw stays in place. Only the traffic that can trigger it is filtered.
- **It is fast to deploy and fast to remove.** A rule can be written in hours and retired the day the patch lands, with no reboot and no release train.
- **It is a compensating control.** It reduces risk until remediation. It is tracked as residual risk, not closed as fixed.

| At a glance | Vendor patch | Virtual patch |
| --- | --- | --- |
| What changes | The vulnerable code | The policy on traffic that reaches it |
| Where it lives | On every affected host | At one enforcement point, applied to many hosts |
| Lead time | Vendor release, testing, change window | Hours, once the exploit path is understood |
| Downtime | Often needs a restart or maintenance window | None for the protected system |
| Residual risk | Removed for that CVE | Remains; exploit paths the rule misses still work |
| Lifetime | Permanent | Temporary, retired once the patch is applied |

OWASP also notes that virtual patching is ideally suited to injection-type flaws and may not provide adequate attack surface reduction for every category. A rule can block a malformed command. It cannot fix a flawed business decision that looks like normal traffic.

## Why can't teams simply patch faster?

OWASP's cheat sheet lists the reasons organizations cannot edit vulnerable code immediately: lack of resources, third-party software they do not control, and outsourced development. Mission-critical systems add another: some cannot be taken offline on a vendor's schedule. [SQL Server 2016 left extended support in July 2026](https://www.neowin.net/news/microsoft-ends-support-for-sql-server-2016-but-admits-that-it-is-still-heavily-deployed/) while Microsoft acknowledged it remained heavily deployed. Every unsupported database engine, appliance or embedded system is a permanent patch gap by definition.

The numbers describe how wide the gap is:

| Measure | Figure | Source |
| --- | --- | --- |
| Share of intrusions where an exploit was the initial vector | 32% | [Mandiant M-Trends 2026](https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026) |
| Mean time to exploit, relative to patch release | About -7 days | Mandiant M-Trends 2026 |
| Share of breaches that began with vulnerability exploitation | 31% | [Verizon 2026 DBIR](https://www.verizon.com/business/resources/reports/dbir/) |
| KEV entries fully remediated during 2025 | 26%, down from 38% | [Verizon 2026 DBIR, as analyzed by Qualys](https://blog.qualys.com/vulnerabilities-threat-research/2026/05/19/inside-the-2026-verizon-dbir-what-one-billion-records-revealed-about-vulnerability-remediation) |
| Median time to fully remediate a KEV | 43 days, up from 32 | Verizon 2026 DBIR, as analyzed by Qualys |
| KEVs with exploitation evidence on or before CVE publication, 2025 | 29% | [VulnCheck State of Exploitation 2026](https://www.vulncheck.com/blog/state-of-exploitation-2026) |

Read together: an exploit often exists before the patch, the patch takes weeks to reach every host, and a large share of known-exploited flaws are never fully closed. The question for a security team is not whether a gap exists but what sits inside it.

## Where can a virtual patch be enforced?

The enforcement point decides what a rule can see. A network firewall sees addresses and ports. A WAF sees HTTP. A database proxy sees SQL. Each layer can only block what it can parse.

| Enforcement point | What it parses | Typical coverage |
| --- | --- | --- |
| Network firewall or IPS | Packets and signatures | Exposure reduction, known exploit signatures |
| WAF or reverse proxy | HTTP requests | Public web applications and APIs |
| Kubernetes admission controller | Resource manifests | Objects created through the API server |
| Host configuration | Daemon settings | Single-host mitigations such as a disabled feature |
| Access proxy or broker | Database wire protocols, SSH sessions, kubectl calls, HTTP, MCP | Internal infrastructure reached by people, services and agents |

The first four are well established. The fifth is the one most organizations do not have. Internal protocols such as the PostgreSQL wire protocol, Redis commands, SSH sessions and MCP tool calls usually travel from a client straight to the server with nothing in between that understands the conversation. An identity-aware access proxy is the inline point that does.

## How do Adaptive's proxies apply a virtual patch?

[Adaptive brokers every connection through its own proxy](https://adaptive.live/product/access), so the downstream credential never reaches the person, service or agent using it. Users authenticate with SSO and MFA, receive a role that scopes what they can do, and work in a recorded session. Because the proxy parses the protocol, [preventive policies](https://adaptive.live/product/monitor) can block or restrict a statement in real time, [authorization profiles](https://adaptive.live/product/authorization) can constrain which commands run on a virtual machine or what can be reached inside a Kubernetes cluster, and [MCP access](https://adaptive.live/product/mcp) can be limited to specific tools.

A virtual patch on the broker uses four mechanisms, in increasing order of how closely the exploit traffic resembles legitimate work:

1. **Remove exposure.** The vulnerable service accepts connections only from the broker. [Zero trust network access](https://adaptive.live/product/zero-trust-network-access) builds ephemeral tunnels to the resource, so an unauthenticated attacker on the network never reaches the listener. This covers pre-authentication bugs, where no rule on session content helps because the exploit happens before the session exists.
2. **Deny the trigger.** When the exploit needs a specific command, statement, verb, path or tool, a preventive policy denies it for everyone, or for everyone outside a named role.
3. **Gate the risky path.** When the feature cannot be removed, keep it behind [just-in-time approval](https://adaptive.live/product/authorization), a short grant and a recorded session. The feature stays available for approved work and unavailable to an attacker holding a stolen session.
4. **Detect and terminate.** For traffic that cannot be distinguished in advance, [audit records](https://adaptive.live/product/audit), [anomaly detection](https://adaptive.live/product/anomaly-detection), live session termination and [SIEM streaming](https://adaptive.live/product/siem-and-alerting) shorten the time between misuse and response.

The examples below map real vulnerabilities to those mechanisms. Each one is a pattern to adapt, not a claim that the vulnerability is closed. Verify which commands and paths each integration parses in your deployment before relying on a rule.

### Databases: deny the statement the exploit needs

[CVE-2025-49844](https://www.sysdig.com/blog/cve-2025-49844-redishell), known as RediShell, is a critical use-after-free in Redis's Lua engine. An authenticated client sends a crafted Lua script, escapes the sandbox and executes code on the host. Lua scripting is on by default, so every unpatched instance is exposed to any client that can authenticate. The published interim mitigation is to restrict the scripting commands with Redis access control lists until the instance is upgraded.

Through Adaptive's [Redis](https://adaptive.live/integrations/redis), [ElastiCache](https://adaptive.live/integrations/amazon-elasticache) and [Memorystore](https://adaptive.live/integrations/google-memorystore) integrations, clients reach Redis through the broker with their own identity rather than the shared instance password. The virtual patch is a preventive policy that denies the scripting commands (`EVAL`, `EVALSHA` and script loading) for every role except the one that owns the application's scripts, applied across every Redis endpoint from one place instead of instance by instance. Every attempt is logged against a named identity, which also tells you who still sends scripts and where the real patch has to land first.

The same pattern applies to any database where a documented exploit depends on a statement shape: a specific stored procedure, an extension function, a schema change or a bulk export. [Adaptive's database activity monitoring](https://adaptive.live/product/monitor) parses queries across PostgreSQL, MySQL, SQL Server, Oracle, MongoDB, Snowflake, Redshift and others, so the deny rule is written once, in terms of the statement, rather than once per client.

### Servers: take the vulnerable daemon off the network

[CVE-2024-6387](https://rockylinux.org/news/2024-07-01-openssh-sigalrm-regression), known as regreSSHion, is a signal handler race condition in OpenSSH 8.5p1 through 9.7p1 that allows unauthenticated remote code execution as root. The documented host-side mitigation, setting `LoginGraceTime` to zero, trades the race for a denial-of-service exposure. A year later, [CVE-2025-32433](https://censys.com/advisory/cve-2025-32433) in the Erlang/OTP SSH server allowed commands to run before login completed. It was added to CISA's Known Exploited Vulnerabilities catalog, and Censys counted hundreds of exposed servers.

No rule on session content helps with a bug that fires before authentication. The virtual patch is exposure removal: the host's SSH daemon accepts connections only from Adaptive's broker, and engineers reach it over [brokered SSH](https://adaptive.live/integrations/ssh) with SSO and MFA. The unauthenticated attack surface becomes one hardened path instead of every reachable port 22. For post-authentication bugs, [command restrictions on virtual machines](https://adaptive.live/product/authorization) deny the binary or argument the exploit needs, and [credential rotation](https://adaptive.live/product/credential-rotation) ensures the host password is not also sitting in a configuration file somewhere else, as the [FortiBleed 2.0 exposures](https://adaptive.live/blog/fortibleed-2-firewall-secrets-privileged-access) showed for network appliances.

### Kubernetes: shrink who can send the dangerous request

[CVE-2024-10220](https://access.redhat.com/security/cve/CVE-2024-10220) allowed arbitrary command execution through a crafted `gitRepo` volume in a pod specification on kubelet versions before the 1.28.12, 1.29.7, 1.30.3 and 1.31.0 fixes. The documented mitigation is a validating admission policy that rejects any pod carrying a `gitRepo` volume. That is the right tool for inspecting the request body.

The admission policy answers "what may be created." The broker answers "who may create it, from where, and for how long." Through Adaptive's [Kubernetes integration](https://adaptive.live/integrations/kubernetes), each identity receives a scoped role that limits which verbs and resources it can reach in the cluster, and privileged verbs such as pod creation in sensitive namespaces can require approval and expire. While the cluster waits for its upgrade window, the set of identities that could send a malicious manifest shrinks from every holder of a kubeconfig to the approved sessions of the moment, and each of those sessions is recorded.

### Web services and consoles: block the path

Grafana's [CVE-2021-43798](https://github.com/grafana/grafana/security/advisories/GHSA-8pjx-jj86-j47p) was a directory traversal under `/public/plugins/<plugin-id>/` that read arbitrary files from the server. The advisory's interim recommendation was a reverse proxy that normalizes the request path. Jenkins's [CVE-2024-23897](https://www.jenkins.io/security/advisory/2024-01-24/) let attackers with read permission read entire files, and unauthenticated attackers read the first lines of files, through a CLI argument-parser feature. The advisory's workaround was to disable CLI access entirely.

These are the classic WAF use cases, and the point is that internal consoles rarely sit behind a WAF. Adaptive brokers access to [Grafana](https://adaptive.live/integrations/grafana), [Jenkins](https://adaptive.live/integrations/jenkins), [Kibana](https://adaptive.live/integrations/kibana) and [GitLab](https://adaptive.live/integrations/gitlab), and [browser isolation](https://adaptive.live/product/browser-isolation) runs the console in a managed session rather than on the user's device. [Stratos](https://adaptive.live/product/stratos) adds URL filtering and action-level policies per user and agent. The virtual patch is a URL rule that blocks the CLI path or the traversal pattern for every brokered session, with the console itself reachable only through SSO, so unauthenticated path probes never arrive.

### MCP servers and agents: allowlist tools, not servers

AI agents introduced a class of software that is young, widely deployed and patched unevenly. The [Filesystem MCP server](https://cvefeed.io/vuln/detail/CVE-2025-53110) shipped with sandbox escapes through path traversal (CVE-2025-53109 and CVE-2025-53110). The [mcp-remote package](https://db.gcve.eu/cve/CVE-2025-6514) allowed operating-system command injection when a client connected to an untrusted server (CVE-2025-6514). Researchers chained flaws in the [Git MCP server](https://www.techradar.com/pro/security/anthropics-official-git-mcp-server-had-some-worrying-security-flaws-this-is-what-happened-next) with the filesystem server to reach code execution.

[Adaptive's MCP gateway](https://adaptive.live/product/mcp) exposes infrastructure to agents through brokered MCP servers, with OAuth sign-in as the user running the agent and every tool call logged. [Exo](https://adaptive.live/product/exo) scopes tool permissions per agent, enforces allowlists, and gates server access with approvals and time limits. The virtual patch is a change to the allowlist: when a tool is reported vulnerable, remove it from every agent's permitted set centrally until the server is updated. Because agents never hold downstream credentials, a compromised MCP server does not inherit the database password or the cloud key. The [LiteLLM incident](https://adaptive.live/blog/litellm-breach-agent-access-security) is a reminder of how quickly a flaw in agent tooling becomes an access problem.

## What does a virtual patching workflow look like on the proxy?

OWASP's cheat sheet describes virtual patching as a process with six phases. The table maps each phase to what a team does when the enforcement point is the access broker.

| OWASP phase | What it means on an access proxy |
| --- | --- |
| Preparation | Route the systems that matter through the broker before you need to, so a rule has somewhere to land. [Discovery](https://adaptive.live/product/discovery-and-classification) finds the endpoints you forgot. Keep policies as code through the CLI, REST API or Terraform provider. |
| Identification | Watch vendor advisories and CISA's KEV catalog. Match affected versions to brokered endpoints using the inventory the broker already keeps. |
| Analysis | Decide which protocol element the exploit needs: a command, a statement, a verb, a path, a tool, or a pre-authentication connection. That decides which of the four mechanisms applies. |
| Virtual patch creation | Prefer the positive model where you can: allow the statements the application is known to send and deny the rest. Fall back to a negative rule that denies the exploit trigger. |
| Implementation and testing | Deploy as a detective policy first and read the alerts. Promote to preventive once legitimate traffic is clean, and test in an approved environment. |
| Recovery and follow-up | Apply the vendor patch, confirm it, retire the rule, and keep the audit trail as evidence that the window was covered. |

OWASP's point that code-level fixes and virtual patching are not mutually exclusive applies here too. The rule on the proxy buys time. It does not replace the upgrade.

## What can a proxy not patch?

Honest scope matters more for a compensating control than for a fix. Four limits apply.

- **Client-side bugs.** PostgreSQL's [CVE-2025-1094](https://www.postgresql.org/support/security/CVE-2025-1094/) was a quoting flaw in the `psql` client's handling of invalid UTF-8, chained with a BeyondTrust vulnerability to reach code execution. A server-side proxy cannot fix a parser on the user's laptop. It can ensure that only brokered identities with scoped roles reach the database, and it can alert on the "invalid byte sequence" errors that exploitation attempts leave behind.
- **Traffic that bypasses the broker.** A direct connection with a shared password, or an application service account that talks straight to the database, is outside the rule. Route service traffic through [workload access](https://adaptive.live/product/workloads) and rotate the credentials that used to allow direct connections. Absence from the broker's records does not establish absence of access.
- **Exploits that look like legitimate work.** A logic flaw triggered by a normal-looking request is invisible to a deny rule. The positive model narrows the gap but cannot close it.
- **The broker itself.** Adaptive is software with its own update cadence. A virtual patching program includes patching the enforcement layer.

A virtual patch also carries an organizational risk: it works well enough that the real fix stops being urgent. Record each rule with the CVE it covers, an owner and a retirement condition, and review the open set in the same cadence as the vulnerability backlog.

## How can teams validate these controls?

Use an approved test environment and a representative engineering account:

1. Pick one recent advisory that affects a brokered system and identify the exploit trigger: the command, statement, path, verb or tool it needs.
2. Write the rule as a detective policy. Run the team's normal workload for a day and confirm the alert count is zero or explained.
3. Promote the rule to preventive. Send the trigger through the broker from a test account and confirm it is denied and logged against the identity.
4. Try the same trigger around the broker: a direct connection to the host, an old kubeconfig, a saved console cookie. Each success is a bypass to close with a network rule, a credential rotation or a workload identity.
5. Apply the vendor patch, confirm the trigger is harmless, retire the rule, and export the audit records that show the window was covered.

## Frequently asked questions

**Q: What is virtual patching?**

Virtual patching is a security policy enforced between an attacker and a vulnerable system that blocks attempts to exploit a known vulnerability without changing the vulnerable code. OWASP defines it as "a security policy enforcement layer which prevents and reports the exploitation attempt of a known vulnerability." It is a compensating control used until the vendor patch is applied.

**Q: Is virtual patching the same as a WAF?**

No. A web application firewall is one place a virtual patch can be enforced, and the most common one for public web applications. The same idea applies at a network IPS, a Kubernetes admission controller, a host's configuration, or an access proxy that parses database, SSH, Kubernetes, HTTP and MCP traffic to internal systems.

**Q: Can virtual patching replace patching?**

No. It reduces the risk of a known exploit path while the fix is tested and deployed. The vulnerability remains, exploit paths the rule does not cover still work, and OWASP notes that code fixes and virtual patches are not mutually exclusive. Track every virtual patch as residual risk with an owner and a retirement date.

**Q: How is virtual patching on an access proxy different from a WAF?**

A WAF inspects HTTP to applications. An access proxy such as Adaptive's sits inline for every protocol that engineers, services and agents use to reach infrastructure, and attributes each request to an authenticated identity. That allows rules on database statements, server commands, Kubernetes verbs, console paths and MCP tools, scoped per role, with approval and expiry attached.

**Q: Can Adaptive virtually patch any vulnerability?**

No. It can remove network exposure for systems behind the broker, deny a specific statement, command, path or tool, gate a risky feature behind approval, and detect and terminate misuse. It cannot fix client-side bugs, traffic that bypasses the broker, or exploits that are indistinguishable from legitimate requests. Verify which elements each integration parses in your deployment.

**Q: How long should a virtual patch stay in place?**

Until the vendor patch is applied and verified on every affected system. Retire the rule at that point and keep the audit records as evidence. A rule that outlives its CVE is a sign that the real remediation has stalled.

## Cover the patch window with Adaptive

Start with the next advisory that lands in your queue. Identify the exploit trigger, find the brokered systems it affects, and write the rule once on the proxy instead of once per host. [Request an Adaptive demo](https://adaptive.live/request-demo) to see how brokered access, preventive policies and tool-level allowlists can shield databases, servers, clusters, consoles and agents while the patch is on its way.

Download this article as [Markdown](https://adaptive.live/blog/virtual-patching-with-access-proxies/article.md) or [plain text for LLMs](https://adaptive.live/blog/virtual-patching-with-access-proxies/llms.txt). Both include publication metadata and source links.