SONARJAVA-6443 Narrow S5852 to exponential backtracking and create S8786

[pierre-loup-tristant-sonarsource]

Summary

• Narrows S5852 (vulnerability) to exponential backtracking only
• Creates S8786 (code-smell) for remaining super-linear cases (polynomial, quadratic)
• Extracts shared AbstractRedosCheck base class
• Updates ruling IT expected results

[hashicorp-vault-sonar-prod]

SONARJAVA-6443

[sonarqubecloud]

Agentic Analysis: Early Results

Agentic Analysis and Context Augmentation are available on your project. Here are some issues that could have been prevented. Follow the links to learn how to put them into action.

2 issue(s) found across 2 file(s):

Rule	File	Line	Message
java:S110	java-checks/src/main/java/org/sonar/java/checks/regex/AbstractRedosCheck.java	51	This class has 6 parents which is greater than 5 authorized.
java:S110	java-checks/src/main/java/org/sonar/java/checks/regex/SuperLinearRegexCheck.java	23	This class has 7 parents which is greater than 5 authorized.

_{Analyzed by SonarQube Agentic Analysis in 7.2 s}

[nils-werner-sonarsource]

One minor style nit on the new file.

[nils-werner-sonarsource]

One minor style nit on the new file.

[nils-werner-sonarsource]

I left a nitpick comments. Feel free to ignore.

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
1 Fixed issue
3 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
99.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[gitar-bot]

Code Review ✅ Approved 2 resolved / 2 findings

Splits regex backtracking rule S5852 into a vulnerability-focused rule and a new super-linear code smell S8786. The downgrade of exponential backreference cases and the fix for S8786's broken markup recommendations are successfully addressed.

✅ 2 resolved

✅ Security: Exponential backref regexes downgraded from S5852 to S8786 on Java 9+

📄 java-checks/src/main/java/org/sonar/java/checks/regex/RedosCheck.java:29-35 📄 java-checks/src/main/java/org/sonar/java/checks/regex/SuperLinearRegexCheck.java:28-38 📄 java-checks-test-sources/default/src/main/java/checks/regex/RedosCheckSample.java 📄 java-checks-test-sources/default/src/main/java/checks/regex/RedosCheckJava8.java
The original RedosCheck.message() classified QUADRATIC_WHEN_OPTIMIZED and LINEAR_WHEN_OPTIMIZED as exponential (the security-relevant case) whenever optimized was false, where optimized = isJava9OrHigher() && !regexContainsBackReference. A capturing-group backreference disables the Java 9 loop optimization, so e.g. (.*,)*\1 and (?:.*,)*(X)\1 were exponential ReDoS even on Java 9+ and were reported by S5852 with the "exponential runtime" message.

After the split, RedosCheck.buildMessage() (S5852) no longer consults regexContainsBackReference at all:

case QUADRATIC_WHEN_OPTIMIZED -> isJava9OrHigher() ? Optional.empty() : Optional.of(MESSAGE);
default -> Optional.empty();  // LINEAR_WHEN_OPTIMIZED never reported

So on Java 9+ these backreference cases return empty from S5852 and are instead reported only by SuperLinearRegexCheck (S8786) with the message "...has super-linear performance due to backtracking." This is a genuine regression: an exponential ReDoS vulnerability is reclassified as a polynomial/super-linear code smell, and the user-facing message now understates the severity (calls exponential behaviour "super-linear"). The relabelled test expectations in RedosCheckSample.java (lines 34-35) and RedosCheckJava8.java (line 51) bake in this downgrade.

If the intent is truly to keep S5852 = exponential only, then the genuinely-exponential not-optimized cases of QUADRATIC_WHEN_OPTIMIZED/LINEAR_WHEN_OPTIMIZED should remain in S5852 (using the optimized flag, not just isJava9OrHigher()), with S8786 covering only the actually-polynomial cases to avoid both miscategorization and double reporting.

✅ Quality: S8786.html has broken markup in fix recommendations

📄 sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S8786.html:11-16
In S8786.html the 'How to fix it' list contains malformed HTML. The negated-character-class example renders as an empty <code></code> tag instead of showing something like [^,] (line ~11), and the possessive-quantifier bullet renders literal backticks: <code>+, *</code>, <code>?+</code> instead of ++, *+, ?+ (line ~15). These render as confusing/empty snippets in the rule description shown to users.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}