Sandbox Escape in Axum with Mutual Tls

A sandbox escape in an Axum service that uses Mutual Transport Layer Security (mTLS) occurs when an attacker who has compromised one component can violate security boundaries that should have been enforced by the mutual authentication layer. In Axum, a Rust web framework built on Tower and Hyper, mTLS is typically enforced at the transport or middleware layer before requests reach application logic. If the application incorrectly trusts request metadata that should have been validated by mTLS, or if it exposes internal endpoints or behaviors that bypass mTLS checks, the boundary between trusted and untrusted execution contexts can weaken.

Consider a scenario where an Axum service uses mTLS to authenticate clients, but also exposes an administrative endpoint that does not enforce client certificate verification, or where the application deserializes request data into types that allow type confusion or path traversal. An attacker who bypasses or misuses the authenticated channel may exploit unsafe routing, unchecked deserialization, or improper handling of forwarded headers to reach internal routes that were intended to be isolated. For example, if the application uses request extensions populated by middleware without re-verifying the client identity on each handler, a compromised component could inject crafted requests that appear authorized.

Another vector involves configuration mismatches: the server enforces mTLS but the client certificates are not properly validated (e.g., missing hostname verification or incomplete certificate chain validation). This can allow an attacker with a stolen or forged certificate to present as a legitimate client and access endpoints that expose sensitive operations, such as health checks, metrics, or administrative commands. In Axum, this often manifests as handlers that assume identity derived from TLS metadata is trustworthy without additional checks, enabling privilege escalation or unauthorized operations that constitute a sandbox escape.

The interplay between Axum’s routing and the mTLS layer is critical. Axum’s router matches paths and methods to handlers; if the application defines overly permissive routes or uses nested routers without scoping, an attacker may leverage authenticated mTLS sessions to traverse unintended paths. Real-world patterns include using middleware to set identity claims in request extensions and then failing to validate those claims in downstream handlers. This can lead to confused deputy scenarios where a handler executes with elevated trust based on corrupted context, allowing an attacker to perform actions or access data outside the intended sandbox.

From an API security scanner perspective, middleBrick checks for such boundary violations by correlating OpenAPI specifications with runtime behavior. For mTLS-protected APIs, it ensures that authentication requirements are consistently enforced across all paths and that no routes bypass certificate validation. It also inspects handlers for unsafe consumption of request data and checks whether extensions or metadata introduced by middleware are re-validated before use. These checks help identify configurations where mTLS is present but insufficiently coupled with application-level authorization, which can enable sandbox escapes in Axum services.

To prevent sandbox escapes in Axum with mTLS, enforce strict validation at both the transport and application layers. Always verify client certificates completely, including chain validation and hostname verification, and avoid relying on request extensions that are not re-validated in handlers. Use Axum’s middleware to extract and validate identity, and ensure that authorization checks are applied consistently across all routes.

Example 1: Basic mTLS enforcement with proper validation in Axum

use axum::{routing::get, Router, extract::Extension};
use hyper_rustls::TlsAcceptor;
use std::net::SocketAddr;
use tokio::net::TcpListener;
use axum::extract::connect_info::ConnectInfo;
use hyper::server::conn::auto::Builder;
use hyper::service::service_fn;
use std::sync::Arc;
use rustls_pemfile::{certs, pkcs8_private_keys};
use std::io::BufReader;
use std::fs::File;

async fn admin_handler() -> &'static str {
    "admin endpoint"
}

async fn hello_handler() -> &'static str {
    "hello"
}

#[tokio::main]
async fn main() {
    // Load server certificate and key
    let cert_file = &mut BufReader::new(File::open("server.crt").unwrap());
    let key_file = &mut BufReader::new(File::open("server.key").unwrap());
    let cert_chain = certs(cert_file).unwrap();
    let mut keys = pkcs8_private_keys(key_file).unwrap();

    let tls_config = rustls::ServerConfig::builder()
        .with_safe_defaults()
        .with_client_cert_verifier(Arc::new(
            rustls::server::AllowAnyAuthenticatedClient::new(vec![])
        ))
        .with_single_cert(cert_chain, keys.remove(0))
        .unwrap();

    let tls_acceptor = TlsAcceptor::from(Arc::new(tls_config));

    // Define routes with middleware that enforces mTLS-derived identity
    let app = Router::new()
        .route("/admin", get(admin_handler))
        .route("/hello", get(hello_handler))
        .layer(axum::middleware::from_fn_with_state(
            (),
            move |Extension(state), request: axum::http::Request<_>, next| async move {
                // Here you would validate client certificate details from request extensions
                // provided by the TLS layer, ensuring the identity is trustworthy before proceeding.
                // This is a placeholder for mTLS identity validation logic.
                Ok(next.run(request).await)
            },
        ));

    let listener = TcpListener::bind("127.0.0.1:8443").await.unwrap();
    let builder = Builder::new(tls_acceptor);
    builder.serve_connection(listener, service_fn(move |req| {
        let app = app.clone();
        async move { Ok::<_, std::convert::Infallible>(app.oneshot(req).await.unwrap()) }
    })).await.unwrap();
}

Example 2: Explicit client certificate validation in request handling

use axum::{routing::get, Router, extract::Request};
use axum::middleware::Next;
use std::convert::Infallible;
use axum::http::StatusCode;
use axum::response::IntoResponse;

async fn mtls_auth_middleware(
    request: Request,
    next: Next,
) -> Result {
    // Extract peer certificate from request extensions (set by TLS layer)
    // In practice, this would use a type-safe extractor that validates certificate details.
    let peer_certs = request.extensions().get::>()
        .ok_or((StatusCode::UNAUTHORIZED, "Missing client certificate".to_string()))?;

    if peer_certs.is_empty() {
        return Err((StatusCode::UNAUTHORIZED, "No client certificate provided".to_string()));
    }

    // Additional validation: check certificate fields, revocation, etc.
    // For this example, we assume validation passed.
    Ok(next.run(request).await)
}

async fn protected_handler() -> &'static str {
    "protected"
}

#[tokio::main]
async fn main() {
    let app = Router::new()
        .route("/protected", get(protected_handler))
        .layer(axum::middleware::from_fn(mtls_auth_middleware));

    // Server setup with TLS acceptor as in Example 1
    // ...
}

Key remediation practices

• Validate the full certificate chain and perform hostname verification on the server side.
• Do not treat mTLS-authenticated identity as sufficient for authorization; apply explicit checks in handlers or dedicated authorization middleware.
• Ensure that any metadata or extensions derived from TLS are re-validated in each handler to prevent confused deputy issues.
• Use strict routing definitions in Axum to avoid unintended path traversal via authenticated sessions.
• Regularly scan your API with tools like middleBrick to detect misconfigurations where mTLS is present but insufficiently enforced across endpoints.