Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Spring supports Matrix variables. When Spring integration is used, Armeria calls Spring controllers via TomcatService or JettyService with the path that may contain matrix variables. In this situation, the Armeria decorators might not invoked because of the matrix variables. Let's see the following example: If an attacker sends a request with /important;a=b/resources, the request would bypass the authrorizer Patches - https://github.com/line/armeria-ghsa-wvp2-9ppw-337j/commit/9b0ec3e099cc05fbff11d7f1012a1dddb0000d0c Workarounds Users can add decorators using regex. e.g. "regex:^/important."
Recommended action: Upgrade to 1.24.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An attacker can access an Armeria server's local file system beyond its restricted directory by sending an HTTP request whose path contains %2F (encoded /), such as /files/..%2Fsecrets.txt, bypassing Armeria's path validation logic. Patches Armeria 1.13.4 or above contains the hardened path validation logic that handles %2F properly. Workarounds This vulnerability can be worked around by inserting a decorator that performs an additional validation on the request path, e.g. For more information If you have any questions or comments about this advisory: Open an issue in line/armeria Chat with us at Slack Credits This vulnerability was originally reported by Abdallah Zaher (elcayser-0x0a).
Recommended action: Upgrade to 1.13.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of Armeria 0.85.0 through and including 0.96.0 are vulnerable to HTTP response splitting, which allows remote attackers to inject arbitrary HTTP headers via CRLF sequences when unsanitized data is used to populate the headers of an HTTP response. Impact 1. Cross-User Defacement 2. Cache Poisoning 3. Cross-Site Scripting (XSS) 4. Page Hijacking Root Cause The root cause is due to the usage of Netty without the HTTP header validation. https://github.com/line/armeria/blob/f0d870fde1088114070be31b67f7df0a21e835c6/core/src/main/java/com/linecorp/armeria/common/DefaultHttpHeaders.java#L23 Patches This vulnerability has been patched in 0.97.0. References CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting') https://github.com/ratpack/ratpack/security/advisories/GHSA-mvqp-q37c-wf9j For more information If you have any questions or comments about this advisory: Open an issue in GitHub
Recommended action: Upgrade to 0.97.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Multiple timing attack vulnerabilities leading to the recovery of secrets based on the use of non-constant time compare function Impact String comparison method in multiple authentication validation in Armeria were known to be vulnerable to timing attacks. This vulnerability is caused by the insecure implementation of equals method from java.lang.String. While this attack is not practically possible, an attacker still has a potential to attack if the victim's server validates user by using equals method. We would like to thank @chrsow for pointing out the issue. Potentially vulnerable codes https://github.com/line/armeria/blob/f0d870fde1088114070be31b67f7df0a21e835c6/core/src/main/java/com/linecorp/armeria/server/auth/OAuth2Token.java#L54 https://github.com/line/armeria/blob/f0d870fde1088114070be31b67f7df0a21e835c6/core/src/main/java/com/linecorp/armeria/server/auth/BasicToken.java#L64 Patches There are two options to patch this issue. 1. Remove equals method; it has been exclusively…
Recommended action: Upgrade to 0.97.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.