Rootingg

**Name of the Vulnerable Software and Affected Versions** Hono versions prior to 4.12.25 **Description** On AWS Lambda, the ALB single-header response and the VPC Lattice v2 response join multiple `Set-Cookie` headers into a single comma-separated value. According to RFC 6265, each cookie must be its own header line. Since commas are valid characters within cookie attributes, such as `Expires` dates, clients are unable to correctly split the combined value back into individual cookies, leading to cookies being silently dropped or misparsed. This can result in the failure of session, CSRF, or preference cookies, potentially breaking user sessions or forcing re-authentication. This issue specifically affects applications running on AWS Lambda behind an ALB in single-header mode or VPC Lattice v2. **Recommendations** Update to version 4.12.25.

**Name of the Vulnerable Software and Affected Versions** Hono versions prior to 4.12.25 **Description** The Body Limit Middleware trusts the `Content-Length` header to determine if a request body is within the allowed limit. In environments such as AWS Lambda (including API Gateway v1/v2, ALB, VPC Lattice, and Lambda@Edge), the body is delivered fully buffered, and the adapter reconstructs the request using the client-declared `Content-Length` without verifying if it matches the actual payload size. This allows a client to specify a small `Content-Length` while sending a significantly larger body, bypassing the configured limit. When `Content-Length` is present and `Transfer-Encoding` is absent, the middleware permits the request if the declared value is small enough. This can lead to increased CPU and memory consumption per request as handlers process oversized payloads, although the impact is limited by the platform's overall request size limits. **Recommendations** Update to version 4.12.25.

**Name of the Vulnerable Software and Affected Versions** Hono versions prior to 4.12.25 **Description** On AWS Lambda@Edge, CloudFront delivers request headers that appear multiple times as separate entries. The adapter uses the `Headers.set` function instead of `Headers.append`, causing each subsequent value to overwrite the previous one, meaning only the final value reaches the application. This results in the silent truncation of repeated request headers such as `X-Forwarded-For`, `Forwarded`, and `Via` to a single value. Consequently, request middleware receives incomplete data instead of the full chain. For applications utilizing the `X-Forwarded-For` chain for access control, this can weaken or alter security decisions, and for auditing purposes, the hop history is lost. **Recommendations** Update to version 4.12.25.

**Name of the Vulnerable Software and Affected Versions** Hono versions prior to 4.12.21 **Description** In the `app.mount()` function, the mount prefix is stripped from the incoming request path using the raw URL pathname, whereas route matching is conducted against the percent-decoded path. This inconsistency leads to the prefix being removed from the incorrect position when the path includes percent-encoded multi-byte characters, causing the mounted sub-application to receive an incorrect path. **Recommendations** Update to version 4.12.21.

**Name of the Vulnerable Software and Affected Versions** microlight.js version 0.0.7 **Description** A null pointer dereference issue was discovered in a lightweight syntax highlighting library. The library fails to validate the result of a regular expression match before accessing its properties when processing elements with non-standard CSS color values, leading to an uncaught TypeError and potential application crash. **Recommendations** For microlight.js version 0.0.7, consider updating to a newer version that addresses this issue, as the current version fails to properly handle non-standard CSS color values, leading to potential application crashes. At the moment, there is no information about a newer version that contains a fix for this vulnerability.