CVE-2017-14867

What it actually does

Unsafe Perl scripts in Git subcommands such as cvsserver accept module names containing shell metacharacters, enabling arbitrary OS command execution; the vulnerable code path remains reachable via git-shell even when CVS support is disabled.

Why it matters to the business

Attackers who can reach a vulnerable Git installation can run any commands on the host, leading to full system compromise, data theft, or ransomware deployment; the flaw affects widely used Git packages across Linux distributions and has been public for years.

How an attack unfolds

An attacker supplies a crafted module name containing shell metacharacters to a Git subcommand such as cvsserver over an SSH session handled by git-shell; the unsafe Perl script passes the input directly to the shell, resulting in immediate command execution on the server.

How to fix it

Upgrade Git to version 2.10.5 or later, 2.11.4 or later, 2.12.5 or later, 2.13.6 or later, or 2.14.2 or later; apply the corresponding security updates from your Linux distribution package manager.

How to confirm the fix worked

Run 'git --version' on affected systems and confirm the installed version meets or exceeds one of the fixed releases listed in remediation; attempt a controlled non-destructive test payload in an isolated environment to verify the injection vector is closed.

Typical attack path

1. Identify a reachable Git server exposing git-shell or cvsserver
2. Craft a module name containing shell metacharacters that invoke desired OS commands
3. Submit the payload via SSH or the Git protocol to the vulnerable subcommand handler
4. Execute arbitrary commands, establish persistence, or exfiltrate data

How to detect it

Search SSH daemon logs and Git server logs for unusual module names containing shell metacharacters such as semicolons, pipes, or backticks sent to cvsserver or similar subcommands; review process execution logs for unexpected child processes spawned by git or perl during repository operations.

What your security team should do

• Immediately upgrade all Git installations to a fixed release
• Restrict git-shell access to only trusted users and repositories
• Monitor package repositories for backported fixes on older distribution releases
• Audit any custom scripts or wrappers that invoke Git subcommands