CVE-2026-33502
Server-Side Request Forgery in WWBN AVideo Live Plugin
Publication date: 2026-03-23
Last updated on: 2026-03-24
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| wwbn | avideo | to 26.0 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-918 | The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': 'CVE-2026-33502 is a critical unauthenticated Server-Side Request Forgery (SSRF) vulnerability in the AVideo platform affecting versions up to 26.0, specifically in the plugin/Live/test.php endpoint.'}, {'type': 'paragraph', 'content': 'The vulnerability allows any remote attacker to make the AVideo server send HTTP requests to arbitrary URLs without authentication. The vulnerable endpoint accepts a \'statsURL\' parameter which is only superficially validated to start with "http". If this check passes, the server fetches the content from the specified URL.'}, {'type': 'paragraph', 'content': "Because there is no proper authentication, allowlist, or safe URL validation, attackers can use this to probe internal network services, localhost ports, and cloud metadata endpoints accessible from the server. The server's response or errors from these requests are reflected back to the attacker, revealing internal server details."}, {'type': 'paragraph', 'content': 'This vulnerability is classified as CWE-918: Server-Side Request Forgery (SSRF), where the server fetches URLs without sufficient validation, allowing attackers to manipulate the destination of requests.'}] [1]
How can this vulnerability impact me? :
This vulnerability can have severe impacts including unauthorized access to internal network services and sensitive resources that are normally inaccessible from outside the server.
- Attackers can probe localhost and internal network ports to discover open or closed services.
- They can access internal HTTP resources and cloud metadata endpoints, potentially exposing sensitive configuration or credentials.
- Sensitive internal network information can be gathered, increasing the risk of further attacks.
- The vulnerability requires no authentication and has low attack complexity, making exploitation easy.
Overall, the server and internal network reachable from it are at risk of information disclosure and potential further compromise.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by attempting to access the vulnerable endpoint `plugin/Live/test.php` with a crafted `statsURL` parameter to see if the server makes HTTP requests to arbitrary URLs without authentication.'}, {'type': 'paragraph', 'content': 'A simple detection method is to send HTTP requests to the endpoint with `statsURL` pointing to internal or localhost services and observe if the server responds with connection details or errors indicating it tried to fetch those URLs.'}, {'type': 'paragraph', 'content': 'Example commands to test the vulnerability include using curl to probe internal services:'}, {'type': 'list_item', 'content': 'curl -v "http://[AVideo-server]/plugin/Live/test.php?statsURL=http://127.0.0.1:80/"'}, {'type': 'list_item', 'content': 'curl -v "http://[AVideo-server]/plugin/Live/test.php?statsURL=http://169.254.169.254/latest/meta-data/"'}, {'type': 'paragraph', 'content': 'If the server returns connection refused errors or upstream connection details, it indicates the vulnerability is present.'}] [1]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include:
- Remove the `plugin/Live/test.php` file entirely from production deployments if it is not needed.
- If the endpoint must remain accessible, restrict access by requiring admin authentication before allowing any requests.
- Implement strict validation to only allow requests to explicitly configured, trusted URLs and block requests to localhost, private IP ranges (RFC1918), link-local addresses, and cloud metadata IP ranges.
- Stop reflecting fetched response bodies and raw upstream errors back to clients to avoid information leakage.
- Remove or secure the wget fallback code by escaping shell arguments properly using `escapeshellarg()` to prevent command injection.
- Restrict access to `test.php` via web server configuration (e.g., Apache or Nginx deny rules) and block outbound connections to private IP ranges at the firewall or egress level.