Food Waste Management System EUVD-2026-92252

The attacker must be able to reach the delivery/deliverymyord.php page of a deployed Food Waste Management System instance and supply attacker-controlled values for the delivery_person_id or order_id request parameters, which flow unsanitized into a SQL query (CWE-89). Per the CVSS vector (PR:N/UI:N), no authentication, credentials, or victim interaction are required, and it affects the default rolling-release code with no special configuration. The only real limiting factors are network reachability of the specific self-hosted instance and the measured low impact (VC:L/VI:L/VA:L), indicating partial rather than full database compromise in VulDB's assessment.

Signals are consistent but point to a modest real-world priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a remotely reachable, low-complexity, unauthenticated flaw with no user interaction, but the impact metrics are uniformly low (VC:L/VI:L/VA:L) and there is no scope change, yielding a medium base score of 6.9. Exploit maturity is E:P (proof-of-concept), and publicly available exploit code exists (referenced GitHub issue #13), which raises practical accessibility. However, there is NO CISA KEV listing and NO EPSS score provided in the input, so there is no evidence of active or widespread exploitation - PoC availability must not be conflated with exploitation in the wild. From an SSVC lens: exploitation = PoC, the flaw is likely automatable (classic parameter-based SQLi reachable without auth), and technical impact is partial. The dominant risk-reducing factor is prevalence: this is an individual GitHub hobby/student project with negligible production deployment, so despite the easy-to-trigger unauthenticated SQLi, the real-world attack surface is very small. Net: a genuinely low-friction bug but low aggregate risk for most organizations because almost no one runs this software.

A remote, unauthenticated attacker sends a crafted request to delivery/deliverymyord.php with a malicious value in the delivery_person_id or order_id parameter, injecting SQL into the backend query. Because the application reaches the vulnerable query without authentication or user interaction, the attacker can read or tamper with order/delivery records in the database. A public proof-of-concept is already disclosed in the project's GitHub issue tracker (issue #13).