Git Security Update: Why Your CI Runners Need Patching Too

Six Git vulnerabilities affect operations including recursive clones and binary patches. Inventory local, bundled and automated installations.

José Palanco José Palanco
Last Updated:
1 min read
Share
Git Security Update: Why Your CI Runners Need Patching Too

Beyond ASPM

Proof-Driven AppSec for teams building with AI

Plexicus uses AI Swarm Pentest to explore authorized application paths, validate what is exploitable, and give teams evidence they can use to prioritize remediation.

Explore AI Swarm Pentest

On November 10, the Git project released fixes for six vulnerabilities. One can allow code execution when a malicious repository is cloned recursively. The affected component is Git itself, so the inventory must include developer machines, CI runners and applications that bundle their own Git.

What the release fixes

GitHub’s announcement identifies CVE-2026-111760 in recursive clones and CVE-2026-113408 in a server’s advertised HEAD. The other issues affect signed-tag merges, binary patches, large merges and fast-import streams. Their consequences differ: do not assume that every issue allows remote code execution.

Install Git 2.56.1 or the patched release for your maintenance series: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 or 2.50.2. Check your distributor’s advisory and any backports; update applications with bundled Git as well.

A practical response

  1. Inventory Git versions on workstations, build images, CI runners and services that process repositories.
  2. Patch using the trusted distributor for each environment, rebuild images and verify the version actually running.
  3. Until patched, avoid recursive clones from untrusted repositories and untrusted merges, binary patches and fast-import streams. These precautions do not replace the update.
  4. Record ownership and track remediation; a repository scan alone does not establish the Git version used by a runner.

Where Plexicus fits

Plexicus remediation helps teams follow up on validated application-security findings. This release also needs an infrastructure patching workflow: do not assume an application scan updates Git installations.

Thumbnail: Git logo by Jason Long, CC BY 3.0; unmodified original logo composited over an editorial background.

Written by
José Palanco
José Palanco
José Ramón Palanco is the CEO/CTO of Plexicus, a pioneering company in ASPM (Application Security Posture Management) launched in 2024, offering AI-powered remediation capabilities. Previously, he founded Dinoflux in 2014, a Threat Intelligence startup that was acquired by Telefonica, and has been working with 11paths since 2018. His experience includes roles at Ericsson`s R&D department and Optenet (Allot). He holds a Telecommunications Engineering degree from the University of Alcala de Henares and a Master`s in IT Governance from the University of Deusto. As a recognized cybersecurity expert, he has been a speaker at various prestigious conferences including OWASP, ROOTEDCON, ROOTCON, MALCON, and FAQin. His contributions to the cybersecurity field include multiple CVE publications and the development of various open source tools such as nmap-scada, ProtocolDetector, escan, pma, EKanalyzer, SCADA IDS, and more.
Read More from José
More to read

Related posts

Ready to validate what matters?

Ready to validate what matters?

Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorized target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)
Private Round For investors