CVE-2026-57586: CodeRAG: Gradle Wrapper Execution During Dependency Discovery Enables Arbitrary Code Execution
CodeRAG is a lightweight semantic code search and distillation utility for AI coding agents. Prior to 1.3.1, the default agent-coderag sync flow in coderag/entry/cli.py calls syncdependencies for an indexed path, and coderag/core/manager.py treats build.gradle or build.gradle.kts as sufficient to invoke syncgradle. syncgradle prefers a repository-controlled gradlew or gradlew.bat file and passes it directly to asyncio.createsubprocessexec with the repository root as the working directory; validatepath in coderag/core/utils.py constrains the directory location but does not validate the executable's content or integrity. A victim who indexes an attacker-controlled Gradle repository therefore executes attacker-supplied code with the victim's operating-system privileges, allowing disclosure, modification, persistence, or denial of service in the user environment. This issue is fixed in 1.3.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
CodeRAGto a version that resolves this vulnerability.Fixed in 1.3.1 - Compensating control
For dependency discovery/indexing, avoid indexing attacker-controlled directories or repositories; restrict indexing of Gradle projects to trusted sources to prevent executing a repository-controlled gradlew/gradlew.bat.
Event History
Frequently Asked Questions
Who is exposed to exploitation?
Users running a version prior to 1.3.1 are exposed when they use the default agent-coderag sync flow to index an attacker-controlled repository containing Gradle build files and a repository-controlled Gradle wrapper.
What does an attacker need to exploit this issue?
The attacker needs to convince a victim to index a Gradle repository under the attacker’s control. No privileges are required from the attacker, but victim interaction is required to initiate indexing.
Does the vulnerability execute code with limited permissions?
No. The attacker-supplied Gradle wrapper is launched with the victim's operating-system privileges, so its code can disclose or modify data, establish persistence, or cause denial of service in that user environment.
What should be done if patching is not immediately possible?
Do not index untrusted or attacker-controlled Gradle repositories with the affected sync flow. In particular, avoid repositories containing build.gradle or build.gradle.kts together with a repository-provided gradlew or gradlew.bat file.
How can I determine whether an installation is affected?
Installations running CodeRAG before version 1.3.1 are affected if they use the default agent-coderag sync flow on indexed Gradle project paths. Version 1.3.1 contains the fix.