## Summary

The fix for [CVE-2026-27732](https://github.com/WWBN/AVideo/security/advisories/GHSA-h39h-7cvg-q7j6) is incomplete.

`objects/aVideoEncoder.json.php` still allows attacker-controlled `downloadURL` values with common media or archive extensions such as `.mp4`, `.mp3`, `.zip`, `.jpg`, `.png`, `.gif`, and `.webm` to bypass SSRF validation. The server then fetches the response and stores it as media content.

This allows an authenticated uploader to turn the upload-by-URL flow into a reliable SSRF response-exfiltration primitive.

## Details

`objects/aVideoEncoder.json.php` accepts attacker-controlled `downloadURL` and passes it to `downloadVideoFromDownloadURL()`.

Inside that function:

1. the URL extension is extracted from the attacker-controlled path
2. the extension is checked against an allowlist of normal encoder formats
3. `isSSRFSafeURL()` is skipped for common media and archive extensions
4. the URL is fetched via `url_get_contents()`
5. the fetched body is written into video storage and exposed through normal media metadata

The current code still contains:

- an extension-based bypass for SSRF validation
- no mandatory initial-destination SSRF enforcement inside `url_get_contents()` itself

This means internal URLs such as:

`http://127.0.0.1:9998/probe.mp4`

remain reachable from the application host.

This issue is best described as an incomplete fix / patch bypass of `CVE-2026-27732`, not a separate unrelated SSRF class.

## Proof of concept

1. Log in as a low-privilege uploader.
2. Start an HTTP service reachable only from inside the application environment, for example:

```text
http://127.0.0.1:9998/probe.mp4
```

3. Confirm that the service is not reachable externally.
4. Send:

```text
POST /objects/aVideoEncoder.json.php
downloadURL=http://127.0.0.1:9998/probe.mp4
format=mp4
```

5. If needed, replay once against the returned `videos_id` with `first_request=1` so the fetched bytes land in the normal media path.
6. Query:

```text
GET /objects/videos.json.php?showAll=1
```

7. Recover `videosURL.mp4.url`.
8. Download that media URL and observe that the body matches the internal-only response byte-for-byte.

## Impact

An authenticated uploader can make the AVideo server fetch loopback or internal HTTP resources and persist the response as media content by supplying a `downloadURL` ending in an allowlisted extension such as `.mp4`, `.jpg`, `.gif`, or `.zip`. Because SSRF validation is skipped for those extensions, the fetched body is stored and later retrievable through the generated `/videos/...` media URL. Successful exploitation allows internal response exfiltration from private APIs, admin endpoints, or other internal services reachable from the application host.


## Recommended fix

- Apply `isSSRFSafeURL()` to all `downloadURL` inputs regardless of extension
- Remove extension-based exceptions from SSRF enforcement
- Move initial-destination SSRF validation into `url_get_contents()` so call sites cannot skip it
- Avoid storing arbitrary fetched content directly as publicly retrievable media
- Consider restricting upload-by-URL to an explicit allowlist of trusted fetch origins

CWE-918 Server-Side Request Forgery (SSRF)