Live › vulnerability › CVE-2026-87863
Go to dashboardAn HTTPS server the client has already authenticated to can send an HSTS max-age so large that curl's time serialization fails when saving the HSTS cache. curl then truncates the cache file and deletes the replacement, leaving the HSTS cache empty or partial while still reporting success.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Teams whose scripts or services run curl with HSTS caching enabled against HTTPS origins they already authenticate to. The sources say the risk is data loss in the HSTS cache, not code execution, so systems that do not use an HSTS cache file are unlikely to be affected.
No product ranges from the sources yet.
curl --version and compare the curl version against the fixed release in the advisory.--hsts or the default curl HSTS cache location on the host.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
An authenticated HTTPS origin can supply an HSTS max-age value that the
parser accepts, but time serialization later fails to process. On 64-bit
systems, extreme max-age values compute an absolute expiry within standard
time integer limits that exceeds calendar time structure bounds. During cache
saves, the original HSTS file is truncated before writing a temporary
replacement; when serialization fails, the temporary file is deleted, leaving
an empty or partial cache. Because the save error is silently ignored during
cleanup, curl exits successfully despite the data loss.
This page as .md · .json · in your agent: get_signal("CVE-2026-87863")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.