Spring4shell in Axum with Mutual Tls

Spring4Shell (CVE-2022-22965) targets a vulnerability in Spring MVC and Spring WebFlux where data binding can lead to arbitrary code execution when specific conditions align: a mutable data binder, a target object that exposes a setter for an arbitrary property, and a payload that reaches that setter. Axum is a Rust web framework, but when Axum services are implemented via a JVM-based runtime (e.g., using JNI or hosting a JVM service alongside Rust), or when Axum proxies or interoperates with Spring-based backends, the attack surface can include Spring components.

Mutual TLS (mTLS) ensures client authentication via certificates, which reduces the risk of unauthorized access. However, mTLS does not reduce the exploitability of Spring4shell if an authenticated client can still send crafted HTTP requests to vulnerable Spring endpoints. In a setup where Axum terminates TLS and forwards requests to an upstream Spring service with mTLS between Axum and the client, the presence of mTLS may create a false sense of security. If the upstream Spring service is reachable only via the Axum proxy and the proxy does not strictly validate or sanitize inputs before forwarding, an authenticated client can still deliver malicious payloads to the Spring layer.

The risk is compounded when the Axum service exposes endpoints that mirror Spring controller routes or when Axum is used in a mixed-language environment where some handlers are implemented in Java/Spring. For example, an endpoint like /api/users/{id} in Axum might forward to a Spring backend that performs data binding on the id parameter. If that backend uses a mutable object with setters and does not apply strict validation, an attacker can attempt property manipulation or injection similar to known Spring4shell patterns. Input validation and strict schema enforcement at the Axum layer are critical to prevent malicious payloads from reaching the Spring stack.

During a middleBrick scan, endpoints that accept user input and forward or process it in a JVM-based service will be tested for injection attempts and improper data binding. The scanner checks for signs of uncontrolled reflection, expression language injection, and unexpected object graph mutations that can indicate exposure to Spring4shell-style attacks. Even with mTLS in place, without rigorous input validation and separation of concerns between the edge layer (Axum) and the business logic layer (Spring), the vulnerability remains actionable for an authenticated attacker.

Remediation does not rely on mTLS alone. You must validate and sanitize all inputs at the boundary, enforce strict schema definitions, and avoid exposing mutable Java objects with setters to user-controlled data. MiddleBrick findings can highlight endpoints where input validation is insufficient and where runtime behavior may allow unintended property setting, guiding you to apply framework-specific hardening and architectural separation.

To secure Axum services with mutual TLS and reduce the risk of forwarding malicious payloads to downstream Spring components, implement strict client certificate validation and input handling. Below are concrete Rust code examples using axum, hyper, and rustls to configure mTLS and ensure only authorized clients can invoke endpoints.

First, set up a TLS acceptor that requests and verifies client certificates:

use axum::Server;
use hyper::service::service_fn;
use rustls::{Certificate, PrivateKey, ServerConfig};
use rustls_pemfile::{certs, pkcs8_private_keys};
use std::fs::File;
use std::io::BufReader;
use std::net::SocketAddr;
use std::sync::Arc;

async fn build_tls_config() -> Arc<ServerConfig> {
    let mut cert_file = BufReader::new(File::open("ca.crt").expect("cannot open CA cert"));
    let mut cert_key_file = BufReader::new(File::open("server.key").expect("cannot open server key"));

    let cert_chain = certs(&mut cert_file)
        .collect::

use axum::extract::Query;
use serde::Deserialize;
use validator::Validate;

#[derive(Debug, Deserialize, Validate)]
struct UserParams {
    #[validate(range(min = 1))]
    id: u64,
    #[validate(length(min = 1))]
    name: String,
}

async fn get_user(Query(params): Query<UserParams>) -> String {
    params.validate().expect("invalid params");
    format!("User {{ id: {}, name: {} }}", params.id, params.name)
}