The EPSS score for CVE-2026-76799 is 0.00396 — remarkably low for a vulnerability that explicitly states a public exploit exists. Don't let that number lull you into dismissing this one. The gap between exploit availability and active exploitation tells you something important about the affected population, and it changes how you should respond.
This CVE affects code-projects 1.0, a starter kit distributed through code repositories. The backup handler at /loginsystem/database/login_registration_system.sql can apparently be tricked into reading files beyond its intended scope — potentially a path traversal, though the advisory language is deliberately vague on the mechanism. What matters is this: if the handler accepts user-controlled input to locate and serve files, you have a read-what-you-can-reach primitive. That's not just one exposed database backup; it's a potential /etc/passwd, environment variables, or application secrets leak, depending on what the web server process can reach.
The low EPSS is likely accurate for the population the model actually measures — production servers being actively scanned. But starter kits like this exhibit a bimodal distribution: they cluster in development environments, proof-of-concept deployments on cheap VPS instances, and small business sites built once and never patched. These systems either aren't internet-routable or aren't being hit by the scanner feeds that EPSG ingests. The model isn't wrong — it's measuring a different population than the one at risk.
Your prioritisation should depend on answering one question: is this a path traversal in the handler's parsing logic, or simply an information disclosure from an exposed SQL file? If it's the former, treat this as a file-read primitive with severity beyond what the 5.3 CVSS suggests. If it's the latter, the fix is moving the backup outside the web root — but verify the vendor documentation actually prescribes a secure location, because many starter kits ship with no guidance at all.
Given the public exploit but low EPSS, assume weaponisation is straightforward but the target population is fragmented and largely unmonitored. That means you're not racing against automated exploitation at scale — you're racing against the likelihood that some of these instances will be discovered and hit individually. Prioritise locating any code-projects 1.0 deployments in your environment, verify the backup handler's actual behaviour if you have source access, and treat this as higher-risk than the EPSS alone would suggest.