Regex Dos in Axum with Cockroachdb

A Regex Denial of Service (Regex DoS) occurs when a regular expression exhibits catastrophic backtracking on untrusted input, causing CPU usage to spike and blocking the event loop. In Axum, this risk is amplified when route extractors or validation logic rely on complex regex patterns and the data being validated originates from a Cockroachdb-backed source that may contain unexpectedly long or maliciously crafted strings.

Consider an Axum extractor that validates a path parameter against a regex to ensure it conforms to an expected format. If the regex is poorly constructed (e.g., using nested quantifiers on overlapping character classes), an attacker can supply input that causes exponential backtracking. Because Axum often deserializes request data and may later use values to build SQL queries for Cockroachdb, an attacker might intentionally send long, repetitive strings that trigger the regex engine to consume high CPU during parsing and validation. This becomes a vector for unauthenticated denial of service, especially when the endpoint is public-facing and does not enforce strict size or format constraints before the regex is applied.

When combined with Cockroachdb, the impact is indirect but significant: the Axum service can become unresponsive while attempting to validate or parse input, leading to increased latency or timeouts for legitimate database operations. Cockroachdb itself does not introduce regex vulnerabilities, but if Axum uses regex to validate primary keys, identifiers, or JSONB fields before inserting or querying Cockroachdb, a malicious payload can stall the application layer, indirectly affecting database throughput and availability. The vulnerability is not in Cockroachdb but in how Axum processes and validates input before it reaches the database.

Real-world patterns include using .* or .+ with quantifiers like * or + in overlapping groups without atomic groups or possessive quantifiers. For example, a route guard that validates an organization slug with ^([a-zA-Z0-9_-]+)*$ is susceptible because the nested quantifiers enable exponential backtracking on strings like aaaaaaaaaaaaaaaaX. Even if Cockroachdb stores sanitized identifiers, the Axum layer must reject such inputs early, using length limits and safe regex patterns to avoid tying up runtime resources.

To detect this during scanning, middleBrick runs checks against the unauthenticated attack surface, including input validation and rate limiting assessments. It does not modify your code or block traffic but highlights risky patterns such as vulnerable regex usage and missing size constraints on user-controlled data. By correlating findings with the OpenAPI specification and runtime behavior, the scanner can identify endpoints where regex validation intersects with database-driven workflows, helping you prioritize fixes that reduce CPU exhaustion risks.

Remediation focuses on avoiding catastrophic backtracking in regex patterns and ensuring validation occurs before any interaction with Cockroachdb. Prefer simple, non-overlapping character classes with bounded repetition, and enforce length limits on strings derived from user input. In Axum, implement extractors and guards that validate early and fail fast.

Instead of a nested quantifier pattern like ^([a-zA-Z0-9_-]+)*$, use a bounded, non-overlapping expression such as ^[a-zA-Z0-9_-]{1,64}$. This prevents exponential backtracking while still permitting valid identifiers. When validating identifiers that map to Cockroachdb columns or keys, keep regex simple and combine it with explicit length checks.

Example Axum extractor using a safe regex with length validation:

use axum::extract::Path;
use regex::Regex;
use std::sync::Arc;

/// Safe slug extractor that rejects patterns prone to catastrophic backtracking.
#[derive(Debug, Clone)]
struct SafeSlug(String);

impl SafeSlug {
    fn new(s: String) -> Result {
        // Simple, bounded character class with a length limit to prevent ReDoS.
        let re = Regex::new(r"^[a-zA-Z0-9_-]{1,64}$").expect("valid regex");
        if re.is_match(&s) {
            Ok(SafeSlug(s))
        } else {
            Err(axum::http::StatusCode::BAD_REQUEST)
        }
    }
}

/// Example route using the extractor.
async fn get_org_by_slug(
    Path(slug): Path,
) -> (axum::http::StatusCode, String) {
    // At this point, slug.0 is guaranteed to be safe for use in queries.
    (axum::http::StatusCode::OK, format!("org={}", slug.0))
}

When constructing SQL for Cockroachdb, continue to use parameterized queries to avoid injection, and ensure that validated slugs or identifiers are used as bind variables rather than string interpolation. For example:

use cockroachdb_rs::Connection;

async fn fetch_org(conn: &Connection, org_slug: &str) -> Result<(), Box> {
    // Use parameterized queries; org_slug has already been validated by SafeSlug.
    let row = conn
        .query_one("SELECT id, name FROM organizations WHERE slug = $1", &[&org_slug])
        .await?;
    // Process row...
    Ok(())
}

In middleware or guards, reject requests with suspiciously long segments before they reach regex validation. Combine this with rate limiting at the Axum layer to reduce the impact of automated attacks. middleBrick’s scans can highlight endpoints where regex validation occurs without length bounds or where patterns resemble known ReDoS constructs, enabling you to prioritize remediation in high-risk routes.