This CVE chains three distinct failures: an unauthenticated endpoint exposing user IDs, a JWT secret present in the distributed example configuration, and an authenticated endpoint that returns data for any user rather than validating ownership. The compound nature is what makes this severe—each layer is individually defensible, yet all three collapsed together.
The critical detail is that the secret appears in .env.example. This means exploitation doesn't require source code access, a config leak, or sophisticated reconnaissance—it requires reading the deployment documentation and following the instructions. The vendor effectively shipped a system with a pre-configured credential that works out of the box. The attack path isn't 'find the secret in source code,' it's 'deploy as documented.'
For defenders: treat any instance deployed from the example config as compromised—the secret is known, so account takeover via token forgery is trivial. Generate a replacement secret with at least 256 bits of entropy (openssl rand -hex 32 or equivalent) and rotate immediately. Audit the /api/v1/scans endpoint for evidence of mass enumeration, as it served as a user ID amplifier that turned token forgery into bulk account takeover. Implement network-level restrictions on unauthenticated endpoints until the vendor patch addresses the authorization flaw.
The broader pattern worth recognizing: self-hosted API products that ship example configs with working secrets create a deployment model where 'read the documentation' becomes the attack surface. The path of least resistance—copy-paste from the example— IS the vulnerable path. Secure operation required friction (generate a secret, understand JWT configuration); insecure operation required nothing. This is a design failure, not merely a coding error.