CVE-2026-26005: Oxygenz Clipbucket SSRF Vulnerability

CVE-2026-26005 Overview

CVE-2026-26005 is a Server-Side Request Forgery (SSRF) vulnerability in ClipBucket v5, an open source video sharing platform. The flaw exists in the Remote Play feature, which allows users to create video entries referencing external URLs instead of uploading files. An attacker can supply an internal network host as the video URL, causing the server to issue GET requests to internal infrastructure. The vulnerability affects ClipBucket v5 versions prior to 5.5.3 - #45 and is tracked as [CWE-918]. Even non-privileged users with standard accounts can trigger the SSRF, enabling internal network reconnaissance from an untrusted boundary.

Critical Impact

Authenticated low-privilege users can coerce the ClipBucket server into issuing arbitrary GET requests to internal hosts, enabling internal network scanning and exposure of services not reachable from the public internet.

Affected Products

• ClipBucket v5 versions prior to 5.5.3 - #45
• Oxygenz ClipBucket open source video sharing platform
• Deployments exposing the Remote Play video entry feature to authenticated users

Discovery Timeline

• 2026-02-12 - CVE-2026-26005 published to NVD
• 2026-02-18 - Last updated in NVD database

Technical Details for CVE-2026-26005

Vulnerability Analysis

The Remote Play feature in ClipBucket v5 accepts a user-supplied URL that points to an external video resource. The application fetches this URL server-side without validating that the destination resolves to a public, non-internal host. By substituting an internal IP address or hostname for the expected external video URL, an attacker forces the ClipBucket backend to issue HTTP GET requests against internal infrastructure.

The attack requires only a standard authenticated session. No administrative privilege, file upload capability, or special role is required to register a remote video entry. This widens the attacker pool to any user able to register or obtain a standard account on the affected instance.

Resulting responses and timing differences allow the attacker to enumerate live hosts, open ports, and reachable internal services. Cloud-hosted ClipBucket instances are particularly exposed because SSRF can be directed at cloud metadata endpoints and internal orchestration services.

Root Cause

The root cause is missing validation of the user-supplied video URL before the server initiates an outbound HTTP request. The Remote Play handler does not enforce an allowlist of external hosts, does not reject private and link-local address ranges, and does not resolve and re-check the destination after DNS resolution. This pattern maps directly to [CWE-918] Server-Side Request Forgery.

Attack Vector

The attack vector is network-based and requires low privileges. An authenticated user submits a new Remote Play video entry whose URL field points at an internal target such as http://127.0.0.1:8080/, http://169.254.169.254/latest/meta-data/, or http://10.0.0.5:6379/. The ClipBucket server resolves the host and issues a GET request from its own network position. The attacker observes response status codes, content length differences, and response timing to map the internal network. Refer to the GitHub Security Advisory GHSA-69xj-2pq3-5r4v for the upstream technical description.

Detection Methods for CVE-2026-26005

Indicators of Compromise

• Outbound HTTP requests from the ClipBucket server process to RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback (127.0.0.0/8), or link-local (169.254.0.0/16) destinations.
• Repeated Remote Play video entries created by a single user account where the source URL targets non-public hosts or unusual ports.
• Web server access logs showing bursts of POST requests to the Remote Play submission endpoint followed by internal connection attempts.

Detection Strategies

• Inspect application logs for video entries whose external URL field contains private IP literals, localhost, or cloud metadata addresses such as 169.254.169.254.
• Correlate authenticated user sessions with egress traffic originating from the ClipBucket host to identify anomalous server-initiated connections.
• Deploy egress filtering telemetry to flag outbound traffic from the web application tier toward internal management interfaces or database ports.

Monitoring Recommendations

• Forward web application logs and host-level network telemetry to a centralized analytics pipeline for cross-source correlation of SSRF behavior.
• Alert on any Remote Play submission whose URL resolves to a non-routable or internal address after DNS lookup.
• Baseline normal outbound destinations from the ClipBucket server and alert on deviations such as new internal subnet contact or metadata endpoint access.

How to Mitigate CVE-2026-26005

Immediate Actions Required

• Upgrade ClipBucket v5 to version 5.5.3 - #45 or later, which contains the official fix in commit a9e0f2322fb37501dfd4f44079fc7826a132503a.
• Audit existing Remote Play video entries for URLs pointing at internal addresses and remove any suspicious records.
• Review account creation logs for recently registered users that submitted Remote Play entries shortly after signup.

Patch Information

The maintainers addressed the vulnerability in the MacWarrior/clipbucket-v5 repository. Apply the upstream fix referenced in the GitHub Commit Update. Administrators running custom forks must port the validation logic that rejects internal address ranges before the server issues the outbound request.

Workarounds

• Restrict outbound network access from the ClipBucket server using host-based firewall rules that deny connections to RFC1918, loopback, and link-local ranges except where explicitly required.
• Place the ClipBucket application behind an egress proxy that enforces an allowlist of permitted external video hosts.
• Disable or gate the Remote Play feature to trusted administrative accounts until the patched release can be deployed.

# Example iptables egress restriction for the ClipBucket application user
iptables -A OUTPUT -m owner --uid-owner www-data -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 169.254.0.0/16 -j REJECT