Esno version 0.17.0 brings notable updates and improvements for developers using this Node.js runtime, leveraging esbuild for efficient TypeScript and ESM module loading. A key change from version 0.16.3 is the updated dependency on tsx, moving from version 3.2.1 to ^3.12.7. This upgrade likely incorporates bug fixes, performance enhancements, and potentially new features offered by the newer tsx release, ultimately improving Esno's capabilities in handling TypeScript execution.
Furthermore, the development dependencies see significant shifts. zx, a tool for writing shell scripts in Node.js, jumps from version 4.3.0 to ^7.2.3, suggesting substantial updates or feature additions in the development workflow. fsxx, likely a utility library for file system operations, moves from 0.0.5 to ^0.1.0, indicating some enhancements or API changes. The TypeScript version also sees a major upgrade from 4.5.5 to ^5.1.6, enabling developers to leverage the latest TypeScript features and improvements within Esno. A new dev dependency, bumpp, appears in version 0.17.0 for version bumping, streamlining the release process.
The repository URL has also been updated to https://github.com/esbuild-kit/esno.git, while it was https://github.com/antfu/esno.git in version 0.16.3, reflecting a potential change in project ownership or organization. The unpackedSize has also increased from 2534 to 2663, which shows some code and feature enhancements have been added in the newer version. Developers upgrading to 0.17.0 should be aware of these dependency updates and potential breaking changes introduced by the newer versions of tsx, zx, and TypeScript. Finally, the newer version was released after about 1 year and 2 months after the older version.
All the vulnerabilities related to the version 0.17.0 of the package
esbuild enables any website to send any requests to the development server and read the response
esbuild allows any websites to send any request to the development server and read the response due to default CORS settings.
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/serve_other.go#L121 https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serve_other.go#L363
Attack scenario:
http://malicious.example.com).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.http://127.0.0.1:8000/main.js.In this scenario, I assumed that the attacker knows the URL of the bundle output file name. But the attacker can also get that information by
/index.html: normally you have a script tag here/assets: it's common to have a assets directory when you have JS files and CSS files in a different directory and the directory listing feature tells the attacker the list of files/esbuild SSE endpoint: the SSE endpoint sends the URL path of the changed files when the file is changed (new EventSource('/esbuild').addEventListener('change', e => console.log(e.type, e.data)))The scenario above fetches the compiled content, but if the victim has the source map option enabled, the attacker can also get the non-compiled content by fetching the source map file.
npm inpm run watchfetch('http://127.0.0.1:8000/app.js').then(r => r.text()).then(content => console.log(content)) in a different website's dev tools.Users using the serve feature may get the source code stolen by malicious websites.