CVE-2026-29187: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-29187 is an Authenticated Blind Boolean-Based SQL Injection vulnerability in OpenEMR's Patient Search functionality (/interface/new/new_search_popup.php). It affects all OpenEMR versions prior to 8.0.0.3 and was disclosed on March 25, 2026, with a patch released the same day. The vulnerability carries a CVSS v3.1 base score of 8.8 (High) per Feedly threat intelligence data, or 8.1 (High) per the official GitHub Security Advisory (GitHub Advisory, Feedly).

The root cause (CWE-89) lies in how new_search_popup.php processes HTTP GET/POST parameters prefixed with mf_ (e.g., mf_fname, mf_lname): the code strips the prefix and concatenates the remainder directly into SQL $relevance and $where clauses as column identifiers without validating them against a known-good allowlist (GitHub Advisory). The existing sanitization function add_escape_custom() (wrapping mysqli_real_escape_string) is designed for data values and escapes quotes, but does not escape backtick characters, allowing an attacker to break out of the SQL identifier context and inject arbitrary SQL logic (GitHub Advisory). The fix, applied in commit c61887a, validates the extracted field name against actual patient_data table columns using escape_sql_column_name() and wraps identifiers in backticks (GitHub Commit). A public PoC with concrete curl commands targeting this endpoint is available on GitHub (PoC Repository).

Any authenticated OpenEMR user with access to the Patient Search page can exploit this vulnerability to read, modify, or delete arbitrary data in the underlying database, including sensitive patient health information, medical records, usernames, and password hashes (GitHub Advisory). The blind boolean-based nature of the injection allows systematic extraction of all database contents through true/false queries, posing a severe confidentiality and integrity risk to protected health information (PHI) regulated under HIPAA and similar frameworks (Feedly). Availability impact is rated High in some scoring assessments, reflecting the potential for data destruction or denial of service via malicious SQL commands.

Multiple high-confidence proof-of-concept exploits are publicly available, including a GitHub repository with concrete curl commands and HTTP request sequences demonstrating boolean-based extraction against a live OpenEMR instance (PoC Repository). The official security advisory also contains step-by-step PoC instructions with specific payload formats (GitHub Advisory). The vulnerability requires only low-privilege authenticated access (no admin rights), has low attack complexity, and requires no user interaction, making it straightforward to weaponize. The EPSS score is approximately 0.024% (0.000240), and as of the time of reporting there is no confirmed evidence of in-the-wild exploitation or CISA KEV catalog listing (Feedly). No specific threat actor attribution has been reported.

1. Authenticate to OpenEMR: Obtain valid credentials for any low-privilege user account on the target OpenEMR instance (version ≤ 8.0.0.2).
2. Capture session cookie: Log in via a browser or curl and capture the OpenEMR session cookie from the response headers.
3. Identify the vulnerable endpoint: Navigate to or directly target /interface/new/new_search_popup.php, which handles Patient Search requests.
4. Craft a malicious HTTP parameter key: Instead of injecting into a parameter value, inject SQL into the parameter key using the mf_ prefix. For example, construct a GET request with a parameter key like mf_fname followed by SQL logic embedded in the key name (e.g., mf_\=test` and mf_(SELECT(username)FROM(users_secure))=ad_in%`).
5. Send the boolean-true payload: Issue a request such as curl -k -b "OpenEMR=<session>" 'https://<target>/interface/new/new_search_popup.php?mf_<true_condition>=test' and observe the response (e.g., patient results returned = TRUE condition).
6. Send the boolean-false payload: Modify the injected key to produce a false condition and observe the differing response (e.g., no results = FALSE condition).
7. Automate data extraction: Loop through characters of target data (e.g., database name, usernames, password hashes) by iterating boolean conditions, using tools like sqlmap with custom tamper scripts or a custom script, to reconstruct full values one character at a time (GitHub Advisory, PoC Repository).

• Network: Unusual HTTP GET/POST requests to /interface/new/new_search_popup.php containing parameter keys with mf_ prefix followed by SQL syntax (backticks, SQL keywords like SELECT, FROM, WHERE, AND, OR); repeated requests to the same endpoint with slightly varying parameter key names (indicative of boolean-based enumeration).
• Logs: Web server access logs showing high-frequency requests to new_search_popup.php from a single authenticated session; parameter keys in query strings containing SQL fragments (e.g., mf_%60, mf_SELECT, encoded SQL characters); database error logs showing SQL syntax errors related to column name resolution.
• Database: Unexpected or anomalous query patterns in MySQL/MariaDB general query logs involving the patient_data table with unusual column references; queries originating from the OpenEMR application user that enumerate database schema (e.g., information_schema queries).
• Application: OpenEMR application logs showing repeated Patient Search requests with non-standard parameter keys; authentication events for low-privilege accounts followed immediately by high-volume search activity (GitHub Advisory, PoC Repository).

The primary remediation is to upgrade OpenEMR to version 8.0.0.3 or later, which contains the patch addressing this vulnerability (GitHub Release, GitHub Commit). For systems that cannot be patched immediately, restrict network access to the Patient Search endpoint (/interface/new/new_search_popup.php) via firewall rules or web application firewall (WAF) rules blocking requests with SQL syntax in parameter keys, and limit user access to only essential personnel (Feedly). Additionally, enable and monitor database query logs for anomalous SQL activity targeting the patient_data table, and audit access to sensitive patient records.

The vulnerability was reported by researcher fayassgit and acknowledged by the OpenEMR maintainers, who published the advisory and patch on the same day (March 25, 2026) (GitHub Advisory). The disclosure was noted by security aggregators including The Hacker Wire, INCIBE-CERT, and ENISA's EUVD, reflecting standard community awareness for a high-severity healthcare application vulnerability (Feedly). Given OpenEMR's widespread use in healthcare settings and the sensitivity of PHI, the vulnerability attracted attention from the security community, with a PoC repository published shortly after disclosure.