Command Injection in Actix with Jwt Tokens

Command Injection occurs when an API endpoint constructs a shell or system command using unsanitized input. In Actix-based services that also handle JWT Tokens for authentication, a typical pattern is to authenticate a request, extract a claim (such as a username or role), and then use that claim in a shell command. Because the validation of JWT Tokens often focuses on signature and expiry, developers may mistakenly trust claims extracted from a valid token as safe for system-level operations. This trust boundary mismatch creates a path for Command Injection: an attacker who can influence a claim (or a parameter that is concatenated with a claim) can inject shell metacharacters that alter command semantics.

For example, consider an endpoint that receives a JWT Token, decodes it, reads a sub or custom claim like username, and then passes that value to a command such as grep or tar via a shell call. If the claim contains characters like ;, &, |, or backticks, and the application does not sanitize or escape them, the command executed on the host will include unintended instructions. This becomes especially risky when the endpoint also exposes unauthenticated or weakly scoped routes, because an attacker can probe the API without valid JWT Tokens and still trigger the vulnerable command path if input validation is weak. The combination of a commonly used web framework like Actix and the prevalence of JWT Tokens for stateless auth increases the likelihood that such patterns appear in services.

An attacker might send a request with a manipulated token or parameter like username=admin;cat /etc/passwd. If the server builds a shell command such as grep {username} /var/log/app.log without proper escaping, the injected cat /etc/passwd runs with the same privileges as the Actix process. Findings from middleBrick scans often highlight this when unauthenticated or low-privilege probes reveal endpoints that accept external input and invoke shell utilities. Because JWT Tokens are often treated as authoritative after verification, developers may skip additional input validation, inadvertently widening the attack surface. This illustrates why even strong cryptographic verification of JWT Tokens does not guarantee safety downstream where system commands are constructed.

Remediation centers on never passing untrusted data directly to a shell and strictly validating and encoding all inputs derived from JWT Tokens. Below are concrete Actix examples that demonstrate safe patterns.

Insecure example to avoid:

use actix_web::{get, web, HttpResponse};
use jsonwebtoken::{decode, Algorithm, Validation, DecodingKey};

#[get("/log")]
async fn get_log(query: web::Query, token: actix_web::HttpRequest) -> HttpResponse {
    let token_str = token.headers().get("Authorization")
        .and_t1::to_str().unwrap_or("")
        .strip_prefix("Bearer ").unwrap_or("");
    let token_data = decode::(
        token_str,
        &DecodingKey::from_secret(SECRET.as_ref()),
        &Validation::new(Algorithm::HS256),
    ).map_err(|_| HttpResponse::Unauthorized().finish())?;
    let username = token_data.claims.username;
    // Dangerous: shell command built from token claim
    let output = std::process::Command::new("grep")
        .arg(format!("{}", username))
        .arg("/var/log/app.log")
        .output()
        .expect("failed to execute process");
    HttpResponse::Ok().body(String::from_utf8_lossy(&output.stdout).to_string())
}

In this example, username from the JWT Token is concatenated into a command argument without validation, enabling Command Injection if the claim contains shell metacharacters.

Secure remediation:

1) Avoid the shell entirely and use direct filesystem or regex operations. If a shell is unavoidable, use an argument vector without a shell and strictly allowlist the input.

use actix_web::{get, web, HttpResponse};
use jsonwebtoken::{decode, Algorithm, Validation, DecodingKey};
use regex::Regex;

#[get("/log")]
async fn get_log_safe(query: web::Query, token: actix_web::HttpRequest) -> HttpResponse {
    let token_str = token.headers().get("Authorization")
        .and_t1::to_str().unwrap_or("")
        .strip_prefix("Bearer ").unwrap_or("");
    let token_data = decode::(
        token_str,
        &DecodingKey::from_secret(SECRET.as_ref()),
        &Validation::new(Algorithm::HS256),
    ).map_err(|_| HttpResponse::Unauthorized().finish())?;
    let username = token_data.claims.username;
    // Validate against a strict allowlist: only alphanumeric and underscore
    let re = Regex::new(r"^[a-zA-Z0-9_]+$").unwrap();
    if !re.is_match(&username) {
        return HttpResponse::BadRequest().body("invalid username format");
    }
    // Safe: no shell, direct path and argument separation
    let output = std::process::Command::new("grep")
        .arg(&username)
        .arg("/var/log/app.log")
        .output()
        .expect("failed to execute process");
    HttpResponse::Ok().body(String::from_utf8_lossy(&output.stdout).to_string())
}

2) If you must use a shell (not recommended), do not pass untrusted data into shell commands; instead, sanitize via a strict allowlist and use a wrapper that disables metacharacters. In practice, prefer the no-shell approach shown above.

middleBrick scans can detect patterns where JWT Token claims flow into command construction, and the scanner will surface Command Injection findings with severity and remediation guidance. Following the principle of least privilege and avoiding shell invocation significantly reduces risk.