🔒 Fix ReDoS vulnerability in sudo_sensitive rule#89
🔒 Fix ReDoS vulnerability in sudo_sensitive rule#89google-labs-jules[bot] wants to merge 1 commit into
Conversation
Replaced the vulnerable unbounded `.*` wildcard in the `sudo_sensitive` rule's regex with a deterministic token matching sequence `(?:[^\s;&|]+\s+)*`. This prevents catastrophic backtracking (ReDoS) when large strings are evaluated while ensuring accurate matching of sudo command parameters. Also correctly appended word boundaries only to command keywords ending in word characters.
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
🎯 What: The
⚠️ Risk: The vulnerability allowed highly inefficient backtracking evaluation when parsing long strings, which could result in severe CPU utilization spikes or Denial of Service conditions.
sudo_sensitiveregex pattern contained a Catastrophic Regular Expression Denial of Service (ReDoS) vulnerability.🛡️ Solution: Removed the unbound
.*sequence and replaced it with(?:[^\s;&|]+\s+)*to enforce deterministic, bounded processing. Explicit word boundaries (\b) were carefully added only to the commands that end in word characters to prevent partial word false positives without breaking rules that match spaces or non-word characters.PR created automatically by Jules for task 16342366653819169046 started by @zknpr