# github.com/gorilla/websocket@v1.5.3 security report (Go)

- Verdict: **Needs review** (risk level: medium)
- Scanned: 2026-10-05T19:08:58.000Z
- Files reviewed: 23
- Findings: 1 high, 7 medium, 7 low severity findings
- Report: https://security.togoder.click/go/github.com/gorilla/websocket
- Source: Togoder Security (https://security.togoder.click), AI source-code review

## Summary

Togoder Security scanned the Go package github.com/gorilla/websocket@v1.5.3 on Oct 5, 2026. An AI review of 23 source files produced 1 high, 7 medium, 7 low severity findings. The overall verdict is medium: the findings flag risky but common patterns (dynamic code, unsafe defaults, broad file or network access) rather than confirmed malware.

## Findings

### [high] Unrestricted file execution / process spawning

Finding ID: `NPS-A82E0D4A452D`

File: `examples/command/main.go:115`

The program takes command-line arguments and uses os.StartProcess to execute an arbitrary binary specified by the user. It also pipes stdin/stdout to a WebSocket connection, effectively providing a remote shell. If deployed publicly without authentication, this allows remote command execution.

### [medium] Permissive WebSocket origin check

Finding ID: `NPS-DC8DEE8742BB`

File: `examples/autobahn/server.go:22`

The WebSocket upgrader is configured with CheckOrigin returning true, which disables the same-origin policy for WebSocket connections. This could allow cross-site WebSocket hijacking if the server were exposed beyond its intended test environment.

### [medium] Unbounded memory allocation

Finding ID: `NPS-237C7BC05D7D`

File: `examples/autobahn/server.go:92`

echoReadAll uses conn.ReadMessage which reads the entire message into memory without a size limit, allowing a remote client to cause memory exhaustion via a large WebSocket message.

### [medium] Command executed inherits environment and file descriptors

Finding ID: `NPS-E4FF1C5BBD22`

File: `examples/command/main.go:115`

The child process (cmdPath) is started with the parent's environment and inherits file descriptors for stdin, stdout, and stderr, which could leak sensitive environment variables if the command outputs them or if a client interacts with it.

### [medium] No authentication on WebSocket endpoint

Finding ID: `NPS-21691FC42CD4`

File: `examples/command/main.go:130`

The WebSocket handler /ws does not implement any authentication or authorization. Any client that can reach the server can connect and execute the specified command, which by default may be a shell.

### [medium] WebSocket origin check disabled

Finding ID: `NPS-F30E44F4611B`

File: `examples/echo/server.go:20`

The websocket.Upgrader is initialized with default options, which means CheckOrigin is nil. When CheckOrigin is nil, the Upgrader uses a default that allows all origins. This disables same-origin policy protections for WebSocket connections, potentially enabling Cross-Site WebSocket Hijacking (CSWSH). This is a known security weakness in the Gorilla WebSocket example.

### [medium] Missing origin check in WebSocket upgrader

Finding ID: `NPS-E6C3B65D19E6`

File: `examples/filewatch/main.go:38`

The websocket.Upgrader is used with its zero-value configuration, meaning CheckOrigin is nil and defaults to allowing all origins. This enables Cross-Site WebSocket Hijacking (CSWSH): a malicious website can open a WebSocket to this server and read the contents of the file being served, since the server does not validate the Origin header of the incoming handshake request.

### [medium] File content exposure via WebSocket / home endpoint

Finding ID: `NPS-BE68FAEECA9B`

File: `examples/filewatch/main.go:148`

The application reads an arbitrary file path supplied on the command line and streams its contents to any connecting client over WebSocket (and also renders it in the home page HTML). There is no authentication or access control, so anyone able to reach the service can obtain the file contents. This is a data exposure issue if the operator points it at a sensitive file.

### [low] Potential denial of service via compression

Finding ID: `NPS-2D83F9B1DA4F`

File: `examples/autobahn/server.go:20`

EnableCompression is true, which can enable compression-based DoS (e.g., zip-bomb style payloads) and increased CPU/memory usage when combined with unbounded message reads.

### [low] Default binding to localhost

Finding ID: `NPS-A45E0DD6868E`

File: `examples/command/main.go:25`

The default address is 127.0.0.1:8080, which limits exposure, but the address is configurable via a flag. If changed to 0.0.0.0, the service becomes remotely accessible.

### [low] Reflected input in WebSocket URL template

Finding ID: `NPS-9A070D676721`

File: `examples/echo/server.go:40`

The home handler constructs a WebSocket URL by concatenating 'ws://' with r.Host and passing it to html/template. While html/template escapes for HTML context, the URL is placed inside a JavaScript string literal in the template. An attacker-controlled Host header could inject content into the JavaScript context. Although html/template's contextual escaping generally mitigates XSS here, relying on Host header for URL construction is risky.

### [low] Parsing untrusted numeric input without bounds

Finding ID: `NPS-BA0A890146D1`

File: `examples/filewatch/main.go:118`

strconv.ParseInt on the lastMod query parameter uses bitSize 64 but the value is derived from an unauthenticated request. While ParseInt will fail on overflow, large values are accepted and used to set file modification comparison; this only affects whether file contents are returned, not a direct exploit.

### [low] Unescaped host value in JavaScript WebSocket URL

Finding ID: `NPS-91E46CD2CE11`

File: `examples/filewatch/main.go:183`

In homeHTML the WebSocket URL is constructed as ws://{{.Host}}/ws using the raw request Host header inside a JavaScript string literal within html/template. While html/template contextually escapes HTML, injecting a crafted Host header containing quotes or newlines could allow JavaScript injection in the rendered client page (JS context escaping may not fully neutralize all Host-header injection vectors).

### [low] Network requests

Finding ID: `NPS-3AB436537CCE`

File: `x_net_proxy.go:200`

The code implements SOCKS5 and direct dialers for proxy support; network operations are expected and not suspicious in this context.

### [low] Environment variable access

Finding ID: `NPS-942ACBB42BC4`

File: `x_net_proxy.go:280`

The code reads proxy configuration from environment variables (ALL_PROXY, all_proxy, NO_PROXY, no_proxy) to configure network dialers, which is standard behavior for proxy support and not credential harvesting.

## Files reviewed

- `examples/autobahn/server.go` (medium): This is a Go WebSocket echo test server (Gorilla WebSocket) with no malicious behavior, but it has weak origin checking and unbounded message read patterns that would be unsafe in production.
- `examples/command/main.go` (medium): The example code implements a WebSocket-to-process bridge that can execute arbitrary commands without authentication, posing a high risk of remote code execution if deployed beyond localhost.
- `examples/echo/server.go` (medium): This is the standard Gorilla WebSocket echo example with a disabled origin check (default upgrader), presenting a moderate CSWSH risk but no malicious patterns.
- `examples/filewatch/main.go` (medium): This is the well-known Gorilla WebSocket file-watch example; it contains no malicious code (no exfiltration, no credential harvesting, no shell execution), but it has security weaknesses including a default-permissive WebSocket origin policy and unauthenticated exposure of an operator-specified file's contents.
- `client.go` (safe): No malicious patterns detected; the code is a standard WebSocket client implementation from the Gorilla WebSocket library with expected networking and TLS handling.
- `compression.go` (safe): No malicious patterns detected
- `conn.go` (safe): This is the standard Gorilla WebSocket connection implementation with no malicious patterns, network exfiltration, credential harvesting, or obfuscated code detected.
- `doc.go` (safe): Cleared by Jev triage; no further analysis needed
- `examples/chat/client.go` (safe): No malicious patterns detected; this is the standard Gorilla WebSocket chat client example code.
- `examples/chat/hub.go` (safe): No malicious patterns detected
- `examples/chat/main.go` (safe): No malicious patterns detected
- `examples/echo/client.go` (safe): No malicious patterns detected; this is a standard Gorilla WebSocket example client with no data exfiltration, credential harvesting, or other security concerns.
- `join.go` (safe): No malicious patterns detected
- `json.go` (safe): No malicious patterns detected
- `mask.go` (safe): No malicious patterns detected
- `mask_safe.go` (safe): Cleared by Jev triage; no further analysis needed
- `prepared.go` (safe): No malicious patterns detected; this is the standard Gorilla WebSocket PreparedMessage implementation for efficient message caching.
- `proxy.go` (safe): No malicious patterns detected in the provided Go source file.
- `server.go` (safe): No malicious patterns detected; the code is the well-known Gorilla WebSocket upgrader with standard origin and handshake validation.
- `tls_handshake.go` (safe): No malicious patterns detected
- `tls_handshake_116.go` (safe): No malicious patterns detected
- `util.go` (safe): Cleared by Jev triage; no further analysis needed
- `x_net_proxy.go` (safe): The bundled proxy library implements standard proxy dialing (direct, PerHost, SOCKS5) and reads proxy-related environment variables; no malicious patterns such as exfiltration, backdoors, or obfuscation were found.

AI analysis is guidance, not a guarantee. Methodology: https://security.togoder.click/methodology