Dangling Dns in Axum with Jwt Tokens

A dangling DNS configuration combined with JSON Web Token (JWT) handling in an Axum service can expose authentication bypass or host confusion vulnerabilities. Axum is a Rust web framework where routes and middleware are explicitly composed; if JWT validation logic is applied inconsistently across routes or relies on hostname-based routing, an attacker can exploit DNS records that point to unexpected or leftover endpoints.

In this scenario, a service might validate JWTs in one route group under a primary domain (api.example.com) but omit validation in another route that is accidentally exposed via a dangling DNS entry (e.g., dev.api.example.com or an orphaned subdomain). Because Axum matches routes by path and method, not by hostname, a request to the dangling subdomain can bypass intended authorization checks if the JWT middleware is not applied uniformly. Additionally, if the service uses hostname-sensitive claim validation (such as custom audience or issuer checks that include the hostname), an attacker controlling a dangling DNS record can present a token that appears valid for the intended hostname but is accepted by the misconfigured endpoint.

During a middleBrick scan, this combination is tested by probing unauthenticated endpoints and analyzing OpenAPI specs and runtime behavior for missing authentication on routes that should require JWTs. The scanner checks for inconsistent auth application across hosts and flags cases where hostname-based routing or claim validation is not enforced. Real-world attack patterns like token replay to overlooked subdomains, or exploitation of misconfigured CNAME records that point to deprecated services, map to the Authentication and BOLA/IDOR checks. These tests reveal whether JWT validation is tied to the intended endpoint surface and whether dangling DNS records expose weaker paths.

An example of unsafe Axum routing where JWT middleware is applied only to a specific router that does not cover all intended paths:

use axum::{routing::get, Router};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};

async fn validate_token(headers: &axum::http::HeaderMap) -> Result, (axum::http::StatusCode, String)> {
    let token = headers.get("authorization")
        .and_tx(|h| h.to_str().ok())
        .and_then(|s| s.strip_prefix("Bearer "))
        .ok_or((axum::http::StatusCode::UNAUTHORIZED, "Missing token".to_string()))?;
    let decoding_key = DecodingKey::from_secret("secret".as_ref());
    let validation = Validation::new(Algorithm::HS256);
    decode::(token, &decoding_key, &validation).map_err(|_| (axum::http::StatusCode::UNAUTHORIZED, "Invalid token".to_string()))
}

// Protected router with JWT middleware applied
fn protected_router() -> Router {
    Router::new()
        .route("/me", get(|headers: axum::http::HeaderMap| async move {
            validate_token(&headers).await.map(|data| format!("user: {}", data.claims.sub))
        }))
        .layer(axum::middleware::from_fn_with_state((), |_state, request, next| async move {
            // middleware that calls validate_token and passes claims
            next.run(request).await
        }))
}

// Public router without JWT enforcement
fn public_router() -> Router {
    Router::new()
        .route("/health", get(|| async { "ok" }))
}

fn app() -> Router {
    Router::new()
        .merge(protected_router())
        .merge(public_router())
}