The vulnerability stems from serving untrusted content (artifacts/Javadocs) without proper security headers. The commit diffs show both locations were patched by adding 'Content-Security-Policy: sandbox' headers. The first function (resultAttachment) handles general artifact content delivery, while the second (handleRawJavadocResource) deals with Javadoc resources. Both failed to enforce origin isolation pre-patch, enabling XSS via injected scripts. The high confidence comes from direct correlation between the vulnerability description, remediation steps, and the patched functions in the provided commit data.
It's important to note that the attacker does not need to lure a victim user to use a malicious artifact, but just open a link in the browser. This link can be silently loaded among the other HTML content, making this attack unnoticeable.
Even if the Reposilite instance is located in an isolated environment, such as behind a VPN or in the local network, this attack is still possible as it can be performed from the admin browser.
When serving artifact's content via HTTPS, it's important to understand that this content might be potentially untrusted HTML code, so the javascript execution should be restricted. Consider the following options to remediate this vulnerability:
Additionally, we strongly recommend reconsidering how the website authentication works for Reposilite. Storing user's passwords in plaintext in the browser's local storage is not an ideal option. The more robust and secure option would be to issue a one time session ID or a token to the browser after checking the login/password on the server. These session IDs or tokens should have limited validity time, so their compromise would be trickier to exploit.
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| com.reposilite:reposilite-backend | maven | >= 3.3.0, < 3.5.12 | 3.5.12 |