Simple POS System EUVD-2026-31663

The /user/search.php endpoint must be network-accessible to the attacker - if the POS system is deployed on an internal-only network without internet exposure, remote exploitation is blocked at the network level. The CVSS vector (PR:N/UI:N) confirms no authentication and no user interaction are required, meaning exploitation is possible against a default installation with no special configuration needed. The limiting factors are: (1) the application must be running and the /user/search.php file must exist and be reachable; (2) the underlying database user must have sufficient privileges to return or modify data - if the DB account is restricted to SELECT only, write-impact is reduced; (3) internet-facing deployment is uncommon for POS systems, which materially limits the attacker pool to those with internal network access or who discover rare internet-exposed instances.

The CVSS 4.0 score of 5.5 (Medium) with vector AV:N/AC:L/AT:N/PR:N/UI:N reflects a remotely exploitable, low-complexity, unauthenticated attack with partial confidentiality, integrity, and availability impact on the vulnerable component and no scope change to secondary systems (SC:N/SI:N/SA:N). The E:P modifier confirms a public proof-of-concept exists. Despite these favorable attacker conditions, the EPSS score of 0.03% at the 9th percentile is notably low, suggesting this vulnerability is not currently being mass-exploited in the wild - likely because SourceCodester applications are small-scale deployments with limited internet exposure. The SSVC assessment corroborates concern: exploitation status is 'poc', automatable is 'yes' (meaning scripted mass scanning is feasible), but technical impact is rated only 'partial'. The absence of a CISA KEV listing is consistent with the low EPSS. Real-world risk is moderate for any organization running this application with the /user/search.php endpoint internet-accessible, but low for most environments given the niche nature of this software.

An unauthenticated remote attacker sends a crafted HTTP GET or POST request to /user/search.php with a SQL payload injected into the Name parameter (e.g., Name=' OR 1=1--), causing the application's backend query to return unintended records or execute attacker-controlled SQL statements. A publicly available proof-of-concept on GitHub (https://gist.github.com/c4ttr4ck/24c157c90227c3f5cd5e5d871449fed8) demonstrates the technique, enabling even low-skill attackers to enumerate the database schema and extract sensitive records such as user credentials, inventory data, or transaction history.