VNX-1067: Excessive Execution of Sequential Searches of Data Resource

Field	Value
Rule ID	VNX-1067
Severity	Low
SARIF level	note
Kind	sast
Languages	Java
CWE	CWE-1067
CAPEC	CAPEC-66
ATT&CK	T1190
CWSS vector	CWSS:1.0/TI:L/AP:RU/AL:S/IC:N/FC:LT/RP:RU/RL:S/AV:L/AS:N/IN:A/SC:A/BI:L/DI:H/EX:L/EC:N/P:L
Tags	sequential-search sql performance java cwe-1067
Source	internal/sast/rules/vnx-1067.rego

Overview

VNX-1067 maps to CWE-1067: Excessive Execution of Sequential Searches of Data Resource. Java: an SQL or JPQL search written so the database cannot use an index and must scan the table sequentially. Reported: a LIKE/ILIKE pattern with a leading wildcard in a query string (LIKE '%..., LIKE CONCAT('%', :p ...), ILIKE '%' || :p), a value bound to a query parameter that starts with a wildcard (ps.setString(1, "%" + q ...), query.setParameter("n", "%" + n), or a variable assigned "%" + ... up to 20 lines earlier and then bound), a function applied to a column in a comparison (WHERE LOWER(col) = ..., UPPER(col) LIKE ...), including in @Query annotations, Java text blocks and query strings split by concatenation; the JPA Criteria and Hibernate forms (cb.like(root.get("n"), "%" + q), cb.equal(cb.lower(root.get("n")), v), MatchMode.ANYWHERE/END); and Spring Data derived query methods in a Repository interface whose name compiles to the same thing (findByNameContaining, ...EndingWith, ...IgnoreCase). Not reported: trailing-wildcard (prefix) searches such as LIKE 'adm%', q + "%" or findByNameStartingWith, a function applied to the bound value rather than the column (col = LOWER(:v)), functions in a SELECT list, GROUP BY or ORDER BY, plain equality, % in format strings and log text, and comments. Whether the column is indexed, or the table small, is not known: review each finding against the schema (use a full-text or trigram index, a functional index, or a normalised column).

Why This Matters

This weakness class (Excessive Execution of Sequential Searches of Data Resource) creates a concrete exploit surface: the rule searches for the concrete source-level patterns most commonly associated with CWE-1067 and surfaces them for review. Each finding should be evaluated in context, the rule catches the pattern, not the context.

What Gets Flagged

// FLAGGED: leading wildcard, no index can serve it
String sql = "SELECT name FROM products WHERE name LIKE '%" + term + "%'";
ps.setString(1, "%" + q + "%");

// FLAGGED: function on the column defeats a plain index
@Query(value = "SELECT * FROM orders WHERE LOWER(customer_email) = LOWER(:email)", nativeQuery = true)

// FLAGGED: Criteria API and Spring Data derived queries
return cb.like(root.get("name"), "%" + q + "%");
List<Customer> findByLastNameContainingIgnoreCase(String fragment);

Not flagged: prefix searches (LIKE 'adm%', q + "%", findByLastNameStartingWith), WHERE u.email = LOWER(:email), GROUP BY DATE(created_at), plain equality, % in format strings or log text, and comments.

Remediation

1. Review each flagged line and determine whether the pattern represents a real instance of CWE-1067 or a false positive.
2. Replace the flagged construct with a documented safe alternative appropriate to your language and framework.
3. For confirmed false positives, add a # vulnetix-ignore: VNX-1067 comment on the line.
4. Ensure equivalent test coverage exists to prevent regression.

References

• CWE-1067: Excessive Execution of Sequential Searches of Data Resource
• OWASP Top 10

Suppressing this rule

Put a nosec comment on the line, or on line 1 to cover the whole file. Use the comment marker of the file’s language (#, //, -- or ;):

# nosec vnx-1067
// nosec vnx-1067

Or record an ignore rule: vulnetix ignore add --rule vnx-1067 --reason "...". See Suppressing findings.