Webreaper Damselfly EUVD-2026-103048

No special conditions - remote unauthenticated exploitation against default configurations of Webreaper Damselfly up to and including 4.5.3, because the controller authorization attributes are commented out in shipped code, leaving every /api/* route (including user creation and password reset) open. The only limiting factor is network reachability of the Damselfly web server; as a self-hosted application it is frequently deployed on internal/LAN networks, which reduces internet-wide exposure but offers no protection to any attacker with access to that network segment.

All available technical signals align on high severity: the CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a network-reachable, low-complexity, unauthenticated flaw with high confidentiality, integrity and availability impact to the vulnerable system (VC:H/VI:H/VA:H), scoring 9.3. CWE-306 (Missing Authentication for Critical Function) is consistent with the description's root cause - controller authorization attributes are commented out, exposing all /api/* routes. Exploitability is trivial and well-documented: a public hackmd write-up and the VulnCheck advisory detail the exact PUT /api/users (create admin) and POST /api/users (reset any password) requests, so publicly available exploit information exists, though this is NOT the same as confirmed active exploitation. No EPSS score was provided in the input and the CVE is not listed in CISA KEV, so there is no evidence of in-the-wild exploitation at this time; the realistic exposure is tempered by the fact that Damselfly is a niche self-hosted photo-management application typically deployed on home/LAN networks rather than internet-facing enterprise infrastructure. Net: technically a genuine critical-severity flaw (easy, unauthenticated, full compromise), but real-world mass-exploitation risk is constrained by the product's small, often non-internet-exposed footprint rather than by any difficulty of exploitation.

An attacker who can reach the Damselfly web server over the network sends an unauthenticated PUT /api/users request assigning the Admin role to create an administrator account, then logs in with full control; alternatively a POST /api/users resets an existing user's password for takeover. Because authorization attributes are commented out, no credentials or user interaction are required, and a public write-up documents the exact requests.