CVE-2015-8858

What it actually does

The vulnerable uglify-js parser can enter catastrophic backtracking or otherwise excessive CPU consumption when processing specially crafted JavaScript input. If an exposed application, build service, CMS plugin workflow, or server-side feature passes attacker-controlled content into uglify-js parse/minification routines, a single request or small number of requests can monopolize the Node.js event loop or worker CPU, causing denial of service. The flaw affects uglify-js versions before 2.6.0; the provided affected product context indicates Bitnami WordPress is fixed in version 3.7.40.

Why it matters to the business

Successful exploitation can make web publishing, asset processing, or application services slow or unavailable, potentially causing site outages, failed deployments, degraded customer experience, and increased operational load. This issue is old and not listed in CISA KEV, and the current EPSS score is relatively low, but public exploit knowledge exists, so internet-exposed paths that process user-supplied JavaScript should still be remediated. Organizations using packaged Bitnami WordPress images should verify they are on a fixed release because vulnerable bundled dependencies may persist even when the application itself appears current.

How an attack unfolds

An attacker first identifies an application path that invokes uglify-js on untrusted or semi-trusted input, such as JavaScript minification, theme or plugin asset processing, upload handling, preview generation, or build automation exposed through a web interface or API. The attacker submits a crafted JavaScript payload designed to trigger inefficient parser behavior. When the application calls uglify-js parse on that payload, the Node.js process consumes excessive CPU and may stop servicing other requests. Repeating the request, or targeting multiple workers, can sustain an outage until the process is restarted, input is blocked, rate limits are applied, or the vulnerable dependency is upgraded.

How to fix it

Upgrade uglify-js to version 2.6.0 or later wherever it is present, including transitive dependencies bundled in application images, CMS packages, plugins, themes, and build pipelines. For the provided Bitnami WordPress context, upgrade to Bitnami WordPress 3.7.40 or later. Rebuild containers and redeploy application images after updating dependencies so old node_modules trees are not retained. If immediate upgrade is not possible, prevent untrusted users from reaching code paths that invoke uglify-js, enforce strict input size and content validation before parsing, apply request rate limiting, place parsing/minification jobs behind authenticated queues, and run parsing workloads with CPU timeouts or worker isolation so one request cannot block the main service.

How to confirm the fix worked

Confirm fixed status by inspecting dependency manifests and installed packages for uglify-js versions older than 2.6.0, including nested node_modules directories and packaged application images. For Bitnami WordPress, verify the deployed package or image version is 3.7.40 or later. Run software composition analysis against source repositories, container images, and build artifacts to ensure no vulnerable uglify-js copy remains. Where safe and authorized, perform a controlled regression test using representative malformed JavaScript input and confirm the parsing/minification endpoint returns quickly, enforces limits, or rejects the input rather than consuming sustained CPU. Monitor the service after remediation to verify CPU spikes and request latency associated with parsing endpoints do not recur.

Typical attack path

1. Identify an internet-accessible application or workflow that performs server-side JavaScript parsing or minification.
2. Confirm or infer use of a vulnerable uglify-js version, often through dependency manifests, exposed build artifacts, stack traces, or packaged application versions.
3. Submit a crafted JavaScript input to the feature that calls uglify-js parse.
4. Cause the Node.js process or worker to consume excessive CPU and block normal request handling.
5. Repeat requests or parallelize submissions to maintain denial of service across available workers.
6. Stop when availability impact is achieved or continue until rate limiting, process isolation, or dependency remediation is applied.

How to detect it

To assess prior exploitation, correlate web access logs, application logs, process telemetry, and infrastructure metrics for periods of sustained high CPU on Node.js or asset-processing workers. Look for repeated requests to endpoints that handle JavaScript uploads, minification, theme/plugin editing, preview generation, static asset building, or CMS administrative asset workflows immediately before CPU saturation, timeouts, 502/503/504 responses, process restarts, or container health-check failures. Application logs may show uglify-js parser errors, JavaScript parse exceptions, request timeouts, or worker termination events. Dependency exposure can be checked by searching source repositories, deployed filesystems, and container layers for installed uglify-js versions below 2.6.0. There are no universal network indicators because the malicious payload is application-specific, but clusters of large or unusual JavaScript submissions followed by CPU exhaustion are suspicious.

• node_modules/uglify-js/package.json
• "uglify-js"
• "uglify-js":"2.5
• "uglify-js": "2.5
• "uglify-js":"2.4
• "uglify-js": "2.4
• "uglify-js":"2.3
• "uglify-js": "2.3
• "uglify-js":"2.2
• "uglify-js": "2.2
• "uglify-js":"2.1
• "uglify-js": "2.1
• "uglify-js":"2.0
• "uglify-js": "2.0
• "uglify-js": "<2.6.0"
• "uglify-js":"<2.6.0"
• JS_Parse_Error
• UglifyJS.parse
• parse call
• JavaScript heap out of memory
• FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed
• 504 Gateway Time-out
• 503 Service Unavailable
• upstream timed out
• worker timeout
• node

What your security team should do

• Inventory all applications, containers, CMS packages, plugins, and build systems that include uglify-js, prioritizing internet-facing services and workflows that process user-supplied JavaScript.
• Upgrade uglify-js to 2.6.0 or later and upgrade Bitnami WordPress deployments to 3.7.40 or later where applicable.
• Search for vulnerable transitive dependencies in lockfiles and nested node_modules directories, not only top-level package.json files.
• Restrict or disable public access to server-side JavaScript minification/parsing features until patched.
• Add input size limits, parsing timeouts, worker isolation, and rate limiting around any feature that parses user-controlled JavaScript.
• Review historical logs and CPU telemetry for unexplained spikes tied to JavaScript parsing, upload, preview, theme, plugin, or asset-processing routes.
• Add dependency scanning to CI/CD and image build pipelines to prevent reintroducing vulnerable uglify-js versions.