Summary
A SQL injection flaw in the order_by parameter of the /customers/search endpoint in EasyAppointments allows attackers to inject arbitrary SQL into queries built by CodeIgniter's Query Builder.
When exposed to untrusted clients, this can enable time-based data extraction, schema enumeration, and, under some MySQL configurations, remote code execution via INTO OUTFILE to drop a PHP web shell.
A SQL injection flaw in the order_by parameter of the /customers/search endpoint in EasyAppointments allows attackers to inject arbitrary SQL into queries built by CodeIgniter's Query Builder.
When exposed to untrusted clients, this can enable time-based data extraction, schema enumeration, and, under some MySQL configurations, remote code execution via INTO OUTFILE to drop a PHP web shell.
Affected context
The vulnerability appears in EasyAppointments deployments that expose the /customers/search endpoint to users or integrated systems and rely on user-supplied order_by values to dynamically build SQL queries.
It is most relevant when:
- The application runs on MySQL or MariaDB with file write capabilities from SQL (e.g., permissive
secure_file_priv) - The database user has privileges to use
INTO OUTFILEor similar features - Input validation or parameterization is not enforced on the
order_byfield before passing it to the Query Builder
The vulnerability appears in EasyAppointments deployments that expose the /customers/search endpoint to users or integrated systems and rely on user-supplied order_by values to dynamically build SQL queries.
It is most relevant when:
- The application runs on MySQL or MariaDB with file write capabilities from SQL (e.g., permissive
secure_file_priv) - The database user has privileges to use
INTO OUTFILEor similar features - Input validation or parameterization is not enforced on the
order_byfield before passing it to the Query Builder
Exploit preconditions
- Attack surface: HTTP interface via the
/customers/searchendpoint. - Required access: Ability to send crafted requests with a controlled
order_byparameter (usually unauthenticated or low-privilege authenticated access). - Trigger point: Query construction inside the CodeIgniter Query Builder where
order_byis directly concatenated into SQL. - Why exploitation is possible: The
order_byparameter is treated as trusted SQL syntax instead of a constrained field list, allowing injection of arbitrary SQL fragments, including time-based conditions and file-writing primitives.
- Attack surface: HTTP interface via the
/customers/searchendpoint. - Required access: Ability to send crafted requests with a controlled
order_byparameter (usually unauthenticated or low-privilege authenticated access). - Trigger point: Query construction inside the CodeIgniter Query Builder where
order_byis directly concatenated into SQL. - Why exploitation is possible: The
order_byparameter is treated as trusted SQL syntax instead of a constrained field list, allowing injection of arbitrary SQL fragments, including time-based conditions and file-writing primitives.
Why this happens
This issue stems from a failure to treat user-controlled input as untrusted when constructing SQL queries.
The order_by parameter is passed directly into the CodeIgniter Query Builder's order_by method without whitelisting or parameterization, enabling attackers to escape the intended ordering clause and inject new SQL syntax.
Conceptually, this maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection), where application code assembles SQL strings using unsanitized user input instead of using strict column whitelists or prepared statements.
This issue stems from a failure to treat user-controlled input as untrusted when constructing SQL queries.
The order_by parameter is passed directly into the CodeIgniter Query Builder's order_by method without whitelisting or parameterization, enabling attackers to escape the intended ordering clause and inject new SQL syntax.
Conceptually, this maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection), where application code assembles SQL strings using unsanitized user input instead of using strict column whitelists or prepared statements.
Potential impact
- Attackers may extract or enumerate customer records and related application data.
- Attackers could perform time-based blind SQL injection to infer database contents without direct error messages.
- Attackers may discover database schema, tables, and columns for further exploitation.
- Under permissive MySQL configurations, attackers can write arbitrary PHP files (web shells) via
INTO OUTFILE, potentially achieving remote code execution on the application server. - Compromise of application integrity and confidentiality, including possible lateral movement from the database to the underlying host.
- Attackers may extract or enumerate customer records and related application data.
- Attackers could perform time-based blind SQL injection to infer database contents without direct error messages.
- Attackers may discover database schema, tables, and columns for further exploitation.
- Under permissive MySQL configurations, attackers can write arbitrary PHP files (web shells) via
INTO OUTFILE, potentially achieving remote code execution on the application server. - Compromise of application integrity and confidentiality, including possible lateral movement from the database to the underlying host.
General mitigation guidance
Effective mitigation focuses on eliminating the use of raw, user-controlled values in SQL construction and narrowing trust boundaries around query parameters.
Common defensive patterns include:
- Restricting
order_byto a predefined, server-side whitelist of sortable columns and directions, ignoring any unexpected values. - Using parameterized queries or ORM methods that separate SQL structure from data, even for ordering and filtering.
- Implementing centralized validation routines for query-related parameters (sorting, filtering, pagination) that enforce strict syntax and allowed values.
- Reducing database account privileges so that file-writing operations (e.g.,
INTO OUTFILE) and other dangerous commands are not available to application users. - Applying defense-in-depth controls, such as web application firewalls, to detect and block obvious SQL injection patterns while underlying code is being hardened.
Effective mitigation focuses on eliminating the use of raw, user-controlled values in SQL construction and narrowing trust boundaries around query parameters.
Common defensive patterns include:
- Restricting
order_byto a predefined, server-side whitelist of sortable columns and directions, ignoring any unexpected values. - Using parameterized queries or ORM methods that separate SQL structure from data, even for ordering and filtering.
- Implementing centralized validation routines for query-related parameters (sorting, filtering, pagination) that enforce strict syntax and allowed values.
- Reducing database account privileges so that file-writing operations (e.g.,
INTO OUTFILE) and other dangerous commands are not available to application users. - Applying defense-in-depth controls, such as web application firewalls, to detect and block obvious SQL injection patterns while underlying code is being hardened.
How teams detect issues like this
Organizations can look for this class of issue by combining automated analysis and targeted review of query-building logic.
Useful approaches include:
- Static analysis rules that flag dynamic SQL construction where input variables are incorporated into
ORDER BY,GROUP BY, or raw query fragments without whitelisting. - Code review checks focused on search and list endpoints, ensuring that sortable fields come from enumerated server-side lists instead of direct client parameters.
- Logging and monitoring of database activity for anomalous queries, such as repeated time-based functions, schema introspection (
information_schema), or use ofINTO OUTFILE. - Security review policies that require validation and normalization of request parameters used in query builders, enforced via coding standards and CI checks.
Organizations can look for this class of issue by combining automated analysis and targeted review of query-building logic.
Useful approaches include:
- Static analysis rules that flag dynamic SQL construction where input variables are incorporated into
ORDER BY,GROUP BY, or raw query fragments without whitelisting. - Code review checks focused on search and list endpoints, ensuring that sortable fields come from enumerated server-side lists instead of direct client parameters.
- Logging and monitoring of database activity for anomalous queries, such as repeated time-based functions, schema introspection (
information_schema), or use ofINTO OUTFILE. - Security review policies that require validation and normalization of request parameters used in query builders, enforced via coding standards and CI checks.
