CVE-2015-8857

What it actually does

The vulnerable uglify-js versions before 2.4.24 can incorrectly optimize or rewrite JavaScript boolean expressions when operands are not strictly boolean values. If application logic relies on JavaScript truthy/falsy behavior for authorization, feature gating, input validation, policy checks, or other security-sensitive decisions, minification can change runtime behavior from what developers intended. The result may be authorization bypass, disabled checks, or other integrity and confidentiality impacts in applications built with the affected minifier output.

Why it matters to the business

Applications or bundled assets built with the vulnerable minifier may contain altered security logic, meaning users could gain access to actions or data they should not be allowed to reach. Because this is a build-time supply-chain issue, the risk may persist in already-built JavaScript artifacts even after the dependency is upgraded unless affected assets are rebuilt and redeployed. The issue is old and not listed in CISA KEV, but public exploit knowledge exists and the CVSS rating is critical, so exposed products that still embed affected output should be treated as high priority.

How an attack unfolds

An attacker does not typically attack uglify-js directly at runtime. Instead, they target an application whose JavaScript was previously minified with a vulnerable uglify-js version. The attacker studies client-side or server-side JavaScript behavior, identifies a security-sensitive boolean expression that was incorrectly transformed, and crafts requests, inputs, or browser-side state that trigger the unintended logic path. If the flawed expression controls authorization, validation, or access decisions, the attacker may bypass restrictions, invoke privileged functionality, or access protected data. In supply-chain scenarios, the attacker may also seek to influence a build pipeline or package selection so vulnerable minification is used, causing defective JavaScript artifacts to be produced.

How to fix it

Upgrade uglify-js to version 2.4.24 or later wherever it is used directly or transitively in build pipelines. For the listed affected packages, use versions marked fixed: nri-discovery-kubernetes for Chainguard fixed in 0, nri-discovery-kubernetes for Wolfi fixed in 0, nri-discovery-kubernetes-compat for Chainguard fixed in 0, and nri-discovery-kubernetes-compat for Wolfi fixed in 0. After upgrading, perform a clean rebuild of all JavaScript assets, containers, and packages that may have been produced with the vulnerable minifier, then redeploy the rebuilt artifacts. If immediate upgrade is not possible, avoid minifying security-sensitive code with affected uglify-js versions, disable unsafe boolean/comparison optimizations where feasible, and move critical authorization decisions to trusted server-side enforcement rather than relying on client-side JavaScript.

How to confirm the fix worked

Confirm dependency manifests, lockfiles, SBOMs, and container/package metadata no longer contain uglify-js versions before 2.4.24. Verify the build pipeline is using the updated dependency by performing a clean install and rebuild rather than relying on cached artifacts. Compare regenerated JavaScript bundles against prior bundles for security-sensitive boolean rewrites, and run regression tests that exercise authorization, validation, and access-control branches with non-boolean truthy/falsy values. For containerized affected products, rescan images with an SCA or container scanner and confirm the fixed package versions are reported.

Typical attack path

1. Identify an application or package built with uglify-js before version 2.4.24 or containing minified JavaScript generated by that version.
2. Review bundled JavaScript for optimized boolean expressions that differ from source-level intended logic, especially around authorization, validation, or security gates.
3. Craft inputs, parameters, object properties, or runtime values that exploit JavaScript truthy/falsy behavior after the incorrect rewrite.
4. Submit requests or interact with the application to reach logic paths that should have been blocked.
5. Use the bypass to access restricted functionality, view protected data, alter application state, or chain with other weaknesses.

How to detect it

To determine whether this was already exploited, focus on applications whose deployed JavaScript was built with uglify-js before 2.4.24 and inspect access-control behavior rather than looking for attacks against the library itself. Review web access logs, API gateway logs, application authorization logs, audit trails, and WAF logs for users successfully invoking restricted endpoints, changing privileged settings, or retrieving protected resources without the expected role, entitlement, session state, or workflow. Compare suspicious requests against authorization-denied events before and after deployment of minified assets. In source and artifact repositories, identify bundles generated by vulnerable builds and review diffs around boolean expressions, ternaries, logical operators, and conditionals used in security checks. Build logs, npm/yarn lockfiles, package metadata, and SBOM records showing uglify-js before 2.4.24 indicate exposure but are not proof of exploitation. There are no universal network indicators because exploitation depends on application-specific logic and inputs.

• uglify-js@2.4.23
• uglify-js@2.4.22
• uglify-js@2.4.21
• uglify-js@2.4.20
• uglify-js@2.4.19
• uglify-js@2.4.18
• uglify-js@2.4.17
• uglify-js@2.4.16
• uglify-js@2.4.15
• uglify-js@2.4.14
• uglify-js@2.4.13
• uglify-js@2.4.12
• uglify-js@2.4.11
• uglify-js@2.4.10
• "uglify-js": "2.4.
• "uglify-js":"2.4.
• node_modules/uglify-js/package.json
• node_modules/.bin/uglifyjs
• uglifyjs --compress
• uglifyjs --mangle

What your security team should do

• Inventory repositories, build images, package lockfiles, SBOMs, and deployed artifacts for uglify-js versions before 2.4.24.
• Prioritize remediation for internet-facing applications, administrative interfaces, and products where bundled JavaScript participates in authentication, authorization, or request validation.
• Upgrade the dependency, perform clean rebuilds, and redeploy artifacts rather than only changing manifest files.
• Add tests for security-sensitive boolean logic using non-boolean values such as empty strings, non-empty strings, 0, 1, null, undefined, arrays, and objects.
• Ensure authorization and access-control decisions are enforced server-side and are not dependent on client-side minified JavaScript.
• Search historical build logs and artifact repositories to identify JavaScript bundles generated while the vulnerable version was in use.
• Add SCA/SBOM policy gates to block uglify-js versions before 2.4.24 in future builds.