[260828] Hacked by Doing Security Checks? Malicious Injections in JSON/YAML Parsing and Validation

The x-cmd team released `x ajv`, a Deno-based JSON/YAML/TOML validator that sandboxes AJV with read-only access to prevent malicious injections and privilege escalation, addressing CVE-2026-39890 in PraisonAI and CVE-2020-15366 in Ajv. The tool supports stdin streaming and Schema reuse for high-performance CI batch validation, and defaults to only `--allow-read` permission, blocking network, write, process, and environment variable access.

Hacked by Doing Security Checks? Malicious Injections in JSON/YAML Parsing and Validation TLDR x ajv uses Deno and AJV to sandbox JSON/YAML/TOML validation with read-only access, preventing malicious injections and privilege escalation. It supports stdin streaming and Schema reuse for high-performance CI batch validation. Last Sunday, I was processing external PRs for the x-cmd/install repository. The PRs modify YAML configurations, Schemas, and add a large batch of new configuration files all at once. Before merging, these external submissions must undergo a check to ensure there is no non-compliant content. This led me to search for a tool suitable for batch configuration validation. However, I quickly discovered that the validation process itself poses security risks, and no suitable existing tools were available. Configurations as Attack Vectors This year, the AI Agent framework PraisonAI encountered an issue with YAML parsing. CVE-2026-39890 shows that its AgentService reads user-uploaded Agent YAML files. Once an attacker crafts a malicious YAML, the server might execute JavaScript controlled by the attacker while parsing this "configuration file," ultimately granting code execution privileges on the server. In essence, the attacker submitted a YAML file, but the server treated it as executable code. Therefore, formats like JSON, YAML, and TOML, which appear to be mere configuration files, are equally untrusted external inputs. For repositories like x-cmd/install , configurations introduced by external PRs cannot be trusted blindly. Beyond checking whether files parse normally, it is necessary to verify compliance with predefined Schemas. This is precisely why configuration validators exist. Securing the Validator However, the validator itself can also become an attack vector. In 2020, Ajv suffered from CVE-2020-15366: attackers could supply crafted JSON Schemas to execute arbitrary code during the validation process via prototype pollution. That is to say, malicious configurations can exploit parsers, and malicious Schemas can exploit validators. If the validator runs with full system permissions, the issue escalates beyond a simple validation failure. It might proceed to read API keys from environment variables, access the network, modify files, or spawn other processes. Thus, we specifically developed the x ajv module. Sandboxing the Validator x ajv is built on top of Deno + AJV and defaults to granting only --allow-read permission during validation. It can read the target files and Schemas, while all other permissions are disabled by default: | Capability | x ajv | |---|---| | Read Files | ✓ | | Network Access | ✗ | | Write Files | ✗ | | Create Processes | ✗ | | Read Environment Variables | ✗ | Even if the underlying parser is exploited by malicious input, the attacker will not gain a process with full system privileges. Only two final pieces remain to be implemented: timeout and CPU quota . The former limits how long a single validation run can take, while the latter caps the compute resources it can consume. High-Performance Batch Validation In addition to security, x ajv is optimized for batch validation: it supports stdin streaming input and Schema compilation reuse, making it ideal to pair with find for processing large volumes of files at once and outputting TSV directly for CI scripts. It also remains compatible with common ajv-cli flags, eliminating the need to prepare a package.json , and allows direct validation of JSON, YAML, and TOML files. Configurations Need Verification In the past, discussions focused heavily on code verification: testing, reviewing, and scanning for vulnerabilities after AI generated code. Now, AI is also generating and modifying configurations in bulk. Workflows, CI/CD pipelines, Agents, and toolchains are increasingly driven by JSON, YAML, TOML, and Schemas. Code requires verification, and configuration requires verification just as well; and the tools responsible for verifying them must maintain their own security boundaries. How does your team handle YAML / JSON validation in Agent workflows? Do you have an established CI / PR validation setup running smoothly? Feel free to leave a comment and discuss. Please indicate the source and link of this article when reprinting. Help us make these docs great All X-CMD docs are generated from command help and multiple data sources. See something that's wrong or unclear? Feel free to let us know through any of these ways~