April 8, 2026 eBuilder signs an agreement for MDR/SOC with a hotel business.

March 13, 2026 eBuilder signs an agreement for SOC-operations with a Swedish municipality.

March 2, 2026 A communications/branding agency chooses eBuilders Complorer for cybersecurity training

March 2, 2026 Large international steel company chooses eBuilder as supplier for Penetration testing

March 2, 2026 Large international steel company chooses eBuilders Complorer for cybersecurity training

February 13, 2026 eBuilder Security signs an agreement for continuous pen testing with a Swedish AI-company

February 11, 2026 eBuilder Security sells Complorer Security Awareness training to a Swedish unemployment insurance fund

January 30, 2026 eBuilder sigs an agreement with a Swedish municipality for MDR/SOC.

April 8, 2026 eBuilder signs an agreement for MDR/SOC with a hotel business.

March 13, 2026 eBuilder signs an agreement for SOC-operations with a Swedish municipality.

March 2, 2026 A communications/branding agency chooses eBuilders Complorer for cybersecurity training

March 2, 2026 Large international steel company chooses eBuilder as supplier for Penetration testing

March 2, 2026 Large international steel company chooses eBuilders Complorer for cybersecurity training

February 13, 2026 eBuilder Security signs an agreement for continuous pen testing with a Swedish AI-company

February 11, 2026 eBuilder Security sells Complorer Security Awareness training to a Swedish unemployment insurance fund

January 30, 2026 eBuilder sigs an agreement with a Swedish municipality for MDR/SOC.

Company News

Vulnerabilities

Single Git Push Could Have Compromised Millions of GitHub Repositories

April 30, 2026 / 4 Min Read

Single Git Push Could Have Compromised Millions of GitHub Repositories

A command injection flaw in GitHub’s git push pipeline could have allowed attackers to execute arbitrary code on GitHub servers and access millions of repositories with a single malicious command. Wiz researchers discovered CVE-2026-3854 on 4 March 2026 and reported it through GitHub’s Bug Bounty programme. GitHub patched GitHub.com within two hours but nearly two months later, 88% of GitHub Enterprise Server instances remain vulnerable according to Wiz data.

The vulnerability affects GitHub.com, GitHub Enterprise Cloud and GitHub Enterprise Server versions. It carries a CVSS score of 8.7 and requires only push access to any repository including one an attacker creates themselves. No zero-days, no complex malware. Just a standard git client and a crafted push option containing a semicolon.

How a Semicolon Bypassed GitHub’s Security

The flaw sits in GitHub’s internal X-Stat header, a semicolon-delimited metadata format that passes security-critical configuration between backend services during git operations. When a user pushes code, their git push options were embedded directly into this internal protocol without proper sanitisation.

Wiz researcher Sagi Tzadik demonstrated that an attacker could inject additional fields into the X-Stat header by including a semicolon in their push options. This allowed them to override critical security settings including forcing GitHub’s git hooks to run in an unsafe “enterprise mode” that bypasses sandboxing protections.

On GitHub Enterprise Server, successful exploitation granted full control over the instance. “With unsandboxed code execution as the git user, we had full control over the GHES instance including filesystem read/write access and visibility into internal service configuration,” Tzadik said in Wiz’s technical disclosure.

The impact on GitHub.com was worse. GitHub’s multi-tenant architecture means that code execution on shared storage nodes provided access to millions of repositories belonging to other organizations and users. Wiz confirmed they could read repository index entries across the shared infrastructure which is exactly the kind of cross-tenant breach that cloud providers are designed to prevent.

Most Enterprise Servers Remain Exposed

GitHub released patches for Enterprise Server versions 3.14 through 3.20 on 10 March 2026. The company conducted a forensic investigation and confirmed that CVE-2026-3854 was never exploited beyond Wiz’s own testing. GitHub CISO Alexis Wales said “no customer data was accessed, modified or exfiltrated as a result of this vulnerability.”

That clean record matters less than the deployment figures. Wiz’s scan data shows 88% of Enterprise Server instances have not applied the patch, leaving them vulnerable to a flaw that requires minimal technical skill to exploit. GitHub’s advisory warns administrators to review audit logs at /var/log/github-audit.log for push operations containing semicolons in push options which would indicate attempted exploitation.

The patching delay suggests many organisations either missed the severity of this vulnerability or lack the deployment processes to respond quickly to critical fixes. CVE-2026-3854 earned one of the highest rewards in GitHub’s Bug Bounty programme history, a signal that the company considered it genuinely serious.

AI Found This Flaw in Closed-Source Code

Wiz used automated reverse engineering through IDA MCP to analyse GitHub’s compiled binaries and reconstruct internal protocols. The team identified where user input could influence server behaviour across GitHub’s multi-service pipeline, work that would have been impractical through manual analysis alone.

This represents a shift in vulnerability discovery. Finding critical flaws in closed-source enterprise software typically requires either source code access or extensive manual reverse engineering. AI-assisted tooling is making that analysis practical for security researchers which means more critical vulnerabilities in enterprise platforms are likely to surface.

The GitHub disclosure timeline reflects how seriously both companies treated the finding. Wiz reported the vulnerability at 14:00 UTC on 4 March. GitHub confirmed the issue by 14:40 and deployed a fix to GitHub.com by 15:15 the same day. That 75-minute response is exceptional for a vulnerability of this complexity.

Patch Now or Restrict Access

Organizations running GitHub Enterprise Server should upgrade to the latest patch release immediately. The vulnerability affects all versions from 3.14 onwards and GitHub has released fixes for supported versions. Version 3.19.3 was temporarily unpublished for operational reasons so administrators should use the most recent available patch release for their version.

If immediate patching is not possible, restrict network access to Enterprise Server instances and disable user repository creation until patches can be applied. The vulnerability requires push access to trigger so removing that capability for non-essential users provides temporary protection.

Check audit logs for any push operations containing semicolons in push options since early March. Wiz has published an open-source indicators-of-compromise scanner that checks for signs of exploitation related to CVE-2026-3854. Run it before and after patching to confirm your instance was not compromised.

References

This post is also available in: Svenska

This site is registered on wpml.org as a development site. Switch to a production site key to remove this banner.