CVE-2026-77929: Authenticated File Upload Leads to Remote Code Execution in ClipBucket v5

Overview

A high-severity file upload vulnerability has been disclosed in ClipBucket v5, the open-source PHP video/photo sharing platform maintained by MacWarrior and Oxygenz. Tracked as CVE-2026-77929, the flaw sits in the FileUpload::manageFile() function in fileupload.class.php: after the application validates an uploaded file's content type using image "magic bytes," it fails to correspondingly update the file's stored extension. An attacker who crafts a file with valid image magic bytes but a .php extension can pass the content check while keeping their attacker-chosen extension on disk — and if that file lands somewhere PHP-FPM will execute it, the result is remote code execution.

The vulnerability was reserved on 2026-08-21 and published on 2026-09-18, assigned by VulnCheck. It carries a CVSS v3.1 base score of 8.8 (High) and a CVSS v4.0 score of 8.7. Exploitation requires an authenticated account on the target ClipBucket instance — it is not exploitable pre-auth — and the project shipped a fix in release 5.5.3-#182.

It was disclosed alongside two related, lower-severity blind SQL injection issues in ClipBucket v5 (CVE-2026-77927 and CVE-2026-77928, both involving a clean_requests() sanitization bypass in ClipBucket.class.php), though those are separate bugs from the file upload issue covered here. This is also a distinct issue from the earlier CVE-2025-55912, an unauthenticated arbitrary file upload via photo_uploader.php in ClipBucket ≤ 5.5.0 — that flaw required no login at all; CVE-2026-77929 does.

Technical Details

How It Works

ClipBucket's photo upload endpoint validates uploaded files by inspecting their content — checking for valid image "magic bytes" (the signature bytes at the start of a file, such as the \xFF\xD8\xFF header for JPEG or \x89PNG for PNG) rather than trusting the client-supplied MIME type or extension outright. That content-based check is sound in principle: it's meant to stop an attacker from simply renaming a PHP script to shell.jpg and uploading it.

The bug is in what happens after that check passes. FileUpload::manageFile() determines the file's on-disk extension, but the pre-fix code never re-derived or normalized that extension from the validated content type — it left the attacker-supplied extension in place. That makes it possible to construct a single file that satisfies the magic-byte check (so it's accepted as a legitimate image) while retaining a .php extension supplied by the attacker in the original filename or upload metadata. Once that file is written to a web-accessible upload directory, requesting it directly causes PHP-FPM to execute it as a script rather than serve it as an image — full remote code execution in the context of the web server/application.

The official fix (shipped in 5.5.3-#182, credited to researcher @QwesiRED) addresses this on two levels. In fileupload.class.php, the extension is now explicitly re-derived from the validated MIME type rather than carried over from attacker input. As defense in depth, the release also adds .htaccess rules (Apache) and an nginx location block that explicitly deny PHP execution inside the /files/ upload directory — so even a file that somehow retains an executable extension can no longer be run as a script by the web server.

Because the attack requires an authenticated session, this is not a walk-up-and-exploit bug for anonymous internet traffic. But ClipBucket instances that allow open self-registration, or that have a broad base of lower-trust registered users (a common setup for a video/photo sharing platform), effectively expose this to any user who can create an account — which for a public-facing instance can be a low bar.

Impact Assessment

A successful exploit gives an authenticated attacker arbitrary code execution on the server hosting ClipBucket, which is a full compromise of the application's trust boundary — not merely a data-exposure or privilege-escalation bug. From there, an attacker who already only needed a low-privilege account can typically:

• Execute arbitrary server-side code, including reading the application's database credentials and configuration files, pivoting to the underlying host, or planting persistent web shells.
• Access or modify the ClipBucket database (user accounts, private messages, uploaded media, session data) via the compromised application process.
• Use the compromised server as a foothold for further internal network reconnaissance or lateral movement, depending on hosting environment.

The CVSS 8.8 score reflects network-reachable, low-complexity, no-user-interaction-required exploitation with high impact across confidentiality, integrity, and availability — tempered only by the requirement for a low-privilege authenticated account (PR:L), which is why this lands at High rather than Critical. As of publication, CVE-2026-77929 is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, and CosmicBytez Labs has found no confirmed evidence of active in-the-wild exploitation. Some vulnerability trackers reference associated technical write-ups, but we have not independently verified or reproduced any working exploit — treat "no confirmed exploitation yet" as a snapshot in time, not a guarantee, for a bug this straightforward to weaponize.

Affected Versions

ClipBucket v5 is developed in the open on GitHub (MacWarrior/clipbucket-v5); instances that track releases directly or use the platform's built-in git-based self-update from the Admin Area Dashboard can update in place. This is unrelated to the legacy, long-archived ClipBucket 2.x/4.x codebase, which reached end of life with its December 2022 archival.

Mitigation

• Upgrade to ClipBucket v5 5.5.3-#182 or later immediately. This is the authoritative fix — it corrects the extension-handling logic in fileupload.class.php and is the only change that closes the root cause.
• Apply the web-server hardening independently if you cannot upgrade right away. Explicitly deny PHP execution inside your upload directory (/files/ by default) via an Apache .htaccess rule or an nginx location block that serves those paths as static assets only. This blocks the RCE step even if a malicious file is written to disk, though it is a compensating control, not a substitute for the patch.
• Audit existing uploads in your ClipBucket instance's files/ (or equivalent upload) directory for any files with executable extensions (.php, .phtml, .php5, etc.) that don't belong there, and remove/quarantine anything suspicious.
• Review account creation and access controls. Because exploitation only requires a low-privileged authenticated account, tighten or monitor open self-registration if your instance is internet-facing, and review recent account activity for signs of abuse.
• Check web server and application logs for POST requests to the photo/file upload endpoint carrying unexpected extensions or unusual content-type/magic-byte mismatches, and for any subsequent direct requests to uploaded files that returned executed output rather than static content.
• Keep ClipBucket's git-based self-update mechanism current going forward, and track the project's GitHub releases/changelog for future security-relevant revisions — this codebase has had more than one upload-path security fix across recent versions.

Sources

• NVD — CVE-2026-77929
• Strix.ai CVE Database — CVE-2026-77929
• OffSeq Threat Radar — CVE-2026-77929
• GitHub — MacWarrior/clipbucket-v5