vulnerability-lookup: Specific login names lead to ambigious URLs

Disclosure Status

approved

April 02, 2026

April 09, 2026

Description

Finding

(note: likely to have extremely limited impact, creating report just in case, see below)

For GET requests vulnerability-lookup displays a public user profile under /user/$login . Additionally certain fixed /user/$path subpages are used with GET requests for various purposes. During Signup only some $path values are prohibited, others are not. In case of such collisions Flask will select the more specific route (/user/$path). An attempt to open a users profile may thus lead to unintended visits to other pages (including some functional ones).

Reproducibility

Relevant $path values: toggle_2fa, account_recovery, submit, bundles, sightings, organizations, vulnerability_disclosures.

Note: My understanding of Flask/Werkzeug is that the more specific page (so /user/$path) would be chosen over the less specific (/user/$login) - I wasn't able to test this here as I neither wanted to risk your prod instance nor have one of my own. It's also one of the reasons I am raising this here instead of as a Github Issue (feel free to transform it or let met know I should create one instead).

To test: Create a new account with the login matching any of the above values. Then attempt to visits its profile.

Also: Feel free to delete https://vulnerability.circl.lu/user/generate_apikey as you see fit - account I created for a quick test which should have 0 impact given /user/generate_apikey is undefined for GET.

Impact

Hypothetical as GET on neither of the relevant $path values performs an action (without further interaction) & there is no POST on /user/$login.

Patches

Workarounds

References

Details

GCVE-1-2026-0013

circl:vulnerability-lookup