/

CVE-2026-100365

Severity:

HIGH RISK

(8.8)

SQL Injection (CWE-89) in SuiteCRM AOR Report Generation

CVE-2026-100365

Undergoing Analysis

Vulnerability type

Category:

SQL Injection

CWE:

CWE-89, CWE-943

Impact:

Sensitive data exposure and database resource exhaustion

Severity:

HIGH RISK

(8.8)

CVSS version:

3.1

Catch this CVE while code is being written

Detect vulnerable code directly in pull requests, so CVEs are fixed before merge.

Summary

SuiteCRM's AOR report generation can place an attacker-controlled stored field label into a database ORDER BY clause without an allowlist. An authenticated user with AOR Reports access may exploit this to extract database contents or keep database connections busy with expensive expressions.

SuiteCRM's AOR report generation can place an attacker-controlled stored field label into a database ORDER BY clause without an allowlist. An authenticated user with AOR Reports access may exploit this to extract database contents or keep database connections busy with expensive expressions.

Affected context

The issue occurs in SuiteCRM's AOR report-generation flow, where field labels from stored report data are used to construct an ORDER BY clause. Deployments may be at risk when this value can be influenced by an attacker and is not restricted to approved fields before query construction. The affected flow involves AOR_Reports and aor_fields.

The issue occurs in SuiteCRM's AOR report-generation flow, where field labels from stored report data are used to construct an ORDER BY clause. Deployments may be at risk when this value can be influenced by an attacker and is not restricted to approved fields before query construction. The affected flow involves AOR_Reports and aor_fields.

Exploit preconditions

  • Attack surface: AOR report generation and its database query construction
  • Required access: An authenticated account with AOR Reports access
  • Trigger point: Generating a report that uses a stored field label in an ORDER BY clause
  • Why exploitation is possible: The field label is incorporated into a security-sensitive query without an allowlist, allowing crafted query logic to affect database behavior
  • Attack surface: AOR report generation and its database query construction
  • Required access: An authenticated account with AOR Reports access
  • Trigger point: Generating a report that uses a stored field label in an ORDER BY clause
  • Why exploitation is possible: The field label is incorporated into a security-sensitive query without an allowlist, allowing crafted query logic to affect database behavior

Why this happens

The report-generation flow concatenates an attacker-controlled stored field label into an ORDER BY clause rather than selecting from a trusted set of fields. This insecure query construction can allow input to alter the intended SQL statement, mapping to CWE-89: Improper Neutralization of Special Elements used in an SQL Command. It also relates to CWE-943, which covers improper neutralization in data query logic.

The report-generation flow concatenates an attacker-controlled stored field label into an ORDER BY clause rather than selecting from a trusted set of fields. This insecure query construction can allow input to alter the intended SQL statement, mapping to CWE-89: Improper Neutralization of Special Elements used in an SQL Command. It also relates to CWE-943, which covers improper neutralization in data query logic.

Potential impact

  • Sensitive information, including password hashes, could be extracted through time-based database queries.
  • Data from arbitrary database tables may be exposed.
  • Expensive query expressions may hold database connections and reduce service availability.
  • CRM data confidentiality and database performance may be affected.
  • Sensitive information, including password hashes, could be extracted through time-based database queries.
  • Data from arbitrary database tables may be exposed.
  • Expensive query expressions may hold database connections and reduce service availability.
  • CRM data confidentiality and database performance may be affected.

General mitigation guidance

Defensive patterns focus on ensuring that query structure is controlled by the application rather than user-influenced values.

  • Build ORDER BY clauses only from server-side allowlists of valid fields and directions.
  • Use parameterized queries for values, while recognizing that identifiers and sort expressions generally require explicit allowlisting.
  • Treat stored labels and other persisted input as untrusted when they are later used in queries.
  • Apply least-privilege database permissions and resource limits to reduce the consequences of unsafe query behavior.
  • Validate report definitions against a strict schema before using them to construct queries.

Defensive patterns focus on ensuring that query structure is controlled by the application rather than user-influenced values.

  • Build ORDER BY clauses only from server-side allowlists of valid fields and directions.
  • Use parameterized queries for values, while recognizing that identifiers and sort expressions generally require explicit allowlisting.
  • Treat stored labels and other persisted input as untrusted when they are later used in queries.
  • Apply least-privilege database permissions and resource limits to reduce the consequences of unsafe query behavior.
  • Validate report definitions against a strict schema before using them to construct queries.

How teams detect issues like this

  • Use static analysis to identify string concatenation or interpolation of untrusted data into SQL query structure, especially ORDER BY clauses.
  • Review report-generation code for field names or labels sourced from stored records and confirm they are mapped to approved identifiers.
  • Enforce code-review and CI policies that require allowlists for dynamic SQL identifiers.
  • Monitor database activity for unusual time-based queries, expensive expressions, or prolonged connection usage associated with report generation.
  • Automated security review tools may help flag dynamic query construction for manual assessment.
  • Use static analysis to identify string concatenation or interpolation of untrusted data into SQL query structure, especially ORDER BY clauses.
  • Review report-generation code for field names or labels sourced from stored records and confirm they are mapped to approved identifiers.
  • Enforce code-review and CI policies that require allowlists for dynamic SQL identifiers.
  • Monitor database activity for unusual time-based queries, expensive expressions, or prolonged connection usage associated with report generation.
  • Automated security review tools may help flag dynamic query construction for manual assessment.

Sources

SourceLink
github.comgithub.com/SuiteCRM/SuiteCRM-Core/commit/a11f50180d939f639cc468b5d536e8ad714dfb68
github.comgithub.com/SuiteCRM/SuiteCRM-Core/releases/tag/v8.10.2
github.comgithub.com/SuiteCRM/SuiteCRM/commit/d6bca97a0159ec019a969b86eca32affab3beb7c
github.comgithub.com/SuiteCRM/SuiteCRM/releases/tag/v7.15.2
github.comgithub.com/SuiteCRM/SuiteCRM/security/advisories/GHSA-6c7r-7g6m-29f9

Frequently asked

questions

It can be triggered through the application's report-generation flow, but the described exploitation requires an authenticated user with AOR Reports access.

An account with AOR Reports access is required, along with a way to influence the stored field label used by the query.

Map requested sort fields to a server-side allowlist of approved database identifiers rather than concatenating stored labels into SQL.

Treat stored data as untrusted at query-construction boundaries, review dynamic SQL paths, and enforce automated checks for unallowlisted identifiers.

It can be triggered through the application's report-generation flow, but the described exploitation requires an authenticated user with AOR Reports access.

An account with AOR Reports access is required, along with a way to influence the stored field label used by the query.

Map requested sort fields to a server-side allowlist of approved database identifiers rather than concatenating stored labels into SQL.

Treat stored data as untrusted at query-construction boundaries, review dynamic SQL paths, and enforce automated checks for unallowlisted identifiers.

Find out what's already
exploitable in your codebase.