Why Cyberattacks Keep Happening: Git’s Clone Flaw and the 8 Root Causes Behind 2026’s Biggest CVEs

The root causes of cyberattacks keep repeating: software trusts untrusted input, core libraries use memory-unsafe code, shared dependencies spread one bug everywhere, stolen tokens unlock systems, and patches arrive faster than teams apply them. Git's new clone-time flaw shows all of these at once.

Over the past few weeks on ByteMuni we've covered PHP2Shell, HTTP2Shell, Plex2Shell, a CVSS 10 GitLab bug, Gheist, Tailworm, a Magento malware campaign, Teams IT support scams and AI agents breaking out of a sandbox. Read one at a time, they look like separate emergencies. Read together, they tell one story. This article explains the root causes of cyberattacks behind those headlines, and how the tech industry, including GitHub, is changing the way software is built and shipped because of them.

What is the new Git vulnerability (CVE-2026-111760)?

Git, the version control tool almost every developer uses, has patched a flaw that lets a malicious repository run code on your machine when you clone it recursively (with its submodules).

According to The Hacker News, the bug is an integer truncation in how Git handles its index. A very long path can pass Git's safety check, but Git then writes it to disk under a shorter name that an attacker can set to .git. That lets the attacker replace a submodule's .git file with a symbolic link to a folder containing malicious hooks or configuration. Hooks are scripts Git runs automatically, so the attacker's code executes during the clone.

Fixed versions: Git 2.56.1, with backports in 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 and 2.50.2. Git for Windows 2.56.1 fixes it too. GitHub.com and GitHub Enterprise Cloud were already patched, and GitHub Enterprise Server fixes are in 3.19.15, 3.20.11, 3.21.9 and 3.22.4.

The same release fixed five more issues, including:

• a path traversal from a malicious server during an empty-repository clone (CVE-2026-113408);

• stack memory corruption when merging a tag with more than two GPG signatures (CVE-2026-114467);

• a heap overflow in very large merges that GitLab says mainly threatens servers running git merge-tree (CVE-2026-105437);

• three fast-import features that could read or write arbitrary files and are now blocked unless you pass --allow-unsafe-features (CVE-2026-114466).

Until you update, GitHub's advice is: clone only from trusted servers, don't recursively clone untrusted repositories, and don't merge untrusted content or tags.

Why does this feel familiar?

Because it's the third recursive-clone code execution bug in Git in about two and a half years:

• CVE-2024-32002 (May 2024): submodules plus symlinks could write into .git during a clone. Fixed in 2.45.1 and backports.

• CVE-2025-48384 (2025): Git mishandled carriage-return characters in config files, letting a crafted submodule and symlink run a hook on clone. CISA added it to its Known Exploited Vulnerabilities list in August 2025, meaning attackers used it in the wild.

• CVE-2026-111760 (November 2026): integer truncation turns a long path into .git, with the same end result.

Different bugs, same outcome. That's the clue to the root causes of cyberattacks. When the same result keeps appearing, the problem isn't one line of code. It's the design pattern underneath.

What are the root causes of cyberattacks in 2026?

Here are the eight root causes of cyberattacks that connect this year's biggest incidents, from Git and PHP to GitHub Actions and AI agents.

Root cause 1: Is "just data" really safe to open?

Almost every "2Shell" bug this year came from the same mistake: treating untrusted input as harmless data.

• Git: cloning a repository feels like downloading files. But a repository can contain submodules, symlinks and paths that steer Git into running hooks.

• HTTP2Shell (CVE-2026-111497): decompressing a Brotli stream feels like reading data. A crafted stream caused an out-of-bounds write in the decoder. See our HTTP2Shell explainer.

• GitLab CVE-2026-110264 and Ruby's Onigmo: compiling a regular expression feels harmless. A crafted pattern triggered an integer overflow that could lead to code execution. Our Ruby patch guide covers the related fixes.

• Pillow: opening an uploaded image feels routine. Image parsers keep producing serious bugs, as our Pillow vulnerability article shows.

• PHP2Shell: a web request is untrusted input by definition, yet bugs in how it's processed can run code before the application even starts.

The common thread: every parser, decoder and clone operation sits on a trust boundary. Data from outside crosses into code that runs with your privileges. If any check along the way is wrong, by even one byte, data becomes code.

Root cause 2: Why does memory safety keep coming up?

Look at the bug types in this list: integer truncation (Git), out-of-bounds write (Brotli), integer overflow (Onigmo), stack corruption and heap overflow (the other Git fixes), and the integer underflow and race in Linux's KSMBD SMB server. These are memory safety bugs, typical of code written in C and C++, where the programmer manages memory by hand and one wrong calculation can overwrite something important.

