A security bug can hide for years in code that millions of people run. The Shellshock flaw in Bash was introduced on 5 August 1989 and disclosed in September 2014, about 25 years later. Heartbleed was committed on 31 December 2011 and disclosed on 7 April 2014, a little over two years.
Shellshock
According to Wikipedia, Shellshock was reported as CVE-2014-6271 and publicly announced on 24 September 2014, after the maintainer was warned on 12 September. It affected GNU Bash versions 1.0.3 to 4.3.
Bash lets one process pass function definitions to another through environment variables. The bug made Bash execute commands appended to the end of those definitions. The receiving process cannot verify where the definition came from. Stéphane Chazelas found the original bug, and other researchers found related ones, which is why several CVE IDs followed.
Heartbleed
Heartbleed is CVE-2014-0160. The flawed code was committed on 31 December 2011 and spread with OpenSSL 1.0.1 on 14 March 2012. It was privately reported on 1 April 2014 and disclosed on 7 April 2014, the day OpenSSL 1.0.1g shipped with the fix. Versions 1.0.1 through 1.0.1f were affected.
The cause was a missing bounds check in the TLS heartbeat extension, a buffer over-read. An attacker could read up to 64 KiB of the victim's memory, which could include private keys, session cookies and passwords.
Why they lasted so long
The Heartbleed article lists several factors: code complexity, the use of C, insufficient review and audit, and an underfunded project maintained by very few developers. It also says testing that confirms invalid inputs cause failures could have caught the bug.
For Shellshock, the cause was a feature that mixed data and commands, in a tool whose environment handling few people expected to be attacker controlled.
What this suggests
- Age is not safety. Long use does not mean long review.
- Features create attack surface. A rarely used option, such as heartbeat or function export, can carry the worst bug.
- Negative testing matters. Feeding malformed input is cheap and finds a lot.
- Funding is a security control. A critical dependency with one or two maintainers is a risk you can name.
What to check on your side
List your widely shared libraries and shells. For each, ask who maintains it, how often it releases, and how you would learn of a fix. If the answers are unknown, that is the first gap to close.
A habit worth adopting
When a long lived bug is disclosed, run a quick retrospective on your own code. Ask whether you have similar features that mix data and commands, and whether any parsing code lacks tests with malformed input. Add three negative tests this week for the parser you trust most. Those tests are cheap, and they are exactly the kind that the Heartbleed analysis says could have caught the flaw. Over time the habit builds a safety net around code that nobody wants to touch.
Quick check
How long did the Shellshock bug exist before disclosure?
About 25 years, from 1989 to 2014.
What was the Heartbleed bug type?
A buffer over-read caused by a missing bounds check in the TLS heartbeat extension.
Safeguard can help with the practical side of this today: SBOM and dependency scanning show what you actually run, and there is a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
