How I Uncovered Critical Vulnerabilities in an EDU Certificate Site

The assessment began after the EDU certificate platform was patched; the author aimed to locate overlooked edge assets. Using a Hunter query (web.title="xxxx大学" && icp.number!="xxxxxxx"), an IP site without ICP registration was identified.

Downloading a leaked .map file exposed the frontend source, which revealed both a file‑download and a file‑upload API. The download API required a base64‑encoded file path; after encoding the target path, the author successfully retrieved files such as /etc/passwd and discovered user directories like datahome and elasticsearch.

The upload API ( upload1) accepted a standard file parameter without validating content or type. The response returned a base64‑encoded storage path (e.g.,

/datahome/attachment/2025-02-19/8f9689132e174fa5/test11111.jsp

), but direct access returned 404, and further fuzzing did not reveal the actual storage location.

Inspecting /root/.bash_history yielded shell command history, from which administrator credentials were extracted. Using these credentials, the author logged into the backend, confirmed site registration details, and clarified asset ownership.

Further testing showed the upload endpoint lacked path‑traversal filtering. By controlling the filename, the attacker could place files in the default upload directory ( /datahome/attachment/) and, with knowledge of the web service absolute path ( /datahome/tomcat8_case/webapps/case) obtained from history, could achieve arbitrary file upload and execution. A simple JSP that computes 1+1 was uploaded to verify successful execution.

These steps collectively demonstrated multiple high‑severity vulnerabilities, including unauthorized file access, arbitrary file upload, path traversal, and credential leakage.