CVE-2025-69873

What it actually does

The flaw is a Regular Expression Denial of Service condition in dynamic JSON schema validation. When ajv is used with the $data option enabled, the pattern keyword can take a runtime value through a JSON Pointer reference and pass that attacker-controlled value directly into JavaScript's RegExp() constructor. A malicious regular expression such as ^(a|a)*$ paired with crafted input can trigger catastrophic backtracking, causing the event loop or validation worker to consume CPU for an extended period. The described behavior can block request processing and reduce service availability; it does not directly provide confidentiality or integrity compromise.

Why it matters to the business

Successful exploitation can make an API or service temporarily unavailable with very little attacker traffic, potentially causing request timeouts, failed transactions, degraded user experience, autoscaling cost spikes, and operational incidents. The vulnerability is not listed in CISA KEV, is not reported as ransomware-associated, and has low EPSS at the time of the provided data, so broad active exploitation is not indicated; however, internet-facing APIs that accept user-controlled schema data or validation rules should treat this as a practical availability risk. The input metadata contains a mismatch between the vulnerability description, which describes ajv, and the affected product list, which names aiohttp, so engineering teams should verify both direct and transitive dependency exposure before prioritizing rollout.

How an attack unfolds

An attacker first identifies an endpoint or workflow that performs JSON schema validation using ajv with $data: true and allows user-controlled data to influence the pattern keyword. The attacker submits JSON that causes the validator to construct a regular expression from attacker-supplied runtime data, using a pattern designed for catastrophic backtracking, such as ^(a|a)*$. The attacker then supplies a string that nearly matches the expression but fails at the end, forcing the JavaScript regular expression engine to explore exponentially many paths. During validation, CPU is consumed synchronously and request handling stalls. In Node.js services, this can block the event loop; in worker-based deployments, it can exhaust workers. Repeating the request or increasing the payload length can create prolonged denial of service.

How to fix it

Upgrade vulnerable components to fixed versions. For ajv, use version 8.18.0 or later; if using the 6.x line, use 6.14.0 or later. The supplied package metadata also lists aiohttp fixed in 3.13.3; because this conflicts with the ajv-specific description, verify software bills of materials, lockfiles, and transitive dependencies to confirm whether ajv, aiohttp, or both are present and upgrade affected packages accordingly. If immediate upgrade is not possible, disable ajv $data support where it is not strictly required, prevent untrusted users from controlling schema pattern values, validate or allow-list acceptable regex patterns, reject nested quantifiers and ambiguous alternations, enforce request body size limits, set application-level validation timeouts where feasible, and apply rate limiting to endpoints that perform expensive validation.

How to confirm the fix worked

Confirm exposure by reviewing dependency manifests and lockfiles for ajv versions earlier than 8.18.0, ajv 6.x versions earlier than 6.14.0, and any listed affected package versions such as aiohttp earlier than 3.13.3 where applicable. Review application code and configuration for ajv initialization with $data: true and schemas that use pattern with $data references. After upgrading or mitigating, run dependency scanners and unit/integration tests that exercise dynamic schema validation. A safe validation test should confirm that attacker-controlled pattern values are rejected, sanitized, or no longer accepted, and that suspicious regex patterns do not cause sustained CPU blocking. Monitor application latency and CPU under controlled test requests to ensure validation completes within expected bounds.

Typical attack path

1. Find an API endpoint or application feature that accepts JSON and performs schema validation.
2. Determine or infer that validation uses dynamic schema data, especially ajv with the $data option enabled.
3. Submit a payload that places an attacker-controlled value into a pattern keyword through a $data reference.
4. Use a catastrophic-backtracking regular expression such as ^(a|a)*$ as the injected pattern.
5. Send crafted input containing repeated characters that force the regex engine into exponential backtracking.
6. Cause request processing to hang, CPU utilization to spike, and legitimate requests to time out.
7. Repeat or parallelize requests to sustain service degradation or denial of service.

How to detect it

To determine whether exploitation has already occurred, review API gateway, reverse proxy, WAF, and application access logs for requests containing JSON schema-like fields such as $data and pattern, especially combined with suspicious regular expression syntax. Correlate those requests with spikes in CPU usage, Node.js event-loop lag, worker thread saturation, container restarts, request duration outliers, HTTP 408/429/499/500/502/503/504 responses, and upstream timeout messages. Application logs may show long validation durations, request timeouts, health-check failures, or watchdog restarts without corresponding increases in traffic volume. Source IPs that send small numbers of requests causing disproportionate CPU load should be investigated. For forensic review, inspect retained request bodies where legally and operationally permitted, dependency manifests, container images, and runtime configuration for ajv $data enablement. There are no named threat actors or KEV exploitation signals in the supplied data, so detection should focus on behavioral denial-of-service evidence and payload artifacts rather than campaign-specific infrastructure.

• "$data"
• "pattern"
• "pattern":{"$data"
• "pattern": { "$data"
• "^(a|a)*$"
• "(a|a)*"
• "$data: true"
• "$data": true
• "new RegExp("
• "RegExp("
• "node_modules/ajv/package.json"
• "ajv@8.17"
• "ajv@8.16"
• "ajv@6.13"
• "aiohttp==3.13.2"
• "aiohttp==3.13.1"
• "aiohttp==3.13.0"

What your security team should do

• Prioritize internet-facing APIs, authentication-adjacent services, payment or transaction workflows, and high-availability control planes that parse JSON and perform schema validation.
• Ask engineering teams to verify the metadata mismatch by checking actual dependencies for ajv and aiohttp rather than relying only on the affected product label.
• Upgrade ajv to 8.18.0 or later, or 6.14.0 or later for the 6.x branch; upgrade aiohttp to 3.13.3 if it is confirmed to be the affected dependency in package inventory.
• Search code repositories for ajv configured with $data: true and schemas where pattern is populated from runtime data.
• Add WAF, API gateway, or application-layer rate limits for endpoints performing JSON validation, especially where request bodies contain schema-like structures.
• Create detection rules for repeated requests containing $data, pattern, and known catastrophic regex constructs from the same source over short time windows.
• Monitor service-level indicators for unexplained CPU saturation, event-loop lag, worker exhaustion, request timeouts, and latency spikes on JSON-processing endpoints.
• Treat evidence of successful denial of service as an incident: preserve access logs, application logs, request samples, container metrics, and process telemetry for root-cause analysis.