Curl shipped a flaw in the year 2000. It got patched a few weeks ago.

The newest release of the open source data transfer tool closed 18 vulnerabilities, and one of them had been sitting quietly in the code for roughly 25 years. None of these are internet-on-fire critical bugs. They’re medium and low severity, the kind that never trend. That’s exactly why this matters more than the average cybersecurity headline, and why it should make you nervous about what else you’re running without knowing it.

Curl is everywhere. Its library form, libcurl, is baked into routers, cars, smart TVs, phones, printers, point-of-sale terminals, and a huge share of the server software you depend on every day. The project counts installations in the tens of billions. You did not install most of them. They arrived bundled inside something else.

Twenty-Five Years Is A Long Time To Hide

A bug that survives a quarter century isn’t a story about sloppy code. Curl is one of the most scrutinized codebases on the planet. It has a famously rigorous maintainer, paid security researchers poking at it, fuzzers grinding on it around the clock, and a bug bounty that pays real money.

And a flaw still lived in there for 25 years.

Sit with that for a second. If the well-funded, heavily audited crown jewel of open source can carry a defect that long, what do you think is hiding in the half-maintained library three levels deep in your build, the one nobody has looked at since the original author changed jobs?

The lesson isn’t “curl is bad.” Curl is excellent. The lesson is that presence and visibility are different things, and the gap between them is where your real risk lives.

The Old Bugs Are The Ones That Get You

Security teams love a fresh zero-day. It’s exciting, it gets a name and a logo, it justifies the budget. Meanwhile the boring, ancient, already-patched stuff is what actually puts attackers inside the building.

The numbers back this up. Recent telemetry from Tenable found 3,569 organizations still exposed to Log4Shell, a 2021 vulnerability, and 1,430 still exposed to the 2017 WannaCry flaw. The 2026 Verizon DBIR puts the median time-to-patch at 43 days, up from 32 the year before. We’re getting slower, not faster, while attackers automate discovery and exploitation.

Here’s the uncomfortable part about curl’s 25-year-old bug. The day it got disclosed, the clock started. The flaw is now public, indexed, and trivial for attackers to scan for. The code that hid it harmlessly for two decades is suddenly a target, and it’s sitting in firmware that may never get an update. Good cyber security means assuming the patch and the exposure are two separate problems with two separate timelines.

Your Cybersecurity Problem Is An Inventory Problem

You can’t patch what you can’t see, and you definitely can’t patch what you don’t know you have. The curl story is a brutal reminder that most of your attack surface showed up uninvited, riding inside other software.

Start with the things you can do this week:

• Build a real software bill of materials. Generate an SBOM for your critical systems and find every place libcurl actually lives, including transitive dependencies you never chose.
• Stop trusting “we don’t use curl.” You almost certainly do. It’s inside container base images, language runtimes, vendor appliances, and embedded firmware.
• Subscribe to upstream advisories for the components you depend on, and wire those alerts into your patch workflow instead of a mailing list nobody reads.
• Treat firmware and appliances as patch targets, not appliances you forget. The devices least likely to update are the ones most likely to run ancient code.

Then build the longer game around the assumption that some vulnerable dependency will always be present somewhere. That’s where defense in depth earns its keep.

Put an egress firewall in front of systems that have no business reaching arbitrary destinations, so a flaw in a data-transfer library can’t quietly phone home. Lean on security hardening to strip components and privileges down to what each service genuinely needs, shrinking the blast radius when something does get hit. Point your threat detection at outbound behavior and anomalous connections, because a compromised library shows up in what it does, not in its version string. Layered threat-protection means no single unpatched dependency becomes a full compromise.

And rehearse the response. When the next ubiquitous component drops an emergency patch, your incident response team should already know how fast you can inventory, prioritize, and push fixes across the fleet. The teams that handle these moments well practiced before the headline, not after.

Curl did the hard part. It found a 25-year-old bug and shipped the fix. Whether that fix ever reaches the billions of places curl actually runs is now your problem, not the maintainer’s.

Sources

• 25-Year-Old Vulnerability Patched in Curl
• How much cyber risk does AI create for organizations? 457 million security issues.