In recent days, cybersecurity experts have observed a worrying surge in attempts to access Git repository configuration files. According to GreyNoise, a global threat intelligence platform, over 4,800 unique IP addresses scanned for .git/config files on April 20–21 alone — the highest number ever recorded, signaling a dramatic rise in attacker interest toward vulnerable Git-enabled systems.
While this is not a new vulnerability, researchers warn that cybercriminals are actively exploiting known weaknesses, particularly CVE-2021-23263. This flaw stems from misconfigured web servers that expose the .git directory to the public. If exploited, an attacker could download the entire repository, including the full commit history, configuration files, and — most dangerously — any embedded credentials.
According to GreyNoise, 95% of the IPs attempting .git access in the last 90 days were flagged as malicious. This activity spans nearly every global region, but is heavily concentrated in Asia. Singapore stands out as both the top origin and primary target of these scans. The U.S. ranks second, followed by Germany, the U.K., and India.
Interestingly, many of the suspicious IPs are linked to major cloud providers like Cloudflare, Amazon, and DigitalOcean, indicating that attackers are leveraging scalable infrastructure to amplify and disguise their reconnaissance operations.
This marks the fourth such wave of scanning activity since September 2024, but it dwarfs previous events in scope. Earlier spikes peaked at fewer than 3,000 IPs — this time, the two-day count surged 50% higher.
Exposing .git/config is more than just a technical misstep. It can reveal branch structures, internal repository links, author metadata, and even sensitive credentials accidentally committed to history. A similar misconfiguration in 2024 led to the leak of 15,000 user accounts and the cloning of 10,000 private repositories.
Immediate Protective Measures Recommended
Experts are urging all organizations to act now:
- Ensure the .git directory is not accessible via the web server.
- Block access to hidden files and directories at the configuration level.
- Set up log monitoring to detect repeated .git/config access attempts.
- If compromise is suspected, rotate all affected credentials without delay.
Any organization using Git in development should treat such scans as direct threats to source code security. The sooner the vulnerabilities are closed, the better the chances of avoiding serious damage.
Would you like a checklist or configuration guide to harden your server against this type of attack?