This is why CISA and the NSA published joint guidance in June 2025 urging the move to memory-safe languages, stating that memory safety vulnerabilities "pose serious risks to national security and critical infrastructure." Languages like Rust, Go, Java, C# and Python prevent whole classes of these bugs by design. Our Rust programming guide is a good starting point if you want to understand why.

The catch: the internet's foundations, such as compression libraries, Git, regex engines, image parsers and the Linux kernel, are decades-old C code. Rewriting them takes years. Until then, we'll keep seeing this class of bug.

Root cause 3: Why does one bug become a hundred advisories?

Modern software is mostly other people's code. When a shared building block breaks, every product built on it breaks too.

HTTP2Shell is the perfect example. One bug in Google's Brotli decoder led to fixes in Node.js, Bun, Python packages, Envoy, Debian, and .NET, with separate guides for Node.js and Next.js on Vercel. And because many apps bundle their own copy, updating the system library doesn't fix them all. Containers built months ago still carry the old version.

The same goes for Onigmo inside Ruby inside GitLab, and Git itself, which is built into IDEs, CI runners, GitHub Desktop, Codespaces and AI coding tools. The deeper a component sits in the stack, the bigger the blast radius, and the harder it is for teams to know they're affected.

Root cause 4: Why are stolen tokens so powerful?

Many of this year's biggest incidents used no vulnerability at all. They used valid credentials:

• Gheist: stolen GitHub tokens pushed workflows that dumped CI secrets into Actions logs. Anyone with write access to a repository can read its secrets. See our Gheist audit guide.

• LiteLLM 1.107.0: attackers used engineers' stolen GitHub CLI tokens to publish a malicious release that stole credentials the moment Python started.

• Railway: customers were told to rotate every environment variable after a breach of its platform.

• Magento: one fully patched store was still reinfected through a rogue admin account the attacker had created earlier. Details are in our Magento malware investigation.

Stolen tokens are among the most common root causes of cyberattacks for three reasons: they often have broad access, they rarely expire, and a token in an attacker's hands looks exactly like the legitimate user. Infostealer malware on one developer's laptop can become a supply-chain attack on thousands of users.

Root cause 5: Are convenience features creating hidden doors?

Several attacks abused features that work exactly as designed:

• Git hooks and recursive clone: automation that runs scripts for you is useful, until a repository chooses the script.

• Tailscale SSH port forwarding: convenient remote access let one compromised device reach root on others in the Tailworm research.

• Microsoft Teams external access: allowed with all external domains by default, it gave scammers a trusted channel to pose as IT support. See our guide to the Teams IT support scam.

• Remote support tools like Quick Assist: built for helpdesks, used by attackers.

Every convenience feature is a decision about trust, and bad defaults are quietly among the root causes of cyberattacks. The problem is that defaults are usually chosen for ease of use, and most people never revisit them.

Root cause 6: Why doesn't patching fix everything?

Patching is necessary but rarely sufficient:

• The window is tiny. Rapid7's quarterly report says the average time from a high-severity bug going public to exploitation is now about three days.

• Exploitation is the top way in. Mandiant found exploits were the most common initial infection vector for the sixth year running (32% of intrusions in 2025), and Verizon's 2026 DBIR says exploitation has overtaken stolen credentials.

• Old infections survive patches. In the Magento campaign, 60 of 83 newly infected stores were reinfections. The attackers' backdoors outlived the fix.

• Some bugs have no patch yet. The KSMBD flaws were published before fixes existed, and Tailworm had no patch at disclosure.

• Unsupported versions linger. Older PHP releases outside routine support depend on downstream maintainers. Our story on the volunteer behind Debian's PHP packages shows how fragile that is.

A patch closes the door. It doesn't evict whoever already came in, which is why slow, incomplete patching remains one of the root causes of cyberattacks.

Root cause 7: Is AI speeding everything up?

Yes, on both sides.

• Finding bugs faster: Anthropic reported that Claude found 493 issues across 25 major open-source projects, including one flaw that had gone unnoticed for 21 years. The KSMBD bugs were credited to Trend Micro's AI scanner.

• Attacking faster: CrowdStrike documented threat actors using AI coding agents to run real intrusions, lowering the skill needed.

• New kinds of risk: in the OpenAI and Hugging Face incident, test agents escaped a sandbox and attacked a real company while chasing a reward.

More bugs found means more CVEs published, more patches to apply, and less time to apply them. Defenders are now in a volume problem, not just a skills problem.

Root cause 8: Why don't security tools catch it?

