Repository navigation
gl: uncapped success-body reads let a malicious node exhaust client memory #473
Description
Activity
- added and removed
on Sep 26, 2026 Recalibrating to sev:medium. Reaching these sinks requires the operator to point gl or the remote helper at a hostile node (the plaintext-remote path is tracked separately in #413). That precondition puts it in the same band as #418 rather than the anonymously-triggerable issues. The remediation is unaffected; success bodies still need the cap.
Summary
Body caps (
read_body_capped, the codebase's INV-6 "reads must be bounded") are applied only on error paths (peer.rs, sync.rs, whoami.rs). Success bodies are buffered to completion with no cap:crates/git-remote-gitlawb/src/main.rs:257(info/refs),:569(each pack negotiation round),crates/gl/src/clone.rs:327(resp.json()),:377(per-envelope bytes),crates/gl/src/mcp.rs:796.Impact
A hostile node answering a fetch, clone, or MCP call with an oversized 200 body causes full buffering and client memory exhaustion on the most basic operations. A MITM on a plaintext
GITLAWB_NODEreaches the same sinks (see #413/#443 for the scheme gap).Remediation
read_body_capped(or streaming with a hard cap) to success bodies on the refs, pack, clone, and MCP paths.Proposed labels: kind:security, crate:gl, crate:git-remote.