The libcurl You Patched Is Not Always the One You Shipped
A CI runner passes its vulnerability scan on Monday. On Friday, somebody discovers that the image contains three copies of libcurl: one installed by the package manager, one bundled with a language runtime, and one copied from an earlier build stage. Only the first appeared in the package report.
This is not an exotic edge case. curl is everywhere because it is useful, small, and usually installed without much thought. It appears in application containers, deployment tools, health-check images, Kubernetes jobs, and self-hosted CI runners. libcurl is quieter. Applications link to it, vendors bundle it, and build systems leave copies behind.
The argument here is simple: patch management based on the visible curl command is incomplete. You need to know what was shipped, what is loaded, and whether the affected code can actually be reached.
The command tells you less than you think
Start with the obvious check, but do not stop there:
curl --version
ldconfig -p 2>/dev/null | grep libcurl || true
find / -type f \( -name 'libcurl.so*' -o -name 'libcurl*.dll' \
-o -name 'libcurl*.dylib' \) 2>/dev/nullcurl --version describes the command being executed. It does not prove that an application is using the same library. A Python wheel, vendor agent, static binary, or copied application directory may contain another libcurl entirely.
Package queries help, provided the image still has a package database:
# Debian and Ubuntu
dpkg-query -W 'curl' 'libcurl*' 2>/dev/null
# RHEL, Rocky, AlmaLinux, Fedora
rpm -qa 'curl*' 'libcurl*'
# Alpine
apk info -vv | grep -E '^(curl|libcurl)-'Do not compare only the upstream version string. Linux distributions often backport a security fix without changing to the upstream release that first contained it. Check the distro advisory and package revision before declaring a vulnerability open or fixed.
Current curl advisories show why the distinction matters. The June 2026 release addressed flaws affecting different combinations of the command-line tool and libcurl, including authentication state leaks, connection reuse errors, memory handling bugs, and SSH verification behavior. The upstream curl vulnerability table maps affected releases, while the individual advisories state whether the tool, the library, or both are involved. Blanket statements such as "curl is vulnerable" are not useful enough for an incident decision.
Scan the artifact, not the Dockerfile
A Dockerfile is a recipe, not evidence of what reached production. Multi-stage builds, inherited base images, cached layers, and downloaded binaries all create room for surprises.
Generate an SBOM from the built image digest:
IMAGE='registry.example.com/platform/ci-runner@sha256:REPLACE_ME'
syft "$IMAGE" -o cyclonedx-json > sbom.cdx.json
syft "$IMAGE" -o table | grep -Ei 'curl|libcurl'
trivy image --scanners vuln --ignore-unfixed=false "$IMAGE"
grype "$IMAGE"Pinning the digest matters. Scanning runner:latest while production uses last Tuesday's digest is security theatre with nicer output.
SBOM tools inspect package metadata and file signatures differently, so disagreement is useful. Investigate it. For statically linked binaries, package scanning alone may miss the embedded library. Syft can identify some binaries through catalogers, but a high-value image deserves another pass with file inspection, build provenance, and application dependency data.
Then ask whether the code is reachable. A libcurl vulnerability involving SMTP authentication has a different exposure profile from one triggered by ordinary HTTPS requests. Features compiled into the library also matter. Record the output of curl --version, which includes supported protocols and linked libraries, and compare the CVE preconditions with how the image is used.
A disclosed curl CVE is not automatically a zero-day, nor is every scanner finding an exploitable path. Conversely, a low-severity library finding should not sit forever in a privileged CI runner that holds registry credentials and can reach production. Context changes the decision.
The security appliance now needs incident handling
CVE-2026-25089 is a useful, uncomfortable comparison. It is not a curl flaw. It affects Fortinet FortiSandbox, FortiSandbox Cloud, and FortiSandbox PaaS, systems commonly placed in trusted security workflows to inspect suspicious files and zero-day threats.
The vulnerability allows an unauthenticated attacker to send specially crafted HTTP requests to the web interface and cause operating system commands to run. No valid account or user click is required. Fortinet rates it critical and describes the affected component and fixed releases in FG-IR-26-141.
Organizations running affected FortiSandbox versions are at risk, especially where the management or web interface is reachable from the internet or an untrusted network. A successful exploit means the attacker can execute unauthorized commands on a security appliance. In business terms, that can expose information available to the appliance, alter its operation, interrupt analysis, and provide a foothold with whatever network access the appliance already has.
CISA added CVE-2026-25089 to the Known Exploited Vulnerabilities catalog on 16 July 2026. CISA also records known ransomware campaign use. That moves this from routine patch scheduling into active incident territory. It does not prove every exposed appliance is compromised, but treating it as a normal monthly update is a poor bet.
Check exposure without firing the exploit
First, identify every FortiSandbox appliance, cloud tenant, and PaaS instance. Compare configuration management records with DNS, firewall objects, cloud load balancers, NAT rules, and external attack-surface results. Security products are often missing from ordinary application inventories because another team owns them.
Affected releases include FortiSandbox 5.0.0 through 5.0.5 and 4.4.0 through 4.4.8, plus affected 4.2 releases. FortiSandbox Cloud and PaaS 5.0.4 through 5.0.5 are also affected. Fortinet directs customers to 5.0.6 or later, or 4.4.9 or later where applicable. Use the vendor's supported upgrade path for older branches.
Restrict the interface immediately to known administrative networks or a VPN. Do not mistake that for the final fix. Review HTTP access logs for unusual requests to the web interface, particularly malformed or unexpected JSON input. Look for processes spawned by the web service, new files, changed accounts, persistence, and outbound connections the appliance does not normally make. Preserve relevant logs and evidence before they roll over.
Because exploitation is confirmed and ransomware use is known, patching alone is not enough for an exposed vulnerable system. Follow CISA's BOD 26-04 risk-based update guidance and its forensics triage requirements. Federal organizations have binding obligations. Everyone else should still use the same sequence: reduce exposure, preserve evidence, hunt for compromise, apply Fortinet's mitigation or update, validate the result, and continue monitoring. If a cloud mitigation is unavailable, follow the applicable guidance or discontinue use rather than leaving the service exposed.
This is where offensive testing, threat detection, incident response, and hardening meet. A version check answers only one question. You also need to know whether attackers could reach the component and whether they already did.
If you only do one thing this week
Scan your production and CI image digests with an SBOM tool, then reconcile every curl and libcurl result against runtime files and the upstream or distro advisory. While that inventory runs, treat any internet-exposed FortiSandbox affected by CVE-2026-25089 as a potential incident, not a maintenance ticket.
The unglamorous work is finding the copy nobody remembered. That is usually where the exposure lives.
If this is on your plate, TecLeads does exactly this as part of our Cybersecurity work. If you'd like a second pair of eyes on your setup, book a 30-minute call or explore what we do.