Introduction

Browser-isolation platforms are increasingly deployed in enterprise environments to protect users from malicious websites, phishing payloads, and file-based threats.
Many modern solutions combine containerized remote browsers, gateway proxies, and multiple antivirus engines to ensure that potentially harmful files are blocked before reaching the endpoint.

During a recent authorized security assessment, I analyzed a browser-isolation product that used a multi-AV pipeline and container-based rendering to prevent the download of malicious files. Although the core concept was robust, a subtle logic flaw in the gateway layer allowed me to bypass these security controls entirely. This write-up walks through the root causes of the issue, why the architecture failed, and how a small oversight in path handling undermined the platform’s protection model.

How the Platform Was Supposed to Work

The solution used a standard browser-isolation workflow:

1. A new container is spawned for each browsing session.
2. The user never interacts with the real internet directly; instead, they see a VNC-like interface inside an iframe.
3. All downloads are passed through:

• URL filtering
• multi-engine antivirus scanning
• sandbox inspection

4. If a file is considered malicious, the download is blocked before it can reach the user.

At a high level, this is a secure and well-structured approach.

The Architectural Weak Spot: The Gateway Layer

Each browsing session generates an iframe URL similar to:

https://gateway/<container-id>/<session-id>/vnc.html?path=<container-id>/<session-id>/websockify&cursor=false&resize=remote&clipboard_up=true&clipboard_down=true&clipboard_seamless=true&toggle_control_panel=false

This link points to the remote browser interface running inside the container.

However, during the assessment, it became clear that the gateway was:

exposing internal directory structures

• accepting user-controlled path parameters
• failing to enforce any meaningful path normalization or sanitization

As a result, the gateway unintentionally behaved like a lightweight file server.

What Actually Happened Inside the Container

Although the product blocked malicious file downloads at the gateway’s inspection pipeline, the browser inside the isolated container did download the files before they were scanned.

Normally, this should not be a problem, those downloads should remain sealed inside the container’s filesystem.

However…

The gateway was exposing additional directories beyond the intended VNC interface, including:

• the browser’s default profile directory
• its internal cache
• and most importantly, its download folder

This made it possible to access files after the browser had downloaded them but before the security layers could enforce blocking.

How I Bypassed the Multi-AV Controls

By manipulating the iframe’s path parameter and browsing to adjacent directories within the returned container structure, I could:

• reach the browser’s download directory
• retrieve any file the remote browser had already stored
• access files the AV pipeline had intended to block
• fully bypass the product’s intended threat-prevention controls

This was not an antivirus evasion. It was a gateway-level path exposure vulnerability.

Even with strong isolation at the container level, the gateway’s mismanagement of paths inadvertently reopened access to files that were supposed to remain sealed inside the session.

Why This Happened

1. Direct Exposure of Internal Paths
The gateway directly exposed the container/session path (‘/<container-id>/<session-id>/’) as a browsable directory. By removing the VNC-specific query parameters, the underlying folder became accessible over HTTP.

2. Directory Listing Enabled
With directory indexing turned on, the gateway returned a full listing of files and subdirectories under the session path, including browser profile and download folders.

3. Missing Authorization on Static Routes
Access to these paths did not require any additional authorization beyond the initial session, effectively turning the gateway into a file server for everything inside the browser container.

Security Impact

This vulnerability fundamentally broke the product’s threat model:

• multi-engine AV scanning became irrelevant
• harmful files became accessible through the gateway
• isolation guarantees were weakened
• user-level containment leaked into the web layer

Most importantly, it demonstrated that even secure container isolation can be compromised if the routing/gateway layer is misconfigured.

Vendor Response!

After reporting the issue through the responsible disclosure process, the vendor stated that they were already aware of the vulnerability. No bounty was offered, and there was no formal acknowledgment or appreciation for the findings.
Interestingly, although they claimed the issue was known, the vulnerability was still present not only in the version I was testing but also in the latest release. I originally identified the flaw in two older builds, and further verification showed that the same weakness persisted unchanged in the most recent version as well.

This experience highlights the importance of having a structured vulnerability management process. When a security issue remains unpatched across multiple versions, even after being acknowledged, it signals gaps in prioritization and lifecycle management and underscores the value of transparent and accountable security practices

Conclusion

Browser isolation is a powerful defensive technology, but its effectiveness depends on correct implementation at every layer. In this case, the isolation kernel was functioning correctly, but the surrounding infrastructure introduced a flaw that allowed malicious files to bypass multi-AV scanning entirely.

This assessment reinforced an important lesson:
Container security must be reviewed holistically, from the runtime engine all the way up to the routing and gateway components. Even a single overlooked parameter can collapse an otherwise robust security design.