CWE-1333 Base Draft High likelihood

Inefficient Regular Expression Complexity

This vulnerability occurs when an application uses a poorly constructed regular expression that can trigger catastrophic backtracking, leading to extreme CPU consumption and potential…

Definition

What is CWE-1333?

This vulnerability occurs when an application uses a poorly constructed regular expression that can trigger catastrophic backtracking, leading to extreme CPU consumption and potential denial-of-service.
The root cause lies in how many regex engines handle failed matches through a process called backtracking. When a pattern doesn't match, the engine tries different paths by rewinding to earlier decision points. A poorly designed regex—often involving nested quantifiers (like (a+)+) or ambiguous patterns—can create an exponential number of these backtracking paths relative to the input length. Attackers exploit this by providing carefully crafted, non-matching input that forces the engine to evaluate all possible backtracking paths. This causes CPU usage to spike dramatically, potentially freezing the application or server. The risk is highest when processing user-controlled strings without complexity limits, making regex-based input validation a common attack vector for denial-of-service.
Auswirkungen in der Praxis

Real-world CVEs caused by CWE-1333

  • server allows ReDOS with crafted User-Agent strings, due to overlapping capture groups that cause excessive backtracking.

  • npm package for user-agent parser prone to ReDoS due to overlapping capture groups

  • Markdown parser uses inefficient regex when processing a message, allowing users to cause CPU consumption and delay preventing processing of other messages.

  • Long string in a version control product allows DoS due to an inefficient regex.

  • Javascript code allows ReDoS via a long string due to excessive backtracking.

  • ReDoS when parsing time.

  • ReDoS when parsing documents.

  • ReDoS when validating URL.

Wie Angreifer es ausnutzen

Angreiferpfad Schritt für Schritt

  1. 1

    This example attempts to check if an input string is a "sentence" [REF-1164].

  2. 2

    The regular expression has a vulnerable backtracking clause inside (\w+\s?)*$ which can be triggered to cause a Denial of Service by processing particular phrases. To fix the backtracking problem, backtracking is removed with the ?= portion of the expression which changes it to a lookahead and the \2 which prevents the backtracking. The modified example is:

  3. 3

    Note that [REF-1164] has a more thorough (and lengthy) explanation of everything going on within the RegEx.

  4. 4

    This example attempts to check if an input string is a "sentence" and is modified for Perl [REF-1164].

  5. 5

    The regular expression has a vulnerable backtracking clause inside (\w+\s?)*$ which can be triggered to cause a Denial of Service by processing particular phrases. To fix the backtracking problem, backtracking is removed with the ?= portion of the expression which changes it to a lookahead and the \2 which prevents the backtracking. The modified example is:

Verwundbares Codebeispiel

Vulnerable JavaScript

This example attempts to check if an input string is a "sentence" [REF-1164].

Verwundbar JavaScript
var test_string = "Bad characters: $@#";
 var bad_pattern = /^(\w+\s?)*$/i;
 var result = test_string.search(bad_pattern);
Sicheres Codebeispiel

Secure JavaScript

The regular expression has a vulnerable backtracking clause inside (\w+\s?)*$ which can be triggered to cause a Denial of Service by processing particular phrases. To fix the backtracking problem, backtracking is removed with the ?= portion of the expression which changes it to a lookahead and the \2 which prevents the backtracking. The modified example is:

Sicher JavaScript
var test_string = "Bad characters: $@#";
 var good_pattern = /^((?=(\w+))\2\s?)*$/i;
 var result = test_string.search(good_pattern);
What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Präventions-Checkliste

How to prevent CWE-1333

  • Architecture and Design Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.
  • System Configuration Set backtracking limits in the configuration of the regular expression implementation, such as PHP's pcre.backtrack_limit. Also consider limits on execution time for the process.
  • Implementation Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.
  • Implementation Limit the length of the input that the regular expression will process.
Erkennungssignale

How to detect CWE-1333

SAST High

Führe statische Analyse (SAST) auf der Codebasis aus und suche im Datenfluss nach dem unsicheren Muster.

DAST Moderate

Führe dynamische Application-Security-Tests gegen den Live-Endpoint aus.

Runtime Moderate

Beobachte Runtime-Logs auf ungewöhnliche Exception-Traces, fehlerhafte Eingaben oder Versuche, Autorisierung zu umgehen.

Code review Moderate

Code Review: Markiere jeden neuen Code, der Eingaben von dieser Oberfläche ohne validierte Framework-Helper verarbeitet.

CWE-1333

Don't catalog this weakness. Prove it's reachable.

Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.

Häufig gestellte Fragen

Frequently asked questions

Was ist CWE-1333?

This vulnerability occurs when an application uses a poorly constructed regular expression that can trigger catastrophic backtracking, leading to extreme CPU consumption and potential denial-of-service.

Wie gravierend ist CWE-1333?

MITRE stuft die Exploit-Wahrscheinlichkeit als hoch ein — diese Schwachstelle wird aktiv in freier Wildbahn ausgenutzt und sollte priorisiert behoben werden.

Welche Sprachen oder Plattformen sind von CWE-1333 betroffen?

MITRE hat für diese CWE keine betroffenen Plattformen spezifiziert — sie kann in den meisten Anwendungs-Stacks auftreten.

Wie kann ich CWE-1333 verhindern?

Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers. Set backtracking limits in the configuration of the regular expression implementation, such as PHP's pcre.backtrack_limit. Also consider limits on execution time for the process.

Wie erkennt und behebt Plexicus CWE-1333?

Die SAST-Engine von Plexicus erkennt die Datenfluss-Signatur von CWE-1333 bei jedem Commit. Bei einem Treffer öffnet unser Codex-Remedium-Agent einen Fix-PR mit korrigiertem Code, Tests und einer einzeiligen Zusammenfassung für den Reviewer.

Wo erfahre ich mehr über CWE-1333?

MITRE veröffentlicht die kanonische Definition unter https://cwe.mitre.org/data/definitions/1333.html. Für ergänzende Hinweise kannst du auch die OWASP- und NIST-Dokumentation heranziehen.

Bereit, das Wesentliche zu validieren?

Bereit zu validieren, was zählt.

Plexicus ist Proof-Driven AppSec: validierte Funde, kontextuelles Verständnis und geprüfte Remediation — in Evidenz verankert, mit Ihnen gescoped.

Qualifizierung

Prüfen Sie, ob AI Swarm Pentest zu Ihrer Umgebung passt.

Teilen Sie den wichtigsten Kontext. Wir prüfen den Umfang und nennen den nächsten kommerziellen Schritt.

Vor dem Absenden — prüfen Sie, ob Sie passen

0 / 280

Keine Verpflichtung. Wenn Sie nicht passen, sagen wir es Ihnen.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorized target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)
Private Runde Für Investoren