CVE-2026-41060
SSRF Bypass in WWBN AVideo via Hostname-Port Mismatch
Publication date: 2026-04-21
Last updated on: 2026-04-24
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| wwbn | avideo | to 29.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
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in WWBN AVideo allows an attacker to bypass SSRF protections and exfiltrate data by accessing arbitrary ports on the server and saving response bodies to web-accessible paths.
This could lead to unauthorized access to sensitive information stored or processed by the platform, potentially resulting in data breaches.
Such data breaches may violate compliance requirements under regulations like GDPR and HIPAA, which mandate protection of personal and sensitive data.
Can you explain this vulnerability to me?
This vulnerability exists in WWBN AVideo versions 29.0 and below, specifically in the isSSRFSafeURL() function within objects/functions.php. The function attempts to prevent Server-Side Request Forgery (SSRF) attacks by checking if a URL's hostname matches the site's root URL. However, it only compares the hostname and ignores the port number.
Because of this, an attacker can craft URLs using the site's public hostname but specify arbitrary, non-standard ports. This bypasses the SSRF protections, allowing the attacker to make requests to any port on the AVideo server.
The response from these requests is saved to a web-accessible path, which means the attacker can fully exfiltrate data from these internal services or ports.
This issue was fixed in a commit identified as a0156a6398362086390d949190f9d52a823000ba.
How can this vulnerability impact me? :
This vulnerability can allow an attacker with at least limited privileges (PR:L) to bypass SSRF protections and access arbitrary ports on the AVideo server.
Because the attacker can retrieve responses from these internal ports and the data is saved to a web-accessible location, they can exfiltrate sensitive information from the server.
The impact is rated with a high confidentiality impact (C:H), meaning sensitive data could be exposed, but there is no impact on integrity or availability.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, you should update WWBN AVideo to a version that includes the fix for this issue. The vulnerability is fixed in the commit a0156a6398362086390d949190f9d52a823000ba, so applying this patch or upgrading to a version above 29.0 will resolve the problem.
Additionally, review and restrict access to the affected functions and monitor for any unusual requests targeting non-standard ports on your AVideo server.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
To detect exploitation attempts of CVE-2026-41060 on your system, monitor for requests to the AVideo server that use the site's public hostname combined with non-standard ports. Since the vulnerability involves the isSSRFSafeURL() function allowing SSRF bypass when the hostname matches but the port differs, look for unusual internal port access patterns originating from authenticated users.
Specifically, you can check web server logs or application logs for requests to the downloadURL parameter in objects/aVideoEncoder.json.php that include URLs with the public hostname but non-standard ports.
Suggested commands to help detect such activity include:
- Using grep to find suspicious URLs in web server logs (e.g., Apache or Nginx logs):
- grep -i 'downloadURL=.*your-public-hostname:' /var/log/apache2/access.log
- grep -i 'downloadURL=.*your-public-hostname:' /var/log/nginx/access.log
- Using application logs to identify requests to objects/aVideoEncoder.json.php with suspicious ports:
- grep 'objects/aVideoEncoder.json.php' /path/to/avideo/logs/* | grep 'your-public-hostname:'
Additionally, monitoring for files created in the web-accessible directory videos/cache/tmpFile/ with names derived from URLs containing non-standard ports may indicate exploitation attempts, as the vulnerability saves response bodies there.