Breaking Git with a carriage return and cloning RCE

Patch status and distribution lag

  • Users report needing Git 2.50.1, with some package managers (Homebrew, Arch, Debian, Apple’s bundled Git) initially lagging behind the upstream security release.
  • Homebrew and Arch eventually ship 2.50.1, but people note that many systems will remain vulnerable for some time.
  • There is confusion over timing: tags/commits date from weeks earlier, but the public advisory is very recent. Clarification: tag dates reflect when commits were authored, not when the release/advisory became public.
  • Some complain the blog post doesn’t clearly signal whether this is “urgent now” versus an already-widely-patched issue.

Threat model and practical impact

  • The exploit lets a crafted repo write into a submodule’s .git/hooks and trigger a hook during clone, achieving RCE before the user can inspect code.
  • Discussion emphasizes that this mainly matters for supply-chain scenarios: cloning repositories (often with submodules) where you don’t intend to execute arbitrary code.
  • Some downplay risk, arguing Git’s purpose is to get and run code, and that attacks usually also require transport compromise or a malicious PR.
  • Others argue it still undermines integrity checks and is relevant beyond GitHub, since not all Git use is GitHub-centered and submodules can point anywhere.

Config parsing, CR/LF, and filenames

  • Root cause: mismatch between how Git writes config values (not correctly quoting trailing \r) and how it later reads them (stripping trailing CR/LF), leading to submodule paths being interpreted differently.
  • Several comments generalize this to “encoder/decoder mismatch” and pitfalls of ad‑hoc config formats and hand-written parsers.
  • Others note that this is a pure logic bug that could have appeared even in a standard library and that submodules are a historically fragile bolt‑on.
  • Broader discussion covers CR/LF handling, whitespace semantics, and the long-standing pain of control characters in filenames; one thread advocates banning control chars (or using a kernel “safename” module), another prefers sandboxing Git instead.

Language choice and safety debates

  • One camp insists this is not fundamentally about C; any language can have such logic bugs, especially around parsers and quoting.
  • Another camp counters that “data-safe” languages and established libraries (TOML/JSON/etc.) make these bugs less likely, even if not impossible.
  • Several note that in Rust or similar languages, you could reproduce the same logic error entirely in safe code; fuzzing and round‑trip tests are suggested as key mitigations.

Git design and hardening ideas

  • Some criticize Git for running submodule hooks during clone at all; others respond that hooks and custom subcommands are essential features and inherently involve subprocesses.
  • Proposed mitigations include Landlock/seccomp, OpenBSD-style pledge/unveil, user namespaces, and running git clone in a sandbox, but there’s concern about breaking hooks and plugin workflows.