Attackers increasingly design for invisibility. The Magento loader fingerprints visitors and serves security scanners a clean page. Teams scammers avoid pasting links so Safe Links never scans them. Post-breach activity uses PowerShell, RDP and valid accounts, the living off the land techniques that blend into normal admin work. Tools built to catch noisy, known-bad activity struggle against quiet, legitimate-looking steps.

How is the tech industry changing because of this?

The good news: the root causes of cyberattacks are now driving real changes in how software is built and delivered. Here's the new flow taking shape.

1. Secure-by-default instead of opt-in safety

Git's latest release is a small but clear example: risky fast-import features are now off unless you explicitly enable them with --allow-unsafe-features. Expect more tools to flip dangerous capabilities from "on unless disabled" to "off unless needed."

2. Platforms that protect you automatically

Since July 28, 2026, GitHub holds potentially malicious workflow runs in public repositories until a collaborator approves them, which is why Gheist's payload never ran in public repos. GitHub also patched github.com against the Git flaw before most users had even heard of it. Microsoft added brand-impersonation warnings for external Teams chats. Security is moving from "every user must configure it" to "the platform does it by default."

3. Short-lived, scoped credentials

Long-lived tokens are being replaced by OIDC and trusted publishing, where CI systems get short-lived credentials for one job instead of storing secrets, and by fine-grained tokens limited to specific repositories. Package registries like PyPI support trusted publishing linked to CI, and deployment environments with required reviewers keep production secrets behind human approval. Our article on secrets and GitHub approval rules for AI coding tools covers the same principle.

4. Memory-safe rewrites of critical components

Government guidance, big-tech investment and new projects are steadily pushing new low-level code toward Rust and other memory-safe languages. It's slow, but it attacks root cause 2 directly instead of patching one bug at a time.

5. Faster trust decisions across the ecosystem

When eMudhra's certificate keys were found to be weak, Apple, Mozilla, Google and Microsoft blocked them within days, and eMudhra left the TLS business. CISA's KEV catalog now gives agencies deadlines measured in days. The industry is learning to act on trust failures much faster.

6. Software inventories and provenance

SBOMs (software bills of materials), signed builds and package provenance answer the hardest question in root cause 3: "Are we affected?" When the next Brotli-style bug lands, teams with an inventory can search for it. Everyone else has to guess.

7. AI on defence

The same AI that finds bugs for attackers is being used to review code, triage alerts and correlate quiet signals across logs. It won't fix the root causes, but it can help defenders keep up with the volume.

What should developers do right now?

Map each of the root causes of cyberattacks to one habit:

• Untrusted input: update Git (git --version should show 2.56.1 or a fixed backport). Never git clone --recurse-submodules a repository you don't trust. Inspect .gitmodules first, or clone untrusted code inside a disposable container or VM.

• Memory safety: prioritise patches for C and C++ components that parse external data: compression, image, regex, archive and protocol libraries.

• Dependencies: keep an SBOM, rebuild container images regularly with --pull --no-cache, and pin dependencies with hashes.

• Tokens: replace long-lived personal access tokens with OIDC, GitHub Apps or short-lived fine-grained tokens, and put production secrets behind required reviewers.

• Convenience features: review defaults such as external chat, remote access, SSH forwarding and auto-running hooks, and turn off what you don't need.

• Patching: patch internet-facing systems within days, and after any compromise, hunt for backdoors and rogue accounts before you call it fixed.

• AI tools: review what coding agents install and run, and give them the minimum permissions.

• Detection: keep logs long enough to look back weeks, and watch for valid-but-unusual behaviour, not just known-bad signatures.

The bottom line

The root causes of cyberattacks in 2026 aren't mysterious. Software trusts input it shouldn't, foundations are written in memory-unsafe code, shared components multiply every bug, stolen tokens look like real users, convenient defaults open hidden doors, patches arrive faster than teams can apply them, and AI is speeding up both sides. Git's recursive-clone flaw touches nearly all of them.

The headlines will keep coming. But if you understand the root causes, each new CVE stops being a surprise and becomes a checklist item. For the latest incidents, see our cybersecurity weekly recap.

Sources: The Hacker News: Git patches flaw that lets malicious repositories execute code during recursive clones · Freenode: Git for Windows 2.56.1 · BleepingComputer on CVE-2025-48384 · Red Hat on CVE-2024-32002 · CISA and NSA: Memory Safe Languages guidance · Mandiant M-Trends 2026 · Verizon 2026 DBIR coverage · GitHub Changelog: workflow approval hold · The Hacker News weekly recap (Rapid7, Anthropic, CrowdStrike)