Server builder assets can overwrite the generated main.js entry point
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 68/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- angular, typescript
- Ambito
- build-system, security
Direzione di ricerca
Start with packages/angular_devkit/build_angular/src/builders/server/index.ts, especially the call to copyAssets(), then read packages/angular_devkit/build_angular/src/utils/copy-assets.ts to trace destination writes. Run scripts/validate.sh in the linked reproduction to confirm the collision. Done means the server builder no longer allows an asset to replace generated main.js and the clean and attack scenarios behave as intended.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Command
build, run
Is this a regression?
No. The server builder has copied configured assets after Webpack output since the assets option was released in 15.1.0.
The previous version in which this bug was not present was
No response.
Description
@angular-devkit/build-angular:server copies configured assets after Webpack emits the server program, without checking whether an asset destination is already a generated file.
With a recursive asset tree copied to output ., an asset named main.js silently replaces the generated server entry point. The build reports success, and normal node dist/server/main.js startup executes the asset instead of the generated application bundle.
I reproduced this with an asset-only dependency update. Version 1.0.0 contains only assets/data.json; version 1.0.1 adds only assets/main.js. Neither version declares scripts, main, exports, imports, or bin, installation uses --ignore-scripts, and the application never imports the package.
Expected: the build should reject an asset/generated-output collision, or keep generated output authoritative.
Actual: the build succeeds and the final dist/server/main.js is byte-for-byte identical to the dependency asset. Starting it executes dependency-controlled code as the deployed server process.
Minimal Reproduction
Repository: https://github.com/BlueIridium-Security/angular-server-asset-entry-collision-repro
git clone https://github.com/BlueIridium-Security/angular-server-asset-entry-collision-repro.git
cd angular-server-asset-entry-collision-repro
./scripts/validate.sh
The validator runs clean → attack → restored-clean → restored-attack. Across two fresh-container runs, clean 1.0.0 always emitted and started the same genuine 782,472-byte bundle with no marker; attack 1.0.1 always emitted the exact 192-byte package asset and executed its marker. Runtime networking is disabled, and the script fails on any control mismatch.
Exception or Error
No exception is reported. The builder reports successful bundle generation and asset copying.
Your Environment
Angular CLI: 22.2.0
@angular-devkit/build-angular: 22.2.0
Angular: 22.2.0
Node: 24.21.0
npm: 11.19.0
OS: Linux arm64 container (node:24.21.0-bookworm-slim)
Anything else relevant?
The builder is deprecated but remains shipped. The default server assets list is empty, and exploitation requires an opt-in recursive root-output rule plus an accepted package update, build, deployment, and startup. I therefore assess this as High rather than Critical.
Current source shows the server builder calling copyAssets() after successful Webpack output, while copyAssets() writes each destination without checking generated outputs.
This is distinct from #19157 and #16670, which discuss precedence between two configured asset inputs rather than a post-Webpack asset replacing the executable generated entry point.
Should the server builder reject configured asset destinations that collide with generated output files?
- Lingua principale
- TypeScript
- Stelle
- 27k
- Fork
- 11.8k
- Merge medio
- 22h 50m
- PR unite (30g)
- 168
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di angular/angular-cli
-
area: @angular/build gemini-triaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
angular/angular-cli#33955 ·
I maintainer di solito rispondono entro 1 giorno
-
area: @angular/cli gemini-triaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
angular/angular-cli#33055 · 1 commento · 3 reazioni ·
I maintainer di solito rispondono entro 1 giorno
-
area: @angular/cli gemini-triaged
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
angular/angular-cli#34215 ·
I maintainer di solito rispondono entro 1 giorno
-
stats.json is non-deterministic when two component stylesheets produce the same output fileForse già presa @sdjayna l’ha presa oggi. Apertaarea: @angular/build gemini-triaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 35/100
angular/angular-cli#34209 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
angular/angular-cli#34207 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di angular/angular-cli
Issue simili
-
area/frontend good first issue kind/cooldown
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
voidzero-dev/oxc-angular-compiler#511 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
langchain-ai/deepagentsjs#898 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
anomalyco/models.dev#8509 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
bug documentation P2 UI/UX
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno