curl and git: small tools, big security updates

Updated November 2026

curl and git look like simple command-line tools, but libcurl is loaded by many long-running services and git runs on every build server that clones code. Update both through your package manager, then restart services that use libcurl. Git needs no restart.

What they are and where they hide

curl is the command-line tool for transferring data over HTTP, FTP, SFTP and many other protocols. Its engine is the library libcurl, which other software links to: PHP’s curl extension, git’s HTTPS transport, package managers, monitoring agents and many language bindings. The curl project itself warns that libcurl is often embedded in applications without being obviously identified. Updating the curl command alone is not enough; the library package must be updated too, and programs that already loaded the old library keep using it.

git is the version control system. On servers it runs in deploy scripts, CI runners, Git hosting and configuration management. Many git vulnerabilities trigger when you clone or check out a repository someone else controls, which is exactly what build servers do all day.

Check the installed versions

curl --version | head -1
git --version

# Debian, Ubuntu
dpkg-query -W curl 'libcurl4*' git

# RHEL family, Fedora, SUSE
rpm -qa 'curl*' 'libcurl*' 'git*'

# Alpine
apk info -v | grep -E '^(curl|libcurl|git)-'

# FreeBSD
pkg info curl git

The first line of curl --version shows both the tool and the libcurl version it uses. Package names differ: recent Debian and Ubuntu releases call the library libcurl4t64, older ones libcurl4; on RHEL-family systems you may see curl-minimal and libcurl-minimal instead of curl and libcurl. As with any distribution package, a fixed CVE may be backported into an older upstream version, so compare against your distribution’s tracker, not the upstream release number (see backport). More on this in Check installed versions.

To find running processes that still have an old, deleted libcurl loaded after an update:

sudo lsof -n 2>/dev/null | grep DEL | grep libcurl

Upstream releases, as of November 2026

curl releases come roughly every six to ten weeks; the next one is planned for 2026-12-09. Neither project publishes end-of-life dates for old versions. Git usually ships a security fix for several older release series at once: the July 2025 fix for CVE-2025-48384 came out as 2.43.7, 2.44.4, 2.45.4, 2.46.4, 2.47.3, 2.48.2, 2.49.1 and 2.50.1. Recent curl advisories likewise list fixed patch versions on some older branches.

Distribution packages vs upstream

Use your distribution’s packages on servers. Stable distributions keep one curl and one git version for the life of a release and backport security fixes into it, which avoids surprises from new behavior. The git website notes that Red Hat Enterprise Linux and related distributions “typically ship older versions of git”; that is fine for security as long as you install the vendor updates.

If you need a newer git on Ubuntu, the git project’s download page points to the ppa:git-core/ppa PPA. A PPA or self-built version becomes your responsibility to keep updated. Building curl from source is rarely worth it on a server: you would also have to rebuild or relink everything that uses libcurl.

Update commands

# Debian, Ubuntu (all pending updates, including curl, libcurl and git)
sudo apt update
sudo apt upgrade

# RHEL, AlmaLinux, Rocky, Oracle Linux, Fedora
sudo dnf upgrade 'curl*' 'libcurl*' 'git*'

# SUSE, openSUSE
sudo zypper refresh
sudo zypper update curl 'libcurl*' 'git*'

# Alpine (as root)
apk -U upgrade

# FreeBSD (as root)
pkg update
pkg upgrade curl git

# Ubuntu with the git-core PPA
sudo add-apt-repository ppa:git-core/ppa
sudo apt update
sudo apt install git

For container images, update the base image and rebuild; running apt upgrade inside a running container is lost on the next deploy. See Containers.

What to restart

• curl command and git: nothing. Each run starts from the new files on disk.
• libcurl: restart every long-running service that loaded it, typically PHP-FPM or Apache with mod_php, monitoring agents and application servers. Find them with the lsof check above or a restart tool.

sudo needrestart -r l              # Debian, Ubuntu
sudo dnf needs-restarting -s       # RHEL family, Fedora
sudo zypper ps -s                  # SUSE

# example: restarts PHP-FPM (the unit name depends on your PHP version)
sudo systemctl restart php8.4-fpm

Test service configuration first where the service supports it (for example sudo php-fpm8.4 -t on Debian-style packages). See Restarts and reboots for details.

Verify

• curl --version and git --version show the updated package.
• The package versions match the fixed versions on your distribution’s tracker.
• The lsof check above prints nothing.
• CI runners, build images and deploy hosts have been updated too, not just web servers.

Notable recent vulnerabilities

If you cannot update at once, use a mitigation: the git advisory’s workaround for CVE-2025-48384 is to avoid recursive clones of submodules from untrusted repositories, and the curl advisory for CVE-2026-92392 suggests avoiding HTTP/2 (for example curl --http1.1). See also the vulnerability list.

Where advisories are published

• curl: the curl security page, which also offers the data as JSON and CSV. New advisories go to the curl-announce, curl-library and curl-users mailing lists with each release, and distributions get up to seven days’ notice through the distros list.
• git: git security advisories on GitHub and the release notes linked from git-scm.com. The git community page describes the main mailing list (git@vger.kernel.org) and the low-volume Git packagers list.
• Your distribution’s security notices and trackers. See Security advisories.

Safe-use tips

• Never use curl -k (--insecure) in scripts; fix the certificate or CA bundle instead.
• In scripts that follow redirects, limit protocols: curl --proto =https --proto-redir =https -fL ….
• Do not pipe downloads straight into a shell. Download, check the checksum or signature, then run.
• Keep passwords and tokens off the command line, where other users can see them in the process list; use a .netrc file or a git credential helper, and never put tokens in remote URLs.
• Do not clone untrusted repositories with --recurse-submodules, and do not run git as root inside repositories owned by other users.
• Set git config --global transfer.fsckObjects true on build and deploy hosts so received objects are checked.
• Make sure your web server never serves .git directories from a deployed site.

Sources

• curl security vulnerabilities, curl project
• curl releases, curl project
• Vulnerabilities in curl 8.22.0, curl project
• CVE-2026-92392: HTTP/2 upload use-after-free, curl project
• curl vulnerability disclosure policy, curl project
• Git home page and latest release, Git project
• Install Git on Linux, Git project
• Git community and mailing lists, Git project
• Git security advisories, Git project
• CVE-2025-48384 advisory, Git project