CVE-2020-36897 is a critical (CVSS 9.8) unauthenticated file upload in QiHang Media Web Digital Signage 3.0.9. The QH.aspx file accepts uploads through the remotePath and fileToUpload parameters, so malicious ASPX scripts can be written and run. No fixed version is confirmed.
What's affected
QiHang Media Web Digital Signage version 3.0.9, per the record and VulnCheck. The vendor listed in the product data is Howfor.
The record says QH.aspx supports file uploads using the remotePath and fileToUpload parameters, and that attackers can use them to write and execute arbitrary system commands on the server.
I could not confirm a fixed version from the sources available. Contact the vendor, and treat the product as unpatched. A related flaw in the same file, CVE-2020-36898, allows file deletion.
How to check if you're exposed
Find the product version in the signage administration interface. 3.0.9 is in scope.
Look for the vulnerable page on the web server:
find /path/to/webroot -iname "QH.aspx"
On Windows servers, search the site folder in the same way. Check the web root and upload folders for ASPX files that you did not deploy, and check IIS logs for requests to QH.aspx from addresses you do not recognise.
Finally, check whether the signage server is reachable from the internet and, if it is, whether it needs to be.
What to do now
- Find all QiHang signage servers and their versions.
- Contact the vendor for a fixed release.
- Block access to QH.aspx at the web server or a reverse proxy until a fix is in place.
- Search for unexpected ASPX files, and rebuild the server from clean media if you find any.
- Run the web application with the lowest privileges possible and disable script execution in upload folders.
Why it matters
The weakness is CWE-434 (Unrestricted Upload of File with Dangerous Type). The page writes whatever file it receives to a path the caller chooses. When that path is inside the web root and the file is an ASPX script, the web server will run it on the next request.
The two parameters named in the record show why this is so direct: one chooses where to write, the other supplies what to write. Without authentication and without a file type check, the endpoint is an open door.
The record does not mark this CVE as CISA KEV and makes no claim of exploitation in the wild, though public exploit material is referenced.
Quick check
Is there a patch for QiHang Media Web Digital Signage?
I could not confirm one. Version 3.0.9 is named in the record. Ask the vendor.
Is there a related flaw?
Yes. CVE-2020-36898 covers unauthenticated file deletion in the same QH.aspx endpoint.
Sources
Last reviewed: 19 October 2026.
