Tourism-Management-System CVE-2026-90520

Exploitation requires possession of a valid low-privilege account on a deployed instance of Tourism-Management-System (CVSS PR:L confirms authentication is still required; this is an authorization bypass, not an authentication bypass). The flaw is present on 12 specific security(@RequestParam String username) endpoints across ChatmessageController, DiscussjiudianxinxiController, DiscusslvyougonglveController, DiscusslvyouxianluController, DiscussmeishicantingController, DiscussremenjingdianController, ForumController, FriendController, FriendlinkController, NewsController, NewstypeController, and StoreupController. No special network position, elevated OS privilege, non-default configuration, or user interaction is required. Exploitation is limited to instances running commits up to 84d8ec384f; instances updated to include commit d984d172 are not affected.

The CVSS 4.0 score of 5.3 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P) accurately reflects a moderate-severity authorization bypass with limited practical impact: network-accessible, no special attack conditions, but requiring low-privilege authentication (PR:L), and capped at low C/I/A impacts. No KEV listing exists and EPSS data was not provided, but given the product's obscure footprint as a hobby-grade GitHub project, mass exploitation is implausible - even a mid-sized municipal IT team in boleslawiec would be very unlikely to run this specific system in production. The publicly available proof of concept (GitHub issue #12) does lower the exploitation bar for anyone who happens to be running an instance. The input tag of 'Authentication Bypass' is inconsistent with the actual CWE-285 (Improper Authorization) and the CVSS PR:L metric, both of which confirm that basic authentication is still required - this is a role/permission bypass, not a full authentication circumvention. The finding is real but of limited real-world consequence.

A low-privileged authenticated user of a deployed Tourism-Management-System instance sends a crafted HTTP GET request such as GET /news/security?username=admin directly to one of the 12 affected controller endpoints. Because @IgnoreAuth causes the AuthorizationInterceptor to skip all role checks, the endpoint responds successfully, returning security credential data for the targeted username regardless of the caller's permissions. A public proof-of-concept demonstrating this flow is available via GitHub issue #12.