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
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The development server contains a path traversal vulnerability on Windows when serving files from servedir. Due to the use of path.Clean() (which only normalizes forward-slash / separators) instead of a Windows-aware path normalization function, it is possible to craft requests using backslashes (\) that bypass the intended directory containment logic. An attacker can escape the configured servedir root and access arbitrary files on the filesystem. This issue affects Windows environments only. Details The request path is sanitized using: However: - path.Clean() is POSIX-style and only understands / (docs: https://pkg.go.dev/path#Clean) - On Windows, \ is a valid path separator - path.Clean() does not treat \ as a separator Later, the server constructs the absolute path: If queryPath contains sequences such as: path.Clean() will not normalize them, but the Windows filesystem will interpret \ as directory separators when resolving absPath. Because the implementation does not…
Recommended action: Upgrade to 0.28.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
esbuild allows any websites to send any request to the development server and read the response due to default CORS settings. Details esbuild sets Access-Control-Allow-Origin: header to all requests, including the SSE connection, which allows any websites to send any request to the development server and read the response. https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serveother.go#L121 https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serveother.go#L363 Attack scenario: 1. The attacker serves a malicious web page (http://malicious.example.com). 1. The user accesses the malicious web page. 1. The attacker sends a fetch('http://127.0.0.1:8000/main.js') request by JS in that malicious web page. This request is normally blocked by same-origin policy, but that's not the case for the reasons above. 1. The attacker gets the content of http://127.0.0.1:8000/main.js. In this scenario, I assumed that the…
Recommended action: Upgrade to 0.25.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.