Repository navigation
Add QR auth module XUI template - #370
Merged
Merged
Conversation
vharseko
pushed a commit
that referenced
this pull request
Oct 21, 2026
…026-112946 vite: Dev-server command injection via bundled launch-editor and server.fs bypass (8.0.16 -> 8.3.5) (#1190) Bumps `vite` in `openam-ui/openam-ui-js-sdk` from 8.0.16 to 8.3.5, clearing Dependabot alerts #369, #370 and #371. All three are advisories against `launch-editor`, which Vite bundles into its own `dist` (8.0.16 carries `launch-editor` / `launch-editor-middleware` 2.14.1, 8.3.5 carries 2.14.2), so the lock file has no `launch-editor` entry and only a Vite release can fix it. The same bump fixes two more Vite advisories that are published in the vitejs/vite repository but have not reached the GitHub Advisory Database yet, hence no Dependabot alert. `openam-ui-js-sdk` is the only lock file in the repository that resolves `vite`. ## Advisories Vite's dev server mounts `launch-editor-middleware` at `/__open-in-editor`: a request to `/__open-in-editor?file=<path>` resolves `<path>` against the project root and has `launch-editor` open it in the developer's editor (the error overlay's "click to open" uses it). The three `launch-editor` advisories are about what that `file` argument can make the editor's command line do. **CVE-2026-112942 / GHSA-587h-7wmj-h5pm** (Windows only) — Command injection (CWE-77). `launch-editor` only starts the editor for a path that `fs.existsSync()` accepts, which was meant to require the attacker to plant a file with a malicious name. A value ending in `\..:1:1` gets past that: the middleware's `path.resolve()` keeps `..:1:1` as an ordinary name, `launch-editor` strips `:1:1` as line and column, and Windows then accepts the trailing `\..` as the existing parent directory, so an arbitrary, non-existent preceding component reaches the shell command. Combined with GHSA-698v-4r3x-3vcv this gives OS command injection to whoever controls the `file` argument. launch-editor 2.14.2 resolves the path after stripping the position, so the existence check sees the real target (vitejs/launch-editor@f13cd83). **CVE-2026-112943 / GHSA-698v-4r3x-3vcv** (Windows only) — OS command injection (CWE-78). On Windows `launch-editor` starts the editor through `cmd.exe` (`child_process.exec(…, { shell: true })`), and `escapeCmdArgs()` did not escape `%`, so environment-variable expansion (`%VAR%`, `%CD%`, `%CMDCMDLINE:~-38%`) can splice a subcommand into the command line. On its own it needs a planted file plus an injected environment variable or an NTFS alternate data stream; GHSA-587h removes the planted-file requirement. 2.14.2 rejects any argument containing `%` or a line break on Windows instead of trying to escape it (vitejs/launch-editor@3c2f9bf). **CVE-2026-112944 / GHSA-r825-w8mm-5pxw** — Argument injection (CWE-88). A file name that starts with `+` or `-` reaches the editor as an option; Vim runs `+<cmd>` as an Ex command, and Emacs and some Notepad++ plugins expose similar switches. For Vite it is limited to WSL, where `launch-editor` turns the absolute path back into a relative one, with Vim / MacVim / Emacs / Notepad++ as the editor and an attacker who can create a `+…` or `-…` entry in the working directory. 2.14.2 resolves the name to an absolute path and prefixes the WSL relative form with `./` (vitejs/launch-editor@f6e6701). Not in the Advisory Database yet: **CVE-2026-112946 / GHSA-rq7h-c2jc-7f22** (not on Windows) — Path traversal and improper access control (CWE-22, CWE-284) that bypasses `server.fs.allow`. When Vite rewrote an in-root import to a browser URL such as `/etc/hostname`, it recorded that URL in `safeModulePaths` as if it were an absolute filesystem path, so a later `/@fs/etc/hostname` request returned the host's `/etc/hostname` instead of the project file. It needs the dev server exposed to the network (`--host` / `server.host`), a project import whose root-relative URL is also the absolute path of a readable host file, and that file not matched by `server.fs.deny`. The fix stores module IDs rather than URLs in `safeModulePaths` (vitejs/vite#23656, in 8.3.3). **CVE-2026-112945 / GHSA-9jrq-w75r-8gcw** — Cross-origin script execution (CWE-80). A server that hands the unchanged browser request URL to `server.transformIndexHtml` — the middleware-mode / `appType: 'custom'` SSR pattern from Vite's guide — could be made to emit `<script type="module" src="//evil.example/…">` for an inline module script and so load an attacker's script into the dev-server origin. Vite's own `spa` / `mpa` HTML handling is not affected. The fix strips the query before deriving the HTML file name (vitejs/vite#23653, in 8.3.3). | | Severity | Affected (8.x line) | Fixed in | |---|---|---|---| | GHSA-587h-7wmj-h5pm | High — CVSS 4.0 7.5 (`AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N`) | 8.0.0–8.1.5, 8.2.0–8.2.3, 8.3.0–8.3.2 | 8.1.6, 8.2.4, 8.3.3 | | GHSA-698v-4r3x-3vcv | Medium — CVSS 4.0 6.3 (`AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N`) | same | same | | GHSA-r825-w8mm-5pxw | Medium — CVSS 4.0 6.3 (`AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N`) | same | same | | GHSA-rq7h-c2jc-7f22 | Medium — CVSS 4.0 6.3 (`AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N`) | same | same | | GHSA-9jrq-w75r-8gcw | Low — CVSS 4.0 2.1 (`AV:N/AC:L/AT:P/PR:N/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N`) | same | same | 8.0.16 was never affected by GHSA-vfpm-58rq-9qcg / CVE-2026-112947 (`?vite-wasm-instance` exposes the first 4 bytes of files outside `server.fs`), which covers only 8.2.0–8.3.2; 8.3.5 is past it, whereas a bump that stopped in that window would have introduced it. ## Impact on OpenAM Nothing at runtime and nothing in the build; the exposure is `npm run dev` on a developer machine. `vite` is a direct development dependency of `openam-ui-js-sdk` (`devDependencies`, `dev: true`), and every advisory above sits in the dev server — `/__open-in-editor`, the `/@fs/` handler, `transformIndexHtml` — none of which ends up in what `vite build` writes. - The Maven build runs `npm run build` (`tsc -b && vite build` with `vite.config.ts` and with `vite.lib.config.ts`) and `npm run test:run` (`vitest run`). `vite build` starts no server. `vitest run` creates a Vite server in-process but calls `listen()` only when `api.port` is set (`createVitest`: `if (ctx.config.api?.port) await server.listen()`), and `vitest.config.js` sets no `api`, so no port is opened and `/__open-in-editor` is unreachable, the `windows-latest` CI runners included. - What ships is the `vite build` output: `openam-server-only` unpacks the `app` zip (`target/app`) into the WAR as `extui/`, and the `lib` zip carries `target/lib`. Neither contains the dev server, the Vite client or `launch-editor`. - `npm run dev` runs `vite --host 0.0.0.0`, which binds the dev server to every interface, so `/__open-in-editor` and `/@fs/` answer anyone on the network. `server.allowedHosts` (`localhost`, `openam.example.org`) checks only the `Host` header, which a client other than a browser sets at will; it stops DNS rebinding, not direct requests. A developer running `npm run dev` on Windows with an editor that launch-editor detects was therefore open to command injection over the network through GHSA-587h + GHSA-698v. GHSA-r825 additionally needs WSL, a Vim- or Emacs-type editor and a planted `+…` / `-…` entry in the working directory. GHSA-rq7h needs an import whose root-relative URL is also a readable host path; this module's imports resolve to `/src/…` and `/node_modules/…`, which a standard Linux or macOS host does not have. GHSA-9jrq does not apply: the module uses Vite's default `spa` app type and never calls `transformIndexHtml` itself. ## Change `vite` 8.0.16 → 8.3.5 in `openam-ui/openam-ui-js-sdk`. The `devDependencies` floor in `package.json` moves `^8.0.16` → `^8.3.5`, so a fresh `npm install` cannot resolve back into an affected version, and `package-lock.json` follows Vite's own dependency floors: - `rolldown` 1.0.3 → 1.2.14 (Vite 8.3.5 pins `~1.2.14`), with `@oxc-project/types` 0.133.0 → 0.154.0 and the `@rolldown/binding-*` platform packages 1.0.3 → 1.2.14. Rolldown 1.2.14 adds `@rolldown/binding-android-arm-eabi` and no longer lists the WebAssembly fallback `@rolldown/binding-wasm32-wasi`, so that binding and its helpers (`@napi-rs/wasm-runtime`, `@emnapi/core`, `@emnapi/runtime`, `@emnapi/wasi-threads`, `@tybys/wasm-util`, `tslib`) leave the lock file; the CI runners (Linux x64, macOS arm64, Windows x64) all have native bindings. - `lightningcss` and its platform packages 1.32.0 → 1.33.0, `postcss` 8.5.23 → 8.5.31, `nanoid` 3.3.16 → 3.3.20 (from `postcss`'s new `^3.3.20` floor), and Vite's nested `picomatch` 4.0.4 → 4.0.7. This is a minor-version step for the toolchain that produces the shipped `extui/` and `lib` bundles — Rolldown is Vite 8's production bundler — so the generated JavaScript can differ in chunking and output details although no source or configuration changes. The smallest fixed 8.x release is 8.1.6; Dependabot took the latest, 8.3.5, which is also clear of GHSA-vfpm-58rq-9qcg. The `nanoid` move also takes this lock file out of GHSA-2v37-7h3g-55p8 / CVE-2026-67213 (infinite loop in `customAlphabet` / `customRandom` with `size` 0, fixed in 3.3.18). Its alert #303 had been auto-dismissed, and it was never reachable: `postcss` only calls `nanoid(6)` from `nanoid/non-secure`. Verified: - all 33 changed `integrity` hashes match the npm registry: `vite@8.3.5`, `rolldown@1.2.14`, the 15 `@rolldown/binding-*@1.2.14`, `@oxc-project/types@0.154.0`, `lightningcss@1.33.0` and its 11 platform packages, `postcss@8.5.31`, `nanoid@3.3.20`, `picomatch@4.0.7` - Vite 8.3.5's `dist` bundles `launch-editor` and `launch-editor-middleware` 2.14.2 (8.0.16: 2.14.1), and `/__open-in-editor` is mounted only in the dev server - the GitHub Advisory Database lists no advisory affecting `vite@8.3.5` - the packages that constrain `vite` accept 8.3.5: `@vitejs/plugin-react` 5.2.0 (`… || ^8.0.0`), `vitest` and `@vitest/mocker` 4.1.11 (`^6.0.0 || ^7.0.0 || ^8.0.0`), `vite-plugin-dts` 5.0.3 (`>=3`) - `engines.node` of `vite` and `rolldown` is unchanged (`^20.19.0 || >=22.12.0`); the build's Node v22.21.1 satisfies it ## References - GHSA-587h-7wmj-h5pm - GHSA-698v-4r3x-3vcv - GHSA-r825-w8mm-5pxw - GHSA-rq7h-c2jc-7f22 - GHSA-9jrq-w75r-8gcw - https://nvd.nist.gov/vuln/detail/CVE-2026-112942 - https://nvd.nist.gov/vuln/detail/CVE-2026-112943 - https://nvd.nist.gov/vuln/detail/CVE-2026-112944 - vitejs/launch-editor@f13cd83 - vitejs/launch-editor@3c2f9bf - vitejs/launch-editor@f6e6701 - https://github.com/vitejs/launch-editor/releases/tag/v2.14.2 - vitejs/vite#23654 - vitejs/vite#23656 - vitejs/vite#23653 - https://github.com/vitejs/vite/releases/tag/v8.3.3 Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.