GitHub is investigating unauthorized access to their internal repositories

Perceived causes and role of AI

• Several commenters note a surge in security incidents in the last months and link it to more capable LLMs.
• Many argue attackers are now heavily using LLMs to find vulnerabilities and build exploits; some say this is effectively universal among serious exploit developers.
• Others stress the “defender” side: AI‑generated “slop PRs” and management pressure for speed are degrading code quality and reviews, likely adding new vulnerabilities.

Attack vector and scope (as discussed)

• Thread consensus: a Microsoft developer installed a malicious VS Code extension from the official marketplace; malware exfiltrated credentials, which were then used to clone internal GitHub repos.
• GitHub states ~3,800 internal repositories were accessed; posters debate how “directionally consistent” and how bad that is.
• Ransom group reportedly claims to have copied and is selling all internal repos; some mention file listings that include law-enforcement portals and abuse‑related tooling.
• Whether any customer data or customer repos are impacted remains described as unknown / “no evidence so far.”

Source access in the LLM era

• Multiple comments note that leaked source was already dangerous pre‑AI, but LLMs now make large‑scale code review and vuln‑hunting easier.
• Some assume GitHub likely already scans its own code with AI tools, but others are skeptical that this meaningfully reduces risk.

Developer access and internal repo sprawl

• Many companies give developers read access to all internal code (“inner source”) to boost productivity and understanding; some see that as normal and necessary.
• Others question why one developer’s credentials allowed access to thousands of repos and view this as a failure of least‑privilege design.
• There’s debate over how to balance fast development with tighter access controls and JIT permissions.

VS Code extensions and permission models

• Strong criticism that VS Code extensions, especially “themes,” have broad, unsandboxed capabilities and no robust permission model.
• Some call for extension sandboxing, explicit permissions (especially for themes), running IDEs in containers/VMs, and restricting outbound network access.
• Others note that as long as an IDE can reach git and hold SSH/tokens, compromised extensions can do damage.

GitHub Actions and supply‑chain hardening

• Multiple practical tips: use security linters (e.g., zizmor for GitHub Actions), delay package adoption, firewall npm installs in CI, disable auto‑updates for IDE/AI extensions.
• Template injection in GitHub Actions (e.g., PR titles flowing into shell) is cited as a known class of exploit.

Communication channel criticism

• Many dislike that the only initial disclosure was on X/Twitter, which now often requires login and is blocked in some enterprises.
• Suggestions include: status page and blog posts on github.com, direct email to org owners, and mirroring to more open platforms (e.g., Bluesky, RSS).

Reactions: trust, cloud skepticism, and alternatives

• Some say this is another in a string of Microsoft/GitHub issues and plan to leave; others argue GitHub remains the “least bad” hosted forge.
• Interest in self‑hosting (Forgejo, Gitea) is high; proponents cite lower cost, smaller attack surface, and more control over dependencies and infra.
• A few advocate generally moving off centralized SaaS/cloud for critical dev infrastructure, given growing supply‑chain and ecosystem risks.