CVE-2022-25758

What it actually does

This vulnerability is a Regular Expression Denial of Service in the scss-tokenizer package. The loadAnnotation() function uses an unsafe regular expression that can be forced into excessive backtracking when it processes specially crafted SCSS/CSS annotation content. If an application accepts attacker-controlled stylesheet, theme, template, or build input and passes it to scss-tokenizer, a single malicious input can consume CPU for an extended period, block the Node.js event loop or worker process, and degrade or stop service availability. The issue does not directly provide code execution, data disclosure, or data modification.

Why it matters to the business

Successful exploitation can make applications or build services that process SCSS unresponsive, causing outages, failed builds, delayed deployments, degraded user experience, and increased infrastructure costs from hung workers or autoscaling. The package has exploit material publicly available, but it is not listed in the CISA Known Exploited Vulnerabilities catalog and its EPSS score is low, so prioritization should be driven mainly by whether the package is exposed to untrusted input in production or CI/CD workflows.

How an attack unfolds

An attacker identifies an application feature or service that accepts SCSS, CSS-like content, design themes, templates, uploaded stylesheets, or remote repository content and processes it with scss-tokenizer. The attacker submits a crafted annotation pattern designed to trigger catastrophic backtracking in loadAnnotation(). When the service tokenizes the input, the vulnerable regular expression consumes excessive CPU and may block the Node.js event loop, exhaust worker timeouts, or cause process managers to restart the service. Repeated requests or submitted files can keep the affected service unavailable. Exploitation is most practical where untrusted users can directly or indirectly influence stylesheet content processed synchronously by the application.

How to fix it

No fixed upstream version is listed for scss-tokenizer for this vulnerability. Remove the dependency if it is unused, replace it with a maintained tokenizer/parser, or vendor/fork the package and replace the vulnerable regular expression in loadAnnotation() with a safe, bounded parser or a non-backtracking expression. If immediate replacement is not possible, reduce risk by rejecting or strictly limiting untrusted SCSS/CSS input size and annotation length, applying request and job execution timeouts, processing stylesheet parsing in isolated worker processes, rate-limiting endpoints that trigger parsing, and preventing unauthenticated users from submitting content that reaches scss-tokenizer. Regenerate lockfiles and redeploy all services and build images that contain the package after remediation.

How to confirm the fix worked

Confirm exposure by searching dependency manifests and lockfiles for scss-tokenizer, including package-lock.json, yarn.lock, pnpm-lock.yaml, npm-shrinkwrap.json, and container or build artifacts. Use npm ls scss-tokenizer, yarn why scss-tokenizer, or equivalent SCA tooling to identify direct and transitive use. Validate remediation by confirming the package is removed, replaced, or patched in all deployed artifacts and CI/CD images. Where the component remains in use, run controlled performance tests with malformed or oversized annotation input in a non-production environment and verify parsing is bounded by input validation, worker isolation, and timeouts rather than causing sustained CPU saturation.

Typical attack path

1. Find an application endpoint, import job, theme editor, stylesheet upload, repository scanning job, or build pipeline that processes SCSS/CSS input.
2. Confirm that the processing path uses the vulnerable scss-tokenizer package.
3. Create SCSS/CSS annotation content with long, repetitive, or malformed patterns that trigger excessive regular-expression backtracking in loadAnnotation().
4. Submit the crafted content through the exposed feature or commit it to a repository processed by an automated job.
5. Cause the Node.js process or build worker to consume high CPU, stall the event loop, hit request/build timeouts, or restart.
6. Repeat submissions or parallelize requests to sustain denial of service.

How to detect it

Review application, reverse-proxy, API gateway, build-system, and process-manager logs for requests or jobs that submit SCSS/CSS content immediately followed by high CPU, long response times, request timeouts, worker termination, or service restarts. Focus on endpoints that handle theme editing, stylesheet uploads, repository import, template preview, CSS/SCSS compilation, or design asset processing. In Node.js environments, inspect logs for event-loop delay warnings, worker timeouts, uncaught fatal process exits, and stack traces referencing scss-tokenizer or loadAnnotation(). Compare request bodies or uploaded files, where safely retained, for very long annotation/comment-like sequences, repetitive characters, or malformed annotation syntax. Because ReDoS attempts often leave few durable artifacts, correlate telemetry: repeated similar submissions from the same source, sustained single-threaded CPU saturation, and parsing jobs that hang without corresponding increases in memory, database, or downstream-service activity.

• scss-tokenizer
• loadAnnotation
• node_modules/scss-tokenizer
• node_modules/scss-tokenizer/
• FATAL ERROR: Reached heap limit Allocation failed
• JavaScript heap out of memory
• ETIMEDOUT
• Request timed out
• worker timeout
• event loop delay
• Event loop blocked
• CPU usage exceeded
• SIGTERM
• SIGKILL

What your security team should do

• Prioritize applications where users, third parties, repositories, or external integrations can submit SCSS/CSS-like content that is parsed server-side.
• Inventory all direct and transitive uses of scss-tokenizer across source repositories, build pipelines, containers, and deployed services.
• Remove or replace scss-tokenizer where feasible because no fixed upstream version is listed.
• If replacement is delayed, enforce strict input-size limits, annotation-length limits, request/job timeouts, worker isolation, and rate limiting around stylesheet parsing paths.
• Monitor affected services for CPU spikes, event-loop stalls, request timeouts, build job hangs, and repeated submissions of unusually large or malformed stylesheet annotations.
• Add dependency checks to CI so vulnerable versions of scss-tokenizer are not reintroduced through transitive dependencies.