Unauthenticated Uploads Allowed via /uploadimage Endpoint

📌 Summary

Currently, our CodiMD deployment allows unauthenticated users to upload images via the /uploadimage endpoint. It effectively enables unrestricted and anonymous use of our server as file hosting service, exposing it to being overloaded.

While Single Sign-On (SSO) based on OIDC is correctly integrated into the application and functions as expected for accessing and managing notes, the /uploadimage route remains publicly accessible to any external user who has knowledge of the endpoint.

🔍 Evidence

A simple curl request (no authentication) results in a successful upload:

curl -iF image=@test.jpg https://codimd.web.cern.ch/uploadimage

Response:

HTTP/1.1 200 OK 
... 
{"link":"https://codimd.web.cern.ch/uploads/upload_xxx.jpeg"}

This demonstrates that:

• No session or authentication is required
• Uploaded images are stored and accessible immediately
• The route bypasses any SSO enforcement

✅ Scope of Fix

We are addressing only the upload vulnerability at this time. Specifically:

• The /uploadimage endpoint must be protected so that only authenticated users (via SSO) can upload files.

This will likely be implemented by routing requests to /uploadimage through a dedicated CERN SSO proxy, which will enforce authentication before forwarding the request to the application.

We are not addressing:

• The issue of access control for the /uploads directory, which remains accessible if someone has a direct link to a file.

⚠️ Additional Context on Image Access

Although the /uploads directory is also publicly accessible if a user has the direct URL to an uploaded file, the CodiMD team has addressed this to some extent by making the filenames non-guessable — they are generated using a random hash. This helps reduce the likelihood of unauthorized discovery of uploaded images, but it does not prevent access if a URL is leaked or shared. Check the related security advisory on the CodiMD official repo.

Unlike the upload issue, this cannot be solved simply by placing a generic SSO proxy in front of the /uploads path. That’s because we still want unauthenticated users to be able to view images embedded in public notes. Using a blanket SSO gate would break this functionality. A proper solution would require integrating image access control with note visibility, which is a more complex change inside the application.