CVE-2026-54148 in http4k
Summary
by MITRE • 09/18/2026
http4k is a functional toolkit for Kotlin HTTP applications. Prior to 4.51.0.0, 5.42.0.0, and 6.50.0.0, DigestAuthProvider.verify in http4k-security-digest does not compare the uri parameter in an Authorization: Digest response with the actual request URL. An attacker who captures a valid Digest authentication response can replay it against another URL served by the same realm, bypassing the per-request-URI binding and potentially gaining unauthorized read or write access. This issue is fixed in versions 4.51.0.0, 5.42.0.0, and 6.50.0.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The http4k library serves as a functional toolkit for building HTTP applications in the Kotlin programming language, providing developers with robust tools to handle various aspects of web service development including security protocols. Within this ecosystem, the Digest authentication mechanism is implemented through the http4k-security-digest module, which relies on the standard challenge-response protocol defined by RFC 2617 and later updated by RFC 7616 for HTTP Digest Access Authentication. This method was designed to provide a more secure alternative to Basic authentication by avoiding the transmission of plaintext passwords over the network. However, prior to versions 4.51.0.0, 5.42.0.0, and 6.50.0.0, a critical implementation flaw existed within the DigestAuthProvider.verify method that undermined the integrity of this authentication scheme by failing to enforce strict binding between the authenticated credentials and the specific resource being accessed.
The technical root cause of this vulnerability lies in the verification logic used when processing incoming Authorization headers containing Digest responses. According to the HTTP Digest specification, the client must compute a response hash using several parameters including the username, realm, password, HTTP method, and specifically the URI requested by the client. This URI parameter is crucial because it ensures that an authentication token generated for one specific endpoint cannot be reused for another, even if both endpoints reside within the same security realm. In the affected versions of http4k, the verify function neglected to compare the uri extracted from the Authorization header against the actual request URL received by the server. This omission effectively decoupled the credential validation process from the resource access control mechanism, creating a significant logical flaw in the authentication workflow.
From an operational perspective, this vulnerability allows for a straightforward replay attack scenario with severe consequences. An attacker who intercepts or captures a valid Digest authentication response intended for one URL can subsequently transmit that same captured response to a different endpoint served by the same realm. Because the server does not validate whether the URI in the header matches the target of the current request, it will accept the credentials as valid for the new destination. This bypasses per-request-URI binding controls and potentially grants the attacker unauthorized read or write access to resources they should not be able to reach. For example, if a user authenticates successfully to view public data at one path, an attacker could replay that authentication token to modify sensitive configuration files located in another part of the application, provided both paths fall under the same digest realm protection.
This flaw is classified as CWE-287 Improper Authentication because it represents a failure in correctly verifying identity and access rights during the login process. Specifically, it aligns with CWE-345 Insufficient Verification of Data Authenticity since the server fails to verify that the data (the authentication response) corresponds accurately to the context (the specific request URI). In terms of offensive security frameworks such as MITRE ATT&CK, this vulnerability facilitates techniques related to Credential Replay and potentially Privilege Escalation if the replayed credentials belong to a user with higher privileges than intended for the target resource. The lack of strict binding allows an adversary to leverage stolen or intercepted authentication material across multiple endpoints within the same security domain without needing additional reconnaissance or credential cracking efforts.
To mitigate this vulnerability, organizations using http4k must upgrade immediately to version 4.51.0.0, 5.42.0.0, or 6.50.0.0 where the DigestAuthProvider.verify method has been corrected to strictly compare the uri parameter from the Authorization header with the actual request URL. Until such an update is applied in legacy systems, developers should consider implementing additional custom validation layers that explicitly check URI consistency before processing authentication tokens. Furthermore, it is advisable to enforce HTTPS across all communications to prevent the initial capture of Digest responses by network eavesdroppers, thereby reducing the attack surface for replay attacks even if other mitigations are temporarily insufficient. Regular security audits and dependency updates remain essential practices to maintain the integrity of HTTP-based applications against evolving authentication bypass techniques.