CVE-2026-45792: RTK Configuration Injection Allows Silent Output Suppression in LLM Workflows

Technical summary

RTK improperly implements implicit trust in project-local configuration files. The vulnerability stems from automatic loading of .rtk/filters.toml from the current working directory without explicit user notification or consent. The configuration format supports regex-based output transformations (such as strip_lines_matching) that can selectively remove, redact, or alter shell command output. Because RTK prioritizes local configuration highest, an attacker who commits a poisoned filters.toml to a shared repository will have their rules applied transparently to any developer who runs RTK in that directory. The absence of output modification indicators means developers cannot detect that information has been filtered, creating a silent information disclosure and integrity risk in the AI-assisted development pipeline. The fix in version 0.32.0 addresses the automatic trust model.

Business impact

This vulnerability threatens the integrity of code review and development workflows that rely on LLM assistance. If an attacker can inject a malicious filter configuration into a shared repository, they can hide suspicious code patterns, security vulnerabilities, or unauthorized changes from both human reviewers and AI tools. The risk is amplified in organizations using RTK to improve LLM context efficiency, where developers trust the output they see. Supply chain scenarios (e.g., open-source contributions, team repositories) present the highest exposure. The attack leaves minimal forensic evidence since output suppression happens transparently.

Affected systems

RTK versions prior to 0.32.0 are affected. The vulnerability requires local code repository write access and user interaction (execution of RTK commands in a compromised working directory). Systems where developers run RTK on untrusted or community-contributed code, or where repository access controls are not strictly enforced, face the greatest risk. Organizations using RTK in continuous integration pipelines are potentially affected if those pipelines process repositories not fully controlled by the organization.

Exploitability

Exploitation requires two preconditions: (1) write access to the target repository to place a malicious .rtk/filters.toml file, and (2) the target user must execute RTK commands in that directory. The CVSS vector (AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N) reflects local attack surface, low complexity once access is gained, and user interaction (running RTK). This is not a remote code execution vulnerability. The attack is most practical in open-source or internal-project contexts where contributors routinely clone and develop on shared code. No known public exploit exists at this time, and the vulnerability is not listed on the KEV catalog.

Remediation

Upgrade RTK to version 0.32.0 or later. Organizations should audit existing .rtk/filters.toml files in repositories for unauthorized or suspicious filter rules. Consider implementing repository branch protection policies and code review requirements for configuration files. For teams using RTK in shared development environments, establish guidelines that limit local filter configurations or disable implicit loading of project-local config files if the tool provides such an option.

Patch guidance

Apply the upgrade to RTK 0.32.0 as soon as feasible. The fix changes how RTK handles project-local configuration trust; verify the release notes and vendor documentation to confirm the new behavior meets your workflow requirements. No breaking changes to filter syntax are noted, so upgrades should be straightforward. Test the upgrade in a non-production environment first to confirm that legitimate filter configurations continue to work as expected.

Detection guidance

Review .rtk/filters.toml files in repositories for unexpected or suspicious regex patterns, particularly those using strip_lines_matching or similar redaction rules. Audit RTK command execution logs (if available) to identify which configurations were applied. Monitor for discrepancies between raw command output and output visible to developers (though this is difficult since the tool intentionally suppresses visibility). Implement file integrity monitoring on configuration files in sensitive repositories. In CI/CD contexts, log the contents of RTK configuration files used during pipeline execution.

Why prioritize this

This vulnerability merits prompt but not emergency remediation. The CVSS score of 5.5 (MEDIUM) reflects the integrity risk and local-attack-surface constraint. The absence of KEV listing indicates it has not been actively exploited in the wild at scale. However, the attack is subtle and could go undetected in code review workflows, making it strategically valuable to an attacker. Teams that rely on RTK for LLM context efficiency, especially those accepting external contributions, should prioritize upgrade within 30–60 days. The fix is low-risk and should be applied before engaging with untrusted repositories.

Risk score, explained

The CVSS:3.1 score of 5.5 (MEDIUM) is driven by high integrity impact (I:H)—output can be silently altered—against low attack surface (AV:L/PR:N/UI:R). The vulnerability does not affect confidentiality or system availability. Scope is unchanged (S:U), meaning the impact is limited to RTK users, not the broader system. The medium score appropriately reflects a real but context-dependent risk: significant for organizations that rely on RTK and accept untrusted code, lower for isolated or fully-controlled development environments.

Frequently asked questions