[WIP] Fix ajv ReDoS vulnerability with $data option

[Copilot]

Plan to fix ajv ReDoS vulnerability

• Add ajv@^8.18.0 as a direct dependency in tools/data-handler (to supersede the vulnerable 8.17.1 from directory-schema-validator)
• Run pnpm install to update lock file
• Verify build and tests pass
• Add reachability assessment to PR description
• Run security scan with parallel_validation

Original prompt

---

This section details the Dependabot vulnerability alert you should resolve

<alert_title>ajv has ReDoS when using $data option</alert_title>
<alert_description>ajv (Another JSON Schema Validator) through version 8.17.1 is vulnerable to Regular Expression Denial of Service (ReDoS) when the $data option is enabled. The pattern keyword accepts runtime data via JSON Pointer syntax ($data reference), which is passed directly to the JavaScript RegExp() constructor without validation. An attacker can inject a malicious regex pattern (e.g., \"^(a|a)*$\") combined with crafted input to cause catastrophic backtracking. A 31-character payload causes approximately 44 seconds of CPU blocking, with each additional character doubling execution time. This enables complete denial of service with a single HTTP request against any API using ajv with $data: true for dynamic schema validation.</alert_description>

moderate
GHSA-2g4f-4pwh-qvx6, CVE-2025-69873
ajv
npm
<vulnerable_versions>8.17.1</vulnerable_versions>
<patched_version>8.18.0</patched_version>
<manifest_path>pnpm-lock.yaml</manifest_path>

https://nvd.nist.gov/vuln/detail/CVE-2025-69873 https://github.com/EthanKim88/ethan-cve-disclosures/blob/main/CVE-2025-69873-ajv-ReDoS.md https://github.com/ajv-validator/ajv/pull/2586 https://github.com/ajv-validator/ajv/commit/720a23fa453ffae8340e92c9b0fe886c54cfe0d5 https://github.com/ajv-validator/ajv/releases/tag/v8.18.0 https://github.com/ajv-validator/ajv/pull/2588 https://github.com/ajv-validator/ajv/releases/tag/v6.14.0 https://github.com/advisories/GHSA-2g4f-4pwh-qvx6 https://github.com/ajv-validator/ajv/pull/2590 https://github.com/github/advisory-database/pull/6991

<agent_instructions>Read pnpm lock and find what is the project level dependency that constrains this package from updating to a version required for the security issue to be fixed. If the issue can be fixed by upgrading to a newer version of the project package, update the package and run pnpm install to update pnpm lock and create a PR.</agent_instructions>

<task_instructions>Resolve this alert by updating the affected package to a non-vulnerable version. Prefer the lowest non-vulnerable version (see the patched_version field above) over the latest to minimize breaking changes. Include a Reachability Assessment section in the PR description. Review the alert_description field to understand which APIs, features, or configurations are affected, then search the codebase for usage of those specific items. If the vulnerable code path is reachable, explain how (which files, APIs, or call sites use the affected functionality) and note that the codebase is actively exposed to this vulnerability. If the vulnerable code path is not reachable, explain why (e.g. the affected API is never called, the vulnerable configuration is not used) and note that the update is primarily to satisfy vulnerability scanners rather than to address an active risk. If the advisory is too vague to determine reachability (e.g. 'improper input validation' with no specific API named), state that reachability could not be determined and explain why. Include a confidence level in the reachability assessment (e.g. high confidence if the advisory names a specific API and you confirmed it is or is not called, low confidence if the usage is indirect and hard to trace). If no patched version is available, check the alert_description field for a Workarounds section — the advisory may describe configuration changes or usage patterns that mitigate the vulnerability without a version update. If a workaround is available, apply it and leave a code comment referencing the advisory identifier explaining it is a temporary mitigation. If neither a patch nor a workaround is available, explain in the PR description why the alert cannot be resolved automatically so a human reviewer can take over. Inspect the repository to determine which package manager is used (e.g. lock files, config files, build scripts) and use that tooling to perform the update — do not edit lock files directly. If the version constraint in the manifest (e.g. package.json, Gemfile, pyproject.toml) caps the version below the fix, update the constraint first. For transitive dependencies, determine whether it is simpler to update the direct dependency that pulls in the vulnerable package or to update the transitive dependency directly, and choose the least disruptive approach. If upgrading to fix the vulnerability forces a major version bump or known breaking changes, review the changelog or release notes, then audit the codebase for usage of affected APIs and fix any breaking changes that are found. If the package manager fails to resolve dependencies (e.g. peer dependency conflicts, incompa...

• Resolves CyberismoCom/cyberismo alert Bump @typescript-eslint/eslint-plugin from 7.18.0 to 8.2.0 in /tools/data-handler #87