CVE-2026-32888
SQL Injection in Open Source POS Items Search Allows Data Manipulation
Publication date: 2026-03-20
Last updated on: 2026-04-08
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| opensourcepos | open_source_point_of_sale | to 3.4.2 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-89 | The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-32888 is a high-severity SQL Injection vulnerability in the Items search functionality of the open-source PHP application Open Source Point of Sale (opensourcepos). It occurs when the custom attribute search feature (search_custom filter) is enabled. User input from the search GET parameter is directly inserted into a SQL HAVING clause without proper parameterization or sanitization.
This flaw allows an authenticated attacker with basic item search permissions to execute arbitrary SQL queries on the database. The vulnerability arises from unsafe string interpolation in the code, which fails to neutralize special SQL elements.
How can this vulnerability impact me? :
This vulnerability can have severe impacts on confidentiality, integrity, and availability of the affected system.
- Confidentiality: Attackers can read the entire database, extracting sensitive data such as user credentials, personally identifiable information (PII), and financial data.
- Integrity: Attackers may modify data by executing INSERT or UPDATE subqueries.
- Availability: Attackers can cause denial of service (DoS) by running heavy SQL queries like SLEEP() or BENCHMARK().
- Escalation: Extracted admin password hashes can be cracked offline, potentially leading to full application takeover.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by attempting to exploit the SQL Injection in the Items search functionality when the custom attribute search feature is enabled. An example of a crafted GET request that triggers an error-based SQL injection is:'}, {'type': 'paragraph', 'content': "GET /items/search?search=' AND EXTRACTVALUE(1,CONCAT(0x7e,(SELECT CONCAT(username,':',password) FROM ospos_employees LIMIT 1),0x7e)) AND '1'='1&filters[]=search_custom"}, {'type': 'paragraph', 'content': 'If the server responds with a DatabaseException containing admin username and hashed password, it confirms the presence of the vulnerability.'}, {'type': 'paragraph', 'content': 'To detect this on your system, you can use tools like curl or wget to send the above GET request to the vulnerable endpoint and observe the response for SQL error messages or leaked data.'}, {'type': 'list_item', 'content': 'curl -i "http://yourserver/items/search?search=\' AND EXTRACTVALUE(1,CONCAT(0x7e,(SELECT CONCAT(username,\':\',password) FROM ospos_employees LIMIT 1),0x7e)) AND \'1\'=\'1&filters[]=search_custom"'}, {'type': 'list_item', 'content': 'Observe the HTTP response for database error messages or leaked credential data.'}] [1]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include:
- Disable the custom attribute search feature (search_custom filter) to prevent exploitation of the vulnerable code path.
- Restrict access to the Items search functionality to trusted users only, minimizing the risk of exploitation by authenticated attackers.
- Apply input sanitization by filtering the search parameter using FILTER_SANITIZE_FULL_SPECIAL_CHARS as a defense-in-depth measure.
- Monitor and audit logs for suspicious search queries that may indicate attempted exploitation.
Note that at the time of the advisory, no patch was available. When a patch is released, upgrade to a fixed version that uses parameterized queries instead of string interpolation in the HAVING clause.