Command Injection in Axum with Jwt Tokens

Command injection occurs when an application passes untrusted input directly to a system shell or to a command interpreter. In Axum, this risk can emerge in endpoints that handle JWT tokens in an unsafe manner, for example when a token’s payload or claims are used to construct shell commands. Consider an endpoint that extracts a user identifier from a JWT claim and uses it to invoke an external utility via Rust’s Command. If the identifier is not validated or sanitized, an attacker can supply a token with a specially crafted claim (such as username or sub) that includes shell metacharacters to alter command behavior.

A concrete scenario: an API receives an Authorization header with a JWT, decodes it, reads a custom claim like department, and uses that value in a shell command to generate a report path. If the claim contains something like admin; cat /etc/passwd, the command injection can lead to unauthorized file reads or code execution. Because Axum does not inherently sanitize inputs derived from JWT claims, developers must explicitly validate and escape any data that reaches the shell. The risk is compounded when the JWT is accepted without strong validation (e.g., missing issuer checks or weak signature verification), allowing an attacker to manipulate claims that the application trusts implicitly.

Another angle is logging or debugging code that prints the token or its claims into a shell context. For instance, if a developer uses println! or a logging macro with user-influenced data that later gets processed by a shell-based tooling pipeline, injection becomes feasible. Even in pure Rust code, using std::process::Command with concatenated strings instead of a structured argument vector exposes the application. The combination of JWT-based identity and unsafe command construction bypasses typical input validation that might otherwise protect HTTP parameters.

An attacker may probe such endpoints with manipulated tokens to test for command injection, looking for behaviors like unexpected output, file changes, or network callbacks. Because the vulnerability resides in how Axum code uses external command invocation rather than in the framework itself, the presence of JWT handling does not inherently introduce the flaw; it is the unsafe integration that creates the path. Security checks that inspect authentication tokens must also examine downstream usage patterns, especially when claims influence process execution.

To detect this class of issue, scanners perform black-box testing by sending tokens with crafted claims and observing responses that indicate command execution, such as altered file contents or injected output. The presence of a valid JWT does not reduce the risk; it may in fact increase the impact if the token is associated with elevated logical roles within the application logic. Developers should treat JWT claims as untrusted input and apply strict allowlists, avoid shell interpretation entirely, and use language-native APIs that do not invoke a shell.

Remediation focuses on never passing untrusted JWT claim data directly to shell commands and on validating token contents rigorously. Below are concrete Axum examples in Rust that demonstrate secure handling.

1. Avoid shell invocation entirely. Use Rust’s standard library APIs for file and directory operations instead of shell commands. For example, to write a file based on a claim, prefer std::fs::write over spawning a shell process.

use axum::{{
    extract::Extension,
    response::IntoResponse,
    routing::get,
    Router,
}};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};
use serde::{Deserialize, Serialize};
use std::net::SocketAddr;
use std::path::Path;
use std::fs;

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    department: String,
    exp: usize,
}

async fn report_handler(
    Extension(secret): Extension,
    axum::extract::Header(auth_header): axum::extract::Header<String>,
) -> impl IntoResponse {
    let token = auth_header.strip_prefix("Bearer ").unwrap_or(&auth_header);
    let decoding_key = DecodingKey::from_secret(secret.as_ref());
    let mut validation = Validation::new(Algorithm::HS256);
    validation.validate_exp = true;
    let token_data = decode::