GitHub Git Infrastructure RCE Flaw Discovered

A team set up Gitleaks. Scanned clean. Pushed to GitHub. GitHub Push Protection blocked the push. Stripe key. Slack webhook. Still sitting in commit history from 3 weeks ago. The pre-commit hook never saw it — it only checks staged files. GitHub saw everything. --- I just published Article 3 of my DevSecOps series: 🔐 I Switched from Gitleaks to Betterleaks — Here's What Changed Same author. Smarter engine. And a real hands-on demo where every layer of protection fires in sequence. Here's what the article covers: → Why Gitleaks' entropy scoring produces false positives — and what Betterleaks does differently (BPE token efficiency: 70% → 98% recall) → Pre-commit hooks: what they catch, and the critical blind spot they leave open → Scanning full Git history with --git-workers for parallel speed → Recursive decoding — base64, hex, URL-encoded secrets caught automatically → GitHub Actions CI pipeline with SARIF upload to the Security tab → GitHub Push Protection: the server-side layer that blocked what the hook missed → Baseline workflow — so old findings don't break your pipeline on day one → Custom detection rules in TOML for org-specific token formats I also built a full demo repo so you can run every scenario yourself — blocked commits, blocked pushes, CI failures, the works. 🔗 Article: https://lnkd.in/dwfKgd9j 🛠 Demo repo: https://lnkd.in/dswtfWyV --- The defence stack isn't one tool. It's four layers — each catching what the previous one misses. If you're running Gitleaks today, switching takes 30 seconds. If you're starting fresh — start here. #DevSecOps #Security #Git #Betterleaks #Gitleaks #SecretScanning #PreCommit #GitHubActions #AppSec #DevOps #Cybersecurity #OpenSource

One authenticated git push achieved remote code execution on GitHub's backend. That's CVE-2026-3854. Any GitHub user with push access to a repo could inject arbitrary commands by crafting push option values. The internal X-Stat header used a delimiter that appeared in user input. One crafted push and the git service ran hooks with no sandbox, full filesystem access, as the git service user. GitHub.com was patched silently on March 4. Enterprise Server got a fix on March 10. Public disclosure came April 28. Seven weeks of silence while Help Net Security confirmed 88% of self-hosted GitHub Enterprise Server instances were still running the vulnerable build. If you're on GHES, you need version 3.19.3 or later. The CVSS score is 8.7. The attack doesn't need a zero-click exploit or advanced tooling. Write access to any repository is enough. The seven-week disclosure gap bothers me more than the bug. Responsible disclosure gives defenders time to patch. Running 88% of enterprise instances exposed while the vendor says nothing isn't coordinated disclosure. It's a liability transfer. When did your security team last verify which GitHub Enterprise Server version your organization is running? #AppSec #GitHub #CVE20263854 #SupplyChainSecurity #DevSecOps

Just read an incredible breakdown by the Wiz Research team on a critical GitHub RCE vulnerability (CVE-2026-3854). The TL;DR: An injection flaw in GitHub's internal git pipeline allowed attackers to execute arbitrary commands on backend servers with just a single git push command, exposing both GitHub.com and GitHub Enterprise Server infrastructure. My Take: The most fascinating part of this article isn't actually the vulnerability itself, but how it was discovered. The Wiz team had previously attempted to hunt for these exact types of vulnerabilities in GitHub's compiled, black-box binaries. With traditional tooling, auditing this massive multi-service architecture required an impractical amount of time and manual effort, leading to a dead end. Enter AI. By leveraging AI-augmented tooling—specifically automated reverse engineering—the team was able to rapidly analyze complex binaries, reconstruct internal protocols, and map out exactly where user input influenced server behavior. What was previously too costly and complex became achievable, marking a huge shift in how vulnerabilities are hunted in closed-source apps. AI isn't just generating code; it's finding the needle in the haystack of compiled binaries. A massive win that highlights the future of vulnerability research! Check out the full deep-dive here: https://lnkd.in/eF-CzxpH #CyberSecurity #VulnerabilityResearch #ArtificialIntelligence #GitHub #InfoSec #Wiz #AppSec #AIinSecurity #TechNews

🔐 How secure are your GitHub Actions workflows and software supply chain today? GitHub includes a range of built‑in security features that you can enable across your SDLC, many teams just aren’t using them to their full potential. We’ve published practical steps you can apply today, along with a roadmap of security capabilities coming next, to help secure the open‑source supply chain across GitHub. 🔗 https://lnkd.in/gUattvvh

GitHub should do more than recommend. They could use their resources to: - pin all actions to their current resolved sha via dependabot, if active (prevents hidden downgrades) - only allow mutable tags if people opt into it (secure by default) - fail workflows if unpinned and config not present (secure by default) - invest in tooling to make docs show real shas (model behavior)

