Server builder assets can overwrite the generated main.js entry point
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 68/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- angular, typescript
- 領域
- build-system, security
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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?
- 主要言語
- TypeScript
- スター
- 27k
- フォーク
- 11.8k
- 平均マージ
- 21時間 32分
- マージ済み PR（30日）
- 162
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
angular/angular-cli のほかの issue
-
area: @angular/build gemini-triaged
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
angular/angular-cli#33955 ·
メンテナーはふだん 1 日以内に返信
-
area: @angular/cli gemini-triaged
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
angular/angular-cli#33055 · コメント 1 件 · リアクション 3 件 ·
メンテナーはふだん 1 日以内に返信
-
library builder: tslib is not added to the output package.json対応中かも @alan-agius4 が 9 日前に担当しました。 オープンangular/build:library area: @angular/build gemini-triaged
angular/angular-cli#34131 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
library builder: a name re-exported through two "export *" paths is dropped from the bundle対応中かも @alan-agius4 が 9 日前に担当しました。 オープンangular/build:library area: @angular/build gemini-triaged
angular/angular-cli#34130 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
library builder: entry points a/b and a-b are built into the same bundle対応中かも @alan-agius4 が 10 日前に担当しました。 オープンangular/build:library area: @angular/build gemini-triaged
angular/angular-cli#34128 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
angular/angular-cli の issue をすべて見る
似ている issue
-
needs:triage
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
メンテナーはふだん 1 日以内に返信
-
ai-discovered
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
jessepollak/home#1627 ·
メンテナーはふだん 1 日以内に返信
-
agent-canvas bug llm priority:low ready-for-dev
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
OpenHands/OpenHands#17806 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
radius-project/ai-extensions#923 ·
メンテナーはふだん 1 日以内に返信