LangChain JiraAPIWrapper OS Command Injection
A vulnerability in LangChain's JiraAPIWrapper component (fixed in v0.0.225) fails to sanitize input before passing it to Python's exec() or os.system(), letting an attacker turn a JIRA API call into arbitrary code execution on the host running the LangChain agent. This detection flags the specific pattern of a JIRA REST call followed by a suspicious interpreter spawn from the same process.
How the attack works
An attacker sends crafted input through a LangChain agent that uses the vulnerable JiraAPIWrapper to talk to a JIRA REST endpoint. Because the wrapper does not sanitize this input, the payload reaches an exec()/os.system() call, spawning a shell or scripting interpreter (sh -c, python -c, node -e, or powershell -Command) with attacker-controlled arguments. That inline command can then perform data exfiltration, reconnaissance, obfuscation, or set up persistence. The detection ties these two steps together only when the JIRA call and the interpreter spawn come from the exact same running process (not just the same process ID reused later), and only when the JIRA call happens first.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7b3f1c84-9a2e-4d6b-8f0a-3c5e91d47b2a
- Severity
- High
Why it matters
Successful exploitation gives an attacker code execution on whatever host runs the LangChain agent, with the same privileges as that agent process. This can lead to data theft, lateral movement, or a persistent foothold, depending on what the agent's host can reach.
What you can do
- →Upgrade LangChain to v0.0.225 or later, where the JiraAPIWrapper flaw is fixed.
- →Audit any agent that combines JIRA integration with shell-execution tools, and separate those capabilities where possible.
- →Restrict the LangChain host process's outbound network and shell access to only what the agent strictly needs.
- →Review alerts from this detection manually rather than auto-blocking, since legitimate SRE/support agents and CI/CD pipelines can produce the same JIRA-call-then-shell-command pattern.
Known benign look-alikes
- An SRE/support agent built on LangChain that legitimately reads a JIRA ticket and then runs a diagnostic shell tool containing curl/wget/whoami within the same three-minute window. Mitigated by requiring the inline "-c"/"-e" interpreter form, a Python or LangChain ancestor in the SAME resolved lineage, strict ordering (JIRA call must precede the spawn) and a payload indicator - but a shell-enabled agent can still hit all four legitimately, which is why the action is report and not block.
- CI/CD jobs where a Python step posts to the JIRA REST API and a later step in the same process tree shells out to curl/wget for artefact download.
- Self-hosted Atlassian products other than JIRA (Confluence, Bitbucket) that expose the same /rest/api/2/ or /rest/api/latest/ path prefixes, which will satisfy the anchor stage on path alone.
- Deliberate vulnerability research or red-team reproduction of the JiraAPIWrapper CVE against a lab instance.
- Python interpreters invoked with "-c" by packaging/build tooling (pip, setuptools, poetry) that happens to run inside a LangChain process tree shortly after a JIRA call.