A critical GitHub vulnerability, tracked as CVE‑2026‑3854, allowed authenticated users to achieve remote code execution (RCE) across GitHub.com and GitHub Enterprise Server using nothing more than a single malicious git push command. Why This Vulnerability Is So Severe 1. RCE Across Shared Infrastructure On GitHub.com, exploitation enabled RCE on shared storage nodes, which host data for millions of repositories. Researchers confirmed that the compromised system account had theoretical access to: private repositories proprietary codebases organizational metadata internal configuration data sensitive secrets and credentials 2. Full Server Compromise on GHES On GitHub Enterprise Server, the same flaw allowed complete server takeover, including access to all hosted repositories and internal secrets. 3. Extremely Easy to Exploit The exploit required: no special tools no elevated privileges only a standard Git client a single crafted git push command Researchers described it as “remarkably easy” to exploit. 4. Massive Exposure Window Even after GitHub patched the issue, 88% of GHES instances remained unpatched at the time of disclosure — leaving thousands of organizations exposed. This is one of the most severe architectural vulnerabilities ever discovered in GitHub, demonstrating how a single injection flaw in a shared platform can cascade into cross‑tenant exposure affecting millions of repositories globally. It also highlights a new era of AI‑assisted vulnerability discovery — this flaw was one of the first major RCEs in closed‑source binaries identified using AI‑augmented analysis.

🚨 Massive credentials leak happening on GitHub - please read before your next push Recently my GitHub account ran into restriction issues, so I started digging deeper into how my code and licenses were being used. While exploring, I stumbled onto something much more worrying. By searching for common secret names directly on GitHub (for example, API_KEY here: https://lnkd.in/g5AuMsUF ), I found an alarming number of exposed credentials across public repos: • Around 17.6 million matches just for API_KEY • Around 1.7 million matches for AWS_ACCESS_KEY_ID • Out of every 10 keys I checked manually, 1~3 were still valid and working This includes: • Cloud credentials (AWS, GCP, Azure) • Database URLs and passwords • JWT and auth secrets • SMTP and email credentials • Payment gateway keys (Stripe, Razorpay, etc.) • Even paid OpenAI API keys from active subscription accounts This is effectively a silent, continuous credential exposure happening in plain sight. Once a key is pushed: • Attackers and bots can find it within minutes • Deleting the file is not enough - it still exists in git history • Abuse can lead to huge cloud bills, data exfiltration, account takeover, and more 🛡️ What every developer should do right now • Always add .env, config, and secret files to .gitignore • Never hardcode secrets in code – use environment variables • Use secret managers (AWS Secrets Manager, Vault, Doppler, etc.) • Enable secret scanning on GitHub and your CI pipelines • If you ever leak a key: immediately rotate it and clean your git history I know some people may see this post, run those searches, and try to misuse exposed keys. I can’t control that. But as a developer, I’d rather raise awareness so more people secure their repos before damage happens. If you maintain any public or private repo, please take 5 minutes today to: • Check your .gitignore • Search your own codebase for things like API_KEY, SECRET, TOKEN, .env • Revoke and rotate anything suspicious Security is a shared responsibility. Let’s not make it easy for attackers. #DevSecurity #GitHub #OpenSource #APIKeys #Cybersecurity #WebDevelopment #100DaysOfCode #Python #JavaScript #DeveloperTips

A critical remote code execution vulnerability (CVE-2026-3854, CVSS 8.7) was recently disclosed in GitHub’s internal git infrastructure that could be exploited by any authenticated user with repository push access. The TTPs involved an injection flaw in the X-Stat header: attackers crafted git push options containing semicolons (;) to inject and override internal fields (such as rails_env, custom_hooks_dir, repo_pre_receive_hooks, and user_operator_mode on GitHub.com). This bypassed sandboxing and allowed execution of arbitrary code via pre-receive hooks using only a standard git client. Potential impact: - On GitHub Enterprise Server (GHES): Full server compromise, including access to all hosted repositories and internal secrets. - On GitHub.com: Remote code execution on shared storage nodes, with potential cross-tenant exposure to millions of public and private repositories. GitHub mitigated the issue on its cloud platform within hours and has released patches for all supported GHES versions (vulnerable ≤ 3.19.1; fixed in 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6, 3.19.3+). Self-hosted administrators should upgrade immediately. Full technical breakdown from Wiz Research: https://lnkd.in/eRThbsZJ #GitHub #RCE #Vulnerability #InfoSec #DevSecOps #AppSec #CVE20263854

A critical vulnerability hit GitHub this week. CVE-2026-3854. Authenticated users could run arbitrary commands on the backend with a single git push. GitHub.com was patched fast. 88% of self-hosted GitHub Enterprise instances are still vulnerable. Companies set up self-hosted infrastructure as a project. Install it. Configure it. Walk away. Then a year goes by. The patches stop getting applied. The team rotates. Nobody owns it. The thing keeps running because the people who built it left it stable. That works until it doesn't. The same shape shows up everywhere in small business automation. A VPS running n8n. A Docker container with a webhook handler somebody set up two years ago. A Zapier account with 40 zaps and three former employees as the email contacts. An audit catches the version drift, the credentials sitting in plain text, the workflow paused since March, the API key that should have been rotated. If you've got self-hosted anything in your stack and you haven't audited it this year, you're the 88%. #automation #cybersecurity #smallbusiness #infosec