Michael Mullins

Improper validation of resource URL attributes allows an unauthenticated remote attacker to read files from the web application, including files under WEB-INF that the servlet container would not otherwise serve. The locale, style, and variation attributes decoded from a package resource URL are spliced into the resource lookup path without being checked for path separators. Because the `IPackageResourceGuard` and `WebApplicationPath` do not inspect the attacker-controlled portion of the path, a crafted request can escape the intended package directory on servlet containers that normalize `..` in `ServletContext.getResource()`. The readable files are limited to extensions permitted by the configured `IPackageResourceGuard`. Applications using the blocklist-based `PackageResourceGuard` or custom patterns may disclose configuration files such as `web.xml`. Additionally, the lookup process can act as an existence oracle for arbitrary paths.

An uncontrolled resource consumption issue exists where an application exposing an endpoint for collecting Content Security Policy (CSP) violation reports reads the submitted report into memory without limits. This allows a single request to exhaust the heap, leading to a denial of service for other users. These endpoints are typically accessible without authentication. The core distribution does not map such an endpoint by default, meaning applications that do not collect violation reports are not affected.

An uncontrolled resource consumption issue exists in the JSON plugin. When an application is configured to populate actions from a JSON request body, the plugin reads the body into memory without a bound on the accepted size. This can allow a single request to exhaust the heap, resulting in a denial of service for other users. The configurable JSON input length limit does not prevent this behavior. This issue only affects applications that use the optional JSON plugin with JSON request-body handling enabled.

The software fails to sufficiently validate URL addresses before returning local files, allowing potential access to files on the developer's machine. This occurs in the `getFilenameFromUrl()` function when the `publicPath` is configured without a trailing slash. An attacker can craft a request where a dot-dot sequence is embedded within a path segment (e.g., `/assets../.env`), bypassing the traversal guard. The system then slices the path at a fixed offset, resulting in a path traversal that resolves one directory above the output path. This issue specifically affects environments where the middleware is backed by the physical filesystem, such as when the `writeToDisk` variable is set to `true` or a custom `outputFileSystem` is provided. If the development server is exposed to a network or allows cross-origin requests, an attacker could exfiltrate sensitive files like passwords or source code.