Webpack in a title is not the webpack-dev-server
Webpack in a title is not the webpack-dev-server
A development server can expose source paths and debugging endpoints that would never be published by a production web server. It can also be difficult to identify from an internet index because the word webpack appears in error pages, documentation, build dashboards, and ordinary application content.
On November 5, 2026 at 02:50 Beijing time, title="webpack" returned 11,080 matches and http.body="webpack-dev-server" returned 3,872. Both queries used page 1, page size 1, and sub_type=all. The title result is broad and noisy. The body expression is narrower but still not proof that a development server is reachable, because it can match logs, documentation, or copied build output.
The Host validation bypass
webpack-dev-server advisory GHSA-wqhc-fvfg-56q6 describes CVE-2026-114348. In versions from 5.1.0 before 5.2.7 and from 6.0.0 before 6.1.0, the /webpack-dev-server/open-editor endpoint was unauthenticated. Its host-validation routine applied a browser-origin regular expression to the Host header, allowing a malformed value such as file:badport to bypass the hostname and allowedHosts checks.
A peer that can reach the server can trigger an exception and receive an HTTP 500 containing a stack trace. That can disclose absolute filesystem paths, module locations, and source line numbers. The advisory does not describe a denial of service. The server continues running.
The risk is greatest when a development server is accidentally reachable outside a trusted development environment. Stack-trace disclosure can help an attacker map the repository and identify other exposed services. The endpoint itself does not provide code execution in the documented issue.
Patch and remove public development surfaces
The fixed versions are 5.2.7 and 6.1.0. Upgrade development dependencies, lockfiles, and container images together. A patched application can still pull an old dev server through a transitive dependency or a shared base image.
Development servers should not be internet-facing. Bind them to localhost or a dedicated development network, enforce the framework's allowed-host policy, and place a proxy in front only when it provides the same validation. Remove the open-editor endpoint when the workflow does not need it.
Search repositories and deployment manifests for webpack-dev-server, --host 0.0.0.0, and development compose files. Verify that production builds do not include the dev server or its HMR websocket. After patching, send a malformed Host value to a staging instance and confirm that the server rejects it without exposing a stack trace.
Turn discovery into ownership
The title count is a prompt to search owned content and expose assets, not a list of vulnerable servers. The body count is more specific but still needs a response-level check. For each owned candidate, confirm the package version, build mode, bind address, network policy, and source directory exposure.
The useful comparison is between 11,080 and 3,872, not a claim that either number is a victim count. The first expression sees a name; the second sees a more distinctive string. A real inventory needs the running version, the endpoint behavior, and the network path. Those facts let a team close a development service that should never have been reachable.
References
- webpack-dev-server advisory GHSA-wqhc-fvfg-56q6
- OpenJS Foundation security advisory index
- ZoomEye: title="webpack"
- ZoomEye: http.body="webpack-dev-server"
Buttons don't work for some users after a deploy
Once a browser has fetched an index.html served without Cache-Control (the header that says how long a response may be cached), it keeps using its own copy without going back to the server. That period is 10% of the time since index.html was last modified.
If you deploy during that period, reopening the site still runs the previous version's page. The files that page loads later are gone from the server, so when a user uses a feature the page hasn't loaded yet, the load fails and clicking the button does nothing. An error tracker (Sentry or similar) shows this line:
TypeError: Failed to fetch dynamically imported module: <chunk URL>
It means a JS file the page tried to load at runtime with import() could not be fetched. A chunk is a separate file the build splits some of the page's features into. It is loaded for the first time when the user clicks a button or similar. The error hits only users who use a feature the previous version hadn't loaded yet. Everyone else keeps running the previous version with no error.
On a site that deploys once a week, the previous version keeps running in users' browsers for up to about 17 hours after the deploy. Browsers that open the site for the first time after the deploy, or that reload, run the new version, so checking internally may not reproduce it. Users running the previous version don't get a fix even after you deploy it.
I reproduced this with a Vite app served by nginx with its default config, and measured how long the previous version runs and what each fix does.
What is happening
For responses without Cache-Control, the HTTP caching spec[^heuristic] lets a cache guess how long it may use its copy without going back to the server, and gives 10% of the time since Last-Modified (when the file was last modified) as a typical value. Chromium uses exactly 10% of the difference between the time the response was sent (Date) and Last-Modified.[^chromium] Below, the difference between Date and Last-Modified at fetch time is called the time since modification.
[^heuristic]: RFC 9111, section 4.2.2.
[^chromium]: The line lifetimes.freshness = (date_value - last_modified_value.value()) / 10; in Chromium 153.0.8010.12's GetFreshnessLifetimes.
Files with a hash (a string the build derives from a file's contents and puts in its name) get a new name whenever their contents change. Which version's files get loaded is decided only by the file names written in index.html, whose own name never changes. Without Cache-Control, the browser decides when to fetch that index.html again.
When build artifacts are baked into an image, Last-Modified is the build time. On a site that deploys once a week, a browser that opened the site just before the next deploy uses its own copy of index.html, without going to the server, for about 17 hours, 10% of 7 days.
1 2 3 4 5
| | | | |
server serves
[=====old=====][============new=============]
browser runs
[===========old===========][=new]
<- 7 days -><------- 16.8 hours ------>
The top row is the version the server serves. The bottom row is the version that runs when the browser that opened the site at 2 reopens it at each point in time. 1 is when the previous version was built (Last-Modified), 2 is when the user opened the site and fetched index.html (Date), 3 is the deploy, 4 is when the user reopened the site, and 5 is when 10% of the span from 1 to 2 has passed since 2. The span from 1 to 2 is compressed in the figure. If a deploy falls between 2 and 5, reopening the site still runs the previous version. After 5, index.html is fetched again and the new version runs.
Verification
I served a Vite app that loads a chunk when a button is clicked, using nginx with its default config. I opened the previous version, closed the browser, deployed by replacing the container, then relaunched the browser and opened the site again.[^env]
| Time since modification | How long the previous version ran |
|:---|:---|
| 10 min | About 1 min |
| 100 min | About 10 min |
| 1000 min | About 100 min |
| 6 days | About 14 h |
Each was about 10% of the time since modification. Reopening the site in a new tab with the browser kept open gave the same result.[^keepopen]
In browsers that hadn't clicked the button on the first open, clicking it while the previous version was running produced the error. In browsers that had clicked it, no error appeared.
Reloading while the previous version was running fetched index.html again and switched to the new version.
[^keepopen]: Compared at a time since modification of 100 minutes, side by side with relaunching the browser, within the same deploy.
[^env]: The browser was Chromium headless shell 153.0.8010.12 (the build without a window) driven by Playwright 1.63.0, with nginx 1.30.5 and Vite 8.3.1. The time since modification was produced by shifting the modification time of the served files into the past when starting the container (nginx returns a file's modification time as Last-Modified). The time until reopening was produced with an Age header that the previous version's server added to index.html. The browser treats the response as already that many seconds old when it receives it (RFC 9111, section 4.2.3). At a time since modification of 10 minutes, the results matched actually waiting. Each condition ran 4 times in CI, for 12 trials per data point. The reproduction setup and scripts are in show-your-work.
Checking your own environment
The response headers on index.html tell you whether browsers keep using their own copy of it. The access log tells you whether any users ran the previous version and hit the error.
Response headers
Check the response headers on index.html with this command. Look at the same headers whether you serve from S3, a CDN, or a hosting service, or render the HTML on the server per request.
curl -sI https://app.example.com/ | grep -iE '^(cache-control|expires|last-modified):'
If the response has Last-Modified but neither Cache-Control nor Expires (the header that sets an expiry time), the previous version keeps running after a deploy for 10% of the time since modification.
Access log
From a browser that ran the previous version and hit the error, the new version's server receives only the following line and returns 404 (the status meaning the file doesn't exist). It is a request for the previous version's chunk, and the same browser sends no request for index.html.
"GET /assets/feature-DHyZGV0s.js HTTP/1.1" 404 153 "http://127.0.0.1:18000/assets/index-DB4b__oJ.js"
From a browser that had clicked the button under the previous version, not a single line arrives.
Fixes
There are three fixes: add no-cache to index.html, add max-age to it, or reload when loading fails.
Add no-cache to index.html
With Cache-Control: no-cache on index.html, the browser asks the server whether index.html has changed every time it opens the page.[^no-cache] If it hasn't, the server returns 304 (the status meaning not modified) and sends no body.
[^no-cache]: RFC 9111, section 5.2.2.4.
In nginx, add this:
location = /index.html {
root /usr/share/nginx/html;
add_header Cache-Control "no-cache";
}
The new version runs every time the site is reopened, and the window where the previous version runs disappears.[^compare]
[^compare]: Using the same setup as with no fix, I opened an index.html with a time since modification of 100 minutes and compared different times until reopening. Each condition ran 4 times in CI, for 12 trials per data point.
The cost is one extra round trip to the server each time the page opens. Reopening when nothing has been deployed still gets a 304 every time.
Add max-age to index.html
With Cache-Control: max-age=<seconds>, the browser uses its own copy of index.html without going to the server for the number of seconds you specify, regardless of time since modification.[^max-age]
[^max-age]: RFC 9111, section 5.2.2.1.
With max-age=300 (5 minutes), the previous version runs for about 5 minutes.
The cost is that the window where the previous version runs doesn't go away. If the seconds you specify are longer than what the browser would have guessed, the window gets longer.
Reload when loading fails
When a chunk fails to load, reload the page. In Vite, a load failure is signaled with the vite:preloadError event.[^preload-error] The code below reloads only once, so that it doesn't keep reloading if the new version also fails.
[^preload-error]: Load error handling in the Vite docs.
window.addEventListener('vite:preloadError', () => {
if (!sessionStorage.getItem('reloaded-once')) {
sessionStorage.setItem('reloaded-once', '1');
window.location.reload();
}
});
The window where the previous version runs doesn't change. When a user clicks the button under the previous version, the page reloads once after the chunk fails to load, and the new version runs.
The cost is that in-progress page state is lost on reload. Only users who hit the error switch to the new version.
Which to pick
Start with no-cache. It is the only one of the three that removes the window where the previous version runs. If you want fewer round trips, use max-age instead to cap the window. Reloading on failure doesn't change the window, so combine it with one of the other two and use it to switch users who hit the error to the new version.
Scope
Everything above assumes that index.html has Last-Modified but no Cache-Control, that the deploy removes the previous version's files, and that the browser is Chromium.
Browsers
Only Chromium was measured. According to their source, Firefox and Safari also use their own copy of index.html without going to the server for 10% of the time since modification, the same as Chromium.[^other-browsers]
[^other-browsers]: Firefox: nsHttpResponseHead.cpp. Safari: WebKit's CacheValidation.cpp.
When the previous version's files stay
In setups where the previous version's files stay on the server after a deploy, the window where the previous version runs doesn't change. Clicking the button during that window returns the previous version's chunk, and no error appears.
With no error, it is harder to notice that the previous version is running. The previous version's page keeps calling the newly deployed server-side code, so that code has to stay compatible with it.
A setup that puts build artifacts in S3 and runs aws s3 sync without --delete (the option that removes files that exist only at the destination) is one of these.
When missing paths don't return 404
With try_files $uri /index.html (an nginx setting that returns index.html for paths that don't exist), the request for the previous version's chunk gets a 200 whose body is index.html. No 404 shows up in the access log.
In the access log, look for lines where a hashed file path returned 200 with the same byte count as index.html (321 in the example below).
"GET /assets/feature-DHyZGV0s.js HTTP/1.1" 200 321 "http://127.0.0.1:18024/assets/index-DB4b__oJ.js"
The message that reaches the error tracker is the same Failed to fetch dynamically imported module as with the 404.
With a Service Worker
If a Service Worker (a script that can intercept the page's requests and answer them from its own cache) serves index.html from its own cache, the same symptom appears. In that case, adding no-cache or max-age to index.html has no effect.
To check whether one is registered, run navigator.serviceWorker.getRegistrations() in the browser console.
Built with webpack
The same failure surfaces as ChunkLoadError. The message starts with Loading chunk <chunkId> failed.[^webpack]
[^webpack]: webpack v5.111.1 source.
4 reactions · 2 comments
Mentions
Webpack in a title is not the webpack-dev-server Webpack in a title is not the webpack-dev-server A development server can expose source paths and debugging endpoints that would never be published by a production web server. It can also be difficult to identify from an internet index because the word webpack appears in error pages, documentation, build dashboards, and ordinary application content. On November 5, 2026 at 02:50 Beijing time, title="webpack" returned 11,080 matches and http.body="webpack-dev-server" returned 3,872. Both queries used page 1, page size 1, and sub_type=all. The title result is broad and noisy. The body expression is narrower but still not proof that a development server is reachable, because it can match logs, documentation, or copied build output. The Host validation bypass webpack-dev-server advisory GHSA-wqhc-fvfg-56q6 describes CVE-2026-114348. In versions from 5.1.0 before 5.2.7 and from 6.0.0 before 6.1.0, the /webpack-dev-server/open-editor endpoint was unauthenticated. Its host-validation routine applied a browser-origin regular expression to the Host header, allowing a malformed value such as file:badport to bypass the hostname and allowedHosts checks. A peer that can reach the server can trigger an exception and receive an HTTP 500 containing a stack trace. That can disclose absolute filesystem paths, module locations, and source line numbers. The advisory does not describe a denial of service. The server continues running. The risk is greatest when a development server is accidentally reachable outside a trusted development environment. Stack-trace disclosure can help an attacker map the repository and identify other exposed services. The endpoint itself does not provide code execution in the documented issue. Patch and remove public development surfaces The fixed versions are 5.2.7 and 6.1.0. Upgrade development dependencies, lockfiles, and container images together. A patched application can still pull an old dev server through a transitive dependency or a shared base image. Development servers should not be internet-facing. Bind them to localhost or a dedicated development network, enforce the framework's allowed-host policy, and place a proxy in front only when it provides the same validation. Remove the open-editor endpoint when the workflow does not need it. Search repositories and deployment manifests for webpack-dev-server, --host 0.0.0.0, and development compose files. Verify that production builds do not include the dev server or its HMR websocket. After patching, send a malformed Host value to a staging instance and confirm that the server rejects it without exposing a stack trace. Turn discovery into ownership The title count is a prompt to search owned content and expose assets, not a list of vulnerable servers. The body count is more specific but still needs a response-level check. For each owned candidate, confirm the package version, build mode, bind address, network policy, and source directory exposure. The useful comparison is between 11,080 and 3,872, not a claim that either number is a victim count. The first expression sees a name; the second sees a more distinctive string. A real inventory needs the running version, the endpoint behavior, and the network path. Those facts let a team close a development service that should never have been reachable. References - webpack-dev-server advisory GHSA-wqhc-fvfg-56q6 - OpenJS Foundation security advisory index - ZoomEye: title="webpack" - ZoomEye: http.body="webpack-dev-server"
🚨 webpack-dev-server shipped a security release fixing 2 CVEs (1 high, 1 medium) in 5.x and 6.x: cross-origin WebSocket access on proxied upgrades, and a Host-validation info leak. Upgrade to 5.2.7 or 6.1.0. github.com/webpack/webpack-dev-server/releases/ta…
🚨 webpack-dev-server shipped a security release fixing 2 CVEs (1 high, 1 medium) in 5.x and 6.x: cross-origin WebSocket access on proxied upgrades, and a Host-validation info leak. Upgrade to 5.2.7 or 6.1.0. github.com/webpack/webpack-dev-server/releases/ta…
Buttons don't work for some users after a deploy Once a browser has fetched an index.html served without Cache-Control (the header that says how long a response may be cached), it keeps using its own copy without going back to the server. That period is 10% of the time since index.html was last modified. If you deploy during that period, reopening the site still runs the previous version's page. The files that page loads later are gone from the server, so when a user uses a feature the page hasn't loaded yet, the load fails and clicking the button does nothing. An error tracker (Sentry or similar) shows this line: TypeError: Failed to fetch dynamically imported module: <chunk URL> It means a JS file the page tried to load at runtime with import() could not be fetched. A chunk is a separate file the build splits some of the page's features into. It is loaded for the first time when the user clicks a button or similar. The error hits only users who use a feature the previous version hadn't loaded yet. Everyone else keeps running the previous version with no error. On a site that deploys once a week, the previous version keeps running in users' browsers for up to about 17 hours after the deploy. Browsers that open the site for the first time after the deploy, or that reload, run the new version, so checking internally may not reproduce it. Users running the previous version don't get a fix even after you deploy it. I reproduced this with a Vite app served by nginx with its default config, and measured how long the previous version runs and what each fix does. What is happening For responses without Cache-Control, the HTTP caching spec[^heuristic] lets a cache guess how long it may use its copy without going back to the server, and gives 10% of the time since Last-Modified (when the file was last modified) as a typical value. Chromium uses exactly 10% of the difference between the time the response was sent (Date) and Last-Modified.[^chromium] Below, the difference between Date and Last-Modified at fetch time is called the time since modification. [^heuristic]: RFC 9111, section 4.2.2. [^chromium]: The line lifetimes.freshness = (date_value - last_modified_value.value()) / 10; in Chromium 153.0.8010.12's GetFreshnessLifetimes. Files with a hash (a string the build derives from a file's contents and puts in its name) get a new name whenever their contents change. Which version's files get loaded is decided only by the file names written in index.html, whose own name never changes. Without Cache-Control, the browser decides when to fetch that index.html again. When build artifacts are baked into an image, Last-Modified is the build time. On a site that deploys once a week, a browser that opened the site just before the next deploy uses its own copy of index.html, without going to the server, for about 17 hours, 10% of 7 days. 1 2 3 4 5 | | | | | server serves [=====old=====][============new=============] browser runs [===========old===========][=new] <- 7 days -><------- 16.8 hours ------> The top row is the version the server serves. The bottom row is the version that runs when the browser that opened the site at 2 reopens it at each point in time. 1 is when the previous version was built (Last-Modified), 2 is when the user opened the site and fetched index.html (Date), 3 is the deploy, 4 is when the user reopened the site, and 5 is when 10% of the span from 1 to 2 has passed since 2. The span from 1 to 2 is compressed in the figure. If a deploy falls between 2 and 5, reopening the site still runs the previous version. After 5, index.html is fetched again and the new version runs. Verification I served a Vite app that loads a chunk when a button is clicked, using nginx with its default config. I opened the previous version, closed the browser, deployed by replacing the container, then relaunched the browser and opened the site again.[^env] | Time since modification | How long the previous version ran | |:---|:---| | 10 min | About 1 min | | 100 min | About 10 min | | 1000 min | About 100 min | | 6 days | About 14 h | Each was about 10% of the time since modification. Reopening the site in a new tab with the browser kept open gave the same result.[^keepopen] In browsers that hadn't clicked the button on the first open, clicking it while the previous version was running produced the error. In browsers that had clicked it, no error appeared. Reloading while the previous version was running fetched index.html again and switched to the new version. [^keepopen]: Compared at a time since modification of 100 minutes, side by side with relaunching the browser, within the same deploy. [^env]: The browser was Chromium headless shell 153.0.8010.12 (the build without a window) driven by Playwright 1.63.0, with nginx 1.30.5 and Vite 8.3.1. The time since modification was produced by shifting the modification time of the served files into the past when starting the container (nginx returns a file's modification time as Last-Modified). The time until reopening was produced with an Age header that the previous version's server added to index.html. The browser treats the response as already that many seconds old when it receives it (RFC 9111, section 4.2.3). At a time since modification of 10 minutes, the results matched actually waiting. Each condition ran 4 times in CI, for 12 trials per data point. The reproduction setup and scripts are in show-your-work. Checking your own environment The response headers on index.html tell you whether browsers keep using their own copy of it. The access log tells you whether any users ran the previous version and hit the error. Response headers Check the response headers on index.html with this command. Look at the same headers whether you serve from S3, a CDN, or a hosting service, or render the HTML on the server per request. curl -sI https://app.example.com/ | grep -iE '^(cache-control|expires|last-modified):' If the response has Last-Modified but neither Cache-Control nor Expires (the header that sets an expiry time), the previous version keeps running after a deploy for 10% of the time since modification. Access log From a browser that ran the previous version and hit the error, the new version's server receives only the following line and returns 404 (the status meaning the file doesn't exist). It is a request for the previous version's chunk, and the same browser sends no request for index.html. "GET /assets/feature-DHyZGV0s.js HTTP/1.1" 404 153 "http://127.0.0.1:18000/assets/index-DB4b__oJ.js" From a browser that had clicked the button under the previous version, not a single line arrives. Fixes There are three fixes: add no-cache to index.html, add max-age to it, or reload when loading fails. Add no-cache to index.html With Cache-Control: no-cache on index.html, the browser asks the server whether index.html has changed every time it opens the page.[^no-cache] If it hasn't, the server returns 304 (the status meaning not modified) and sends no body. [^no-cache]: RFC 9111, section 5.2.2.4. In nginx, add this: location = /index.html { root /usr/share/nginx/html; add_header Cache-Control "no-cache"; } The new version runs every time the site is reopened, and the window where the previous version runs disappears.[^compare] [^compare]: Using the same setup as with no fix, I opened an index.html with a time since modification of 100 minutes and compared different times until reopening. Each condition ran 4 times in CI, for 12 trials per data point. The cost is one extra round trip to the server each time the page opens. Reopening when nothing has been deployed still gets a 304 every time. Add max-age to index.html With Cache-Control: max-age=<seconds>, the browser uses its own copy of index.html without going to the server for the number of seconds you specify, regardless of time since modification.[^max-age] [^max-age]: RFC 9111, section 5.2.2.1. With max-age=300 (5 minutes), the previous version runs for about 5 minutes. The cost is that the window where the previous version runs doesn't go away. If the seconds you specify are longer than what the browser would have guessed, the window gets longer. Reload when loading fails When a chunk fails to load, reload the page. In Vite, a load failure is signaled with the vite:preloadError event.[^preload-error] The code below reloads only once, so that it doesn't keep reloading if the new version also fails. [^preload-error]: Load error handling in the Vite docs. window.addEventListener('vite:preloadError', () => { if (!sessionStorage.getItem('reloaded-once')) { sessionStorage.setItem('reloaded-once', '1'); window.location.reload(); } }); The window where the previous version runs doesn't change. When a user clicks the button under the previous version, the page reloads once after the chunk fails to load, and the new version runs. The cost is that in-progress page state is lost on reload. Only users who hit the error switch to the new version. Which to pick Start with no-cache. It is the only one of the three that removes the window where the previous version runs. If you want fewer round trips, use max-age instead to cap the window. Reloading on failure doesn't change the window, so combine it with one of the other two and use it to switch users who hit the error to the new version. Scope Everything above assumes that index.html has Last-Modified but no Cache-Control, that the deploy removes the previous version's files, and that the browser is Chromium. Browsers Only Chromium was measured. According to their source, Firefox and Safari also use their own copy of index.html without going to the server for 10% of the time since modification, the same as Chromium.[^other-browsers] [^other-browsers]: Firefox: nsHttpResponseHead.cpp. Safari: WebKit's CacheValidation.cpp. When the previous version's files stay In setups where the previous version's files stay on the server after a deploy, the window where the previous version runs doesn't change. Clicking the button during that window returns the previous version's chunk, and no error appears. With no error, it is harder to notice that the previous version is running. The previous version's page keeps calling the newly deployed server-side code, so that code has to stay compatible with it. A setup that puts build artifacts in S3 and runs aws s3 sync without --delete (the option that removes files that exist only at the destination) is one of these. When missing paths don't return 404 With try_files $uri /index.html (an nginx setting that returns index.html for paths that don't exist), the request for the previous version's chunk gets a 200 whose body is index.html. No 404 shows up in the access log. In the access log, look for lines where a hashed file path returned 200 with the same byte count as index.html (321 in the example below). "GET /assets/feature-DHyZGV0s.js HTTP/1.1" 200 321 "http://127.0.0.1:18024/assets/index-DB4b__oJ.js" The message that reaches the error tracker is the same Failed to fetch dynamically imported module as with the 404. With a Service Worker If a Service Worker (a script that can intercept the page's requests and answer them from its own cache) serves index.html from its own cache, the same symptom appears. In that case, adding no-cache or max-age to index.html has no effect. To check whether one is registered, run navigator.serviceWorker.getRegistrations() in the browser console. Built with webpack The same failure surfaces as ChunkLoadError. The message starts with Loading chunk <chunkId> failed.[^webpack] [^webpack]: webpack v5.111.1 source.