Major Security Vulnerabilities History and Timeline - Disclosure, Impact, and the Response Practices They Changed
First Published:
Last Updated:
The question "what actually was Heartbleed?" is easy to answer badly. Anniversary posts recycle each other, dates drift between the day a researcher found the flaw and the day a patch shipped, and the more interesting question usually goes unasked: what changed in how the industry responds, because this happened? Coordinated disclosure norms, the CVE program and its numbering authorities, national catalogs of exploited vulnerabilities, software bills of materials, and risk-based patching deadlines were not designed in the abstract. Each of them is, in part, a response to a specific bad week.
This article is my attempt at a single reference that answers both questions with primary sources. It is built on three rules that most existing lists do not follow. First, every row states which kind of date it is - a public disclosure is not a vendor patch, and neither is the day a vulnerability was added to a national catalog. Second, every row links to a primary source: a vendor or project security advisory, a CERT/CC vulnerability note, a government directive, a standards document, or an official regulatory page. Third, the entry criteria are stated rather than implied, because no list of this kind is complete and pretending otherwise is misleading.
This article is written for defensive purposes only. It describes what was broken in terms of what the fix changed and how defenders detect or mitigate the problem. It contains no exploit code, no proof-of-concept, and no reproduction steps. It also does not rank or grade the organizations, products, maintainers, or researchers involved. Several of the events below concern software maintained by very small numbers of unpaid volunteers, and I treat those as what they are: a structural resourcing problem in the commons that everyone builds on, not a failure of the people who kept the code alive.
Companion articles on hidekazu-konishi.com:
- AWS Security Incident Response Playbooks - First-Response Runbooks for Common Scenarios
- Incident Triage Flowcharts - Network, DB, and Application Layer
- AWS End-of-Support and EOL Reference - Lambda, EKS, RDS and Aurora, ElastiCache, and OpenSearch Service
- HTTP Security Headers Complete Reference - CSP, HSTS, COOP, COEP, Permissions Policy
- Cryptography Glossary for Engineers - AES, RSA, ECDSA, HKDF, Envelope Encryption, and TLS Explained
Background and Method of Creating the Major Security Vulnerabilities Timeline
The reason for building this timeline is that the underlying facts are unusually scattered and unusually easy to get wrong. A single vulnerability generates a cluster of different events - a researcher finds something, a vendor is notified privately, an identifier is reserved, a fix is built, an advisory is published, a catalog entry appears, a regulator issues a deadline - and these can be separated by days, months, or in some cases years. Secondary coverage tends to collapse the cluster into one date, and which date survives is essentially arbitrary.So the organizing principle here is that the kind of date is part of the fact. Each row in the timeline carries a label in the date column identifying what the date actually marks. The labels used are:
- Public disclosure - the day details became public, whether through a mailing list post, a research publication, or a coordinated announcement.
- Vendor advisory - the day the vendor or open source project published its own security advisory.
- Vendor bulletin - a scheduled or out-of-band vendor security bulletin that shipped a fix.
- Vendor response - the day a vendor published operational guidance during an active event, as distinct from the advisory that shipped the fix.
- Vulnerability note - the day a coordination center such as CERT/CC published its note.
- Alert - the day a national authority published exploitation guidance for defenders.
- Catalog addition - the day an entry was added to a catalog of exploited vulnerabilities.
- Directive issued - the day a binding government directive was issued.
- Policy / Regulation - the day an executive order or law took a defined step. A label of Regulation, scheduled marks a date that has been set but has not yet arrived.
- Specification - the day a standards document or minimum-elements definition was published.
- Program milestone - a structural change in the vulnerability-management ecosystem itself.
- Practice change - the establishment of a norm, policy, or organization that changed how disclosure or maintenance works.
- Tracking the events that measurably changed vulnerability response practice, and organizing the transition of those practices over time.
- Summarizing the current overall picture of the vulnerability response ecosystem and the division of labor within it.
Inclusion Criteria
This is a curated timeline, not a census. There are hundreds of thousands of published CVE Records, and any attempt to enumerate the important ones is a judgment call. Mine is stated here so that readers can disagree with it precisely.- The event changed response practice. A vulnerability earns a row if the industry did something differently afterwards - a new disclosure norm, a new catalog, a new funding model for maintenance, a new regulatory obligation, or a new class of defensive control. Severe vulnerabilities that were patched uneventfully are outside the scope, however serious they were.
- The date is confirmable in a primary source. Every row below links to a vendor advisory, a project security page, a coordination center note, a government directive, a standards document, or an official regulatory page. Where I could not confirm a date in a primary source, the row is not in the table - including for a few well-known incidents whose canonical advisories are no longer served.
- Structural milestones are included alongside incidents. The creation of the CVE concept, the catalog of exploited vulnerabilities, and the software transparency requirements are interleaved with the incidents rather than separated, because the causal relationship between them is the point of the article.
- Defensive framing only. Descriptions cover what was corrected and how defenders detect or mitigate the issue. Exploitation technique is out of scope.
- No independent severity assessment. Where a severity score appears, it is attributed to the organization that published it. I do not assign my own ratings, and no severity value appears in headings.
Source Policy and Verification Notes
The source policy is primary-only. Secondary media, aggregator posts, and summary articles are not used as the source of record for any date. In practice this required some care, and three findings are worth passing on to anyone assembling a similar reference.Older advisories often redirect to something generic. Several historically important vendor URLs now resolve to a blog index or an archive landing page rather than the document itself. A link that returns a successful HTTP status is not evidence that the document still exists. Where the original location no longer serves the document, this article links the surviving official page and says which one it is.
Directives get revoked. The directive that created the U.S. catalog of exploited vulnerabilities in 2021 was revoked in June 2026 and replaced by a successor with materially different requirements. A great deal of published guidance still describes the superseded model as current. Both are in the timeline, and the relationship between them is explained in the ecosystem overview.
Some official databases are single-page applications. A few authoritative sites return a successful status for essentially any path, including paths that do not exist, because the page is assembled in the browser. For those sources I verified that the retrieved document actually contains the record in question rather than relying on the status code alone.
This timeline primarily references the following sources.
- NIST National Vulnerability Database
- CISA Known Exploited Vulnerabilities Catalog
- CISA Cybersecurity Directives
- CERT/CC Vulnerability Notes Database
- OpenSSL Security Advisories
- Apache Logging Services Security Page
- Microsoft Security Update Guide and Security Bulletins
- European Commission - Cyber Resilience Act
The content posted here is limited to the milestones considered essential for understanding how vulnerability response practice developed.
In other words, please note that the items on this timeline are not all significant vulnerabilities, but are representative milestones that I have picked out under the criteria stated above.
Major Security Vulnerabilities Historical Timeline (Updates from November 1988)
Here is the chronological timeline, from the founding of the first coordination center through the risk-based patching directives of 2026. The date column states both the date and what kind of event that date marks. Each row links to a primary source.
1988 | 1999 | 2002 | 2008 | 2014 | 2015 | 2016 | 2017 | 2018 | 2019 | 2020 | 2021 | 2022 | 2023 | 2024 | 2025 | 2026
* You can sort the table by clicking on the column name.| Date | Summary |
|---|---|
| 1988-11 (Practice change) | The Software Engineering Institute at Carnegie Mellon University establishes the CERT Coordination Center. The center was created in November 1988 in response to the first large-scale internet worm incident, and it introduced the idea that a neutral third party should receive vulnerability reports, coordinate between finders and vendors, and publish advisories. Richard Pethia served as founding director from 1988, and the unit grew from a small incident-response group into the SEI's CERT Division. Source: SEI CERT Division. |
| 1999 (Program milestone) | A MITRE paper proposes a common enumeration of vulnerabilities, the concept that becomes CVE. David E. Mann and Steven M. Christey argued that the industry's inability to say whether two tools were describing the same flaw was itself a security problem, and proposed a shared list of identifiers so that databases and scanners could interoperate. This is the origin of the CVE identifier scheme still in use. Source: Towards a Common Enumeration of Vulnerabilities (MITRE). |
| 2002-07-24 (Vendor bulletin) | Microsoft publishes MS02-039, fixing a buffer overflow in the SQL Server 2000 Resolution Service. The bulletin shipped a corrective patch for the resolution service that answers instance-discovery requests on a UDP port. This entry is included because of what happened next: the patch was available roughly six months before the flaw was exploited at internet scale, which made it one of the earliest widely cited demonstrations that patch availability and patch application are different problems. Source: Microsoft Security Bulletin MS02-039. |
| 2002-07-26 (Vulnerability note) | CERT/CC publishes vulnerability note VU#484891 for the same SQL Server Resolution Service flaw. The note was originally released on 2002-07-26 and last revised in 2006. Having the coordination center's note and the vendor bulletin two days apart is a clean early example of the coordinated model working as designed - and of why a single "the date" for a vulnerability is usually wrong. Source: CERT/CC VU#484891. |
| 2008-10-23 (Vendor bulletin) | Microsoft releases MS08-067 out of band, outside the monthly update cycle. The bulletin addressed a flaw in the Server service that could be reached over the network, and Microsoft shipped it off-schedule rather than waiting for the next scheduled release. The decision to break the monthly cadence established the modern expectation that a sufficiently exposed flaw warrants an emergency release, and the bulletin remains one of the most-cited examples of that practice. Source: Microsoft Security Bulletin MS08-067. |
| 2014-04-07 (Vendor advisory) | The OpenSSL Project publishes the advisory for the TLS heartbeat read overrun, CVE-2014-0160, known as Heartbleed. The advisory describes a missing bounds check in the TLS heartbeat extension that could reveal memory contents to a connected peer, credits Neel Mehta of Google Security for the discovery and Adam Langley and Bodo Moeller for the fix, and directs users to upgrade to 1.0.1g or rebuild with heartbeats disabled. Heartbleed is the event that made "branded vulnerabilities" - a name, a logo, a dedicated site - a standard part of high-impact disclosure, and it forced the industry to confront how much critical infrastructure depended on a project with very little funding. Source: OpenSSL Security Advisory, 07 Apr 2014. |
| 2014-07-15 (Practice change) | Google announces Project Zero and its fixed disclosure deadline. The team was created to find and report vulnerabilities in software its users depend on, and it committed to a policy under which report details become public after a fixed deadline whether or not a fix has shipped. The deadline model changed disclosure negotiation across the industry by removing open-ended embargoes as the default. Source: Announcing Project Zero. |
| 2014-09-24 (Public disclosure) | The GNU Bash environment-variable parsing flaw, CVE-2014-6271, is disclosed publicly and becomes known as Shellshock. The issue was announced on the oss-security mailing list along with the initial patch, and follow-up issues were identified in the days afterwards as the parsing code received wider scrutiny. Because Bash sits behind many indirect interfaces, Shellshock demonstrated that the reachable attack surface of a component is often far larger than its maintainers assume - an argument that later became central to software inventory and SBOM requirements. Source: oss-security: Bash specially-crafted environment variables. |
| 2014-09-24 (Vulnerability note) | CERT/CC publishes vulnerability note VU#252743 for the Bash issue. The note aggregated vendor status across affected operating system distributions, which for a component embedded in dozens of products was more operationally useful than any single vendor advisory. Source: CERT/CC VU#252743. |
| 2014-10-14 (Public disclosure) | Google researchers disclose POODLE, a padding-oracle weakness in SSL 3.0. The disclosure explained that the obsolete protocol version remained reachable because clients and servers would negotiate down to it, and recommended disabling SSL 3.0 outright. It is a landmark for a specific reason: the remedy was not a code fix but the retirement of a protocol version, which established protocol deprecation as a legitimate response to a vulnerability. Source: This POODLE bites: exploiting the SSL 3.0 fallback. |
| 2014-10-15 (Vendor advisory) | The OpenSSL Project ships support for the fallback signaling cipher suite value alongside its October advisory. The same advisory addressed several memory-handling issues, and the release added the mechanism that lets a client signal that it has downgraded its protocol offer, so that a server can refuse an illegitimate downgrade. This is the structural fix for the class of problem POODLE exposed. Source: OpenSSL Security Advisory, 15 Oct 2014. |
| 2015-01-27 (Vendor advisory) | Distributions publish advisories for CVE-2015-0235, a buffer overflow in the GNU C Library host-resolution functions, known as GHOST. Because the affected functions live in the C library rather than in any single application, remediation required coordinated rebuilds and restarts across the whole distribution rather than one package update. GHOST is a useful reference case for the operational cost of a vulnerability in a universally linked dependency. Source: Red Hat: CVE-2015-0235. |
| 2016-03-01 (Vendor advisory) | The OpenSSL Project publishes the DROWN advisory, CVE-2016-0800, and disables SSLv2 by default. The advisory describes a cross-protocol weakness in which a server still supporting the obsolete SSLv2 protocol and export cipher suites can be used to attack sessions on a different, otherwise sound server that shares the same RSA key. The important lesson is stated in the advisory itself: a key shared with any legacy endpoint, even one running a different application protocol, inherits that endpoint's weaknesses. Source: OpenSSL Security Advisory, 1st March 2016. |
| 2017-03-07 (Vendor advisory) | The Apache Struts project announces Struts 2.3.32 and 2.5.10.1, the releases that address the issue tracked as security bulletin S2-045, CVE-2017-5638. The announcement describes the flaw as a possible remote code execution when performing file upload based on the Jakarta Multipart parser, and directs users to upgrade. Struts S2-045 became the standard illustration of third-party framework risk in enterprise applications, and of the gap between a bulletin being published and the affected applications actually being rebuilt and redeployed. The bulletin itself lives on the project wiki, which was not being served at the time of writing; the project's own announcements page is used here instead, and it is also the page the date is taken from. Source: Apache Struts Announcements 2017. |
| 2017-03-14 (Vendor bulletin) | Microsoft publishes MS17-010, a security update for the Server Message Block server. The bulletin was published on 2017-03-14 as part of the scheduled monthly release and addressed several issues in SMB. Its significance is entirely in the interval that followed: the update was available for approximately two months before the vulnerabilities it fixed were used at scale. Source: Microsoft Security Bulletin MS17-010. |
| 2017-05-12 (Vendor response) | Microsoft publishes customer guidance during the WannaCrypt ransomware outbreak and takes the unusual step of releasing updates for operating systems that were already out of support. The guidance confirmed that supported systems with the March update were already protected, and provided fixes for platforms that had passed end of support. This is the clearest single case for the argument that end-of-support inventory is a security control rather than a procurement detail - a theme that reappears in the 2026 directives further down this table. Source: Customer Guidance for WannaCrypt attacks (MSRC). |
| 2018-01-03 (Public disclosure) | Google Project Zero publishes its analysis of speculative execution side channels, the class of issues known as Meltdown and Spectre. The research showed that performance optimizations present in processors from multiple vendors could allow inference of memory contents across a privilege or process boundary, and that mitigation required coordinated changes across silicon, firmware, operating systems, and compilers. The disclosure became the reference case for hardware-level issues that no single vendor can fix alone, and for what happens when a long multi-party embargo does not hold to its planned date. Source: Reading privileged memory with a side-channel. |
| 2019-05-14 (Vendor advisory) | Microsoft publishes the advisory for CVE-2019-0708, a Remote Desktop Services flaw known as BlueKeep, including updates for out-of-support platforms. The advisory was accompanied by unusually direct messaging urging immediate patching because the issue did not require authentication or user interaction. Releasing fixes for platforms past end of support - for the second time in two years - signaled that vendors now treat certain classes of exposure as a public-safety matter rather than a support-contract matter. Source: Microsoft Security Update Guide: CVE-2019-0708. |
| 2020-08-03 (Practice change) | The Open Source Security Foundation is established at the Linux Foundation. The announcement describes OpenSSF as a cross-industry collaboration to improve the security of open source software, combining efforts from the Core Infrastructure Initiative and GitHub's Open Source Security Coalition among others - that is, consolidating bodies created in the wake of the 2014 disclosures. It represents the institutional answer to the resourcing problem that Heartbleed exposed. Source: Technology and Enterprise Leaders Combine Efforts to Improve Open Source Security. |
| 2020-12-13 (Directive issued) | CISA issues Emergency Directive 21-01 concerning compromised network management software. The directive required U.S. federal civilian agencies to disconnect or power down affected products and to conduct forensic analysis, on the basis that the software build and distribution pipeline itself had been subverted. The directive has since been closed, and its page states so. This is the event that moved "supply chain" from an abstract risk category to a category with its own emergency response playbook. Source: CISA Emergency Directive 21-01 (closed). |
| 2021-03-03 (Directive issued) | CISA issues Emergency Directive 21-02 covering on-premises mail server vulnerabilities. The directive addressed CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065, and required forensic triage in addition to patching, on the assumption that exposed servers should be treated as already compromised. CISA later closed the directive and transitioned its required actions into the standing catalog-based directive. Source: CISA Emergency Directive 21-02 (closed). |
| 2021-05-12 (Policy) | Executive Order 14028 on improving the nation's cybersecurity is signed, introducing federal software bill of materials expectations. Among many provisions, the order directed the development of guidance requiring suppliers to provide a software bill of materials for products sold to the federal government. It is the moment software composition transparency moved from a good idea to a procurement requirement. Source: Executive Order 14028, Federal Register (GovInfo). |
| 2021-07-12 (Specification) | NTIA publishes The Minimum Elements For a Software Bill of Materials. The document defines the baseline data fields, automation support, and practices that make an SBOM usable, giving the executive order's requirement a concrete and testable definition. Source: NTIA: The Minimum Elements For a Software Bill of Materials. |
| 2021-11-03 (Directive issued) | CISA issues Binding Operational Directive 22-01, creating the Known Exploited Vulnerabilities catalog. The directive established a public catalog of vulnerabilities with confirmed exploitation and set remediation deadlines tied to catalog entry rather than to severity score. It was the first large-scale operational statement that evidence of exploitation is a better prioritization signal than a severity rating. This directive was revoked on 2026-06-10 and is superseded by BOD 26-04, though the catalog itself continues. Source: CISA BOD 22-01 (revoked). |
| 2021-12-09 (Public disclosure) | The Apache Log4j JNDI lookup issue, CVE-2021-44228, becomes public and is named Log4Shell. The project's security page records that a JNDI lookup reachable from logged data could cause code to be loaded from a remote directory service, credits the discovery to Chen Zhaojun of the Alibaba Cloud Security Team, and lists the fixed versions - 2.3.1, 2.12.2, and 2.15.0 - followed by further releases as related issues were found. Log4Shell is the definitive argument for software inventory: the hard part was never applying the fix, it was answering the question "where do we run this?" Source: Apache Logging Services Security page. |
| 2021-12-10 (Catalog addition) | The Log4j issue is added to the CISA Known Exploited Vulnerabilities catalog with a two-week remediation deadline. The NVD record for CVE-2021-44228 shows the catalog date added as 2021-12-10 and the due date as 2021-12-24, with the required action being to apply updates or remove affected assets from agency networks. The one-day interval between public disclosure and catalog entry, and the two-week deadline, make this a good illustration of how the exploitation-driven model compresses response timelines. Source: NVD: CVE-2021-44228. |
| 2022-03-31 (Vendor advisory) | The Spring team publishes an early announcement for a Spring Framework remote code execution issue, CVE-2022-22965, known as Spring4Shell. The post is notable as a process artifact: the team published while details were already circulating, describing the affected configurations and a suggested workaround before the full advisory was ready, and updated the post as follow-up issues were addressed. Publishing an incomplete but accurate early announcement, rather than waiting for a complete one, has since become a common pattern for high-attention disclosures. Source: Spring Framework RCE, Early Announcement. |
| 2022-04 (Specification) | RFC 9116 defines security.txt, a standard file for reporting security issues. The specification defines a plain text file at a well-known location that tells a would-be reporter where and how to send a vulnerability report. It addresses one of the most persistent frictions in coordinated disclosure: finders frequently could not determine who to contact. Source: RFC 9116: A File Format to Aid in Security Vulnerability Disclosure. |
| 2022-11-01 (Vendor advisory) | The OpenSSL Project publishes advisories for CVE-2022-3602 and CVE-2022-3786 after pre-announcing the release date, and revises the severity downward before publication. The project had announced a week in advance that a release addressing a high-priority issue was coming, allowing operators to prepare, and then published with a lower severity rating than initially indicated after further analysis. The episode is widely referenced as a case study in pre-announcement: it gives defenders time to prepare, at the cost of a period of uncertainty. Source: OpenSSL Security Advisory, 1st November 2022. |
| 2023-05-31 (Vendor advisory) | Progress publishes a critical advisory for a MOVEit Transfer vulnerability, later identified as CVE-2023-34362. The advisory instructed customers to restrict traffic to the application, apply the patch, and check for indicators of unauthorized access. Because the affected product is a managed file transfer system used to move data between organizations, remediation obligations propagated outward through customer relationships rather than stopping at the operator - an early practical demonstration of third-party and fourth-party risk notification. Source: Progress: MOVEit Transfer Critical Vulnerability. |
| 2024-03-29 (Public disclosure) | A backdoor in the upstream xz compression utility, CVE-2024-3094, is reported to the oss-security mailing list. Andres Freund reported that the upstream repository and release tarballs had been modified, after investigating unexplained resource usage and errors on a development distribution. The case is distinct from every other entry in this table because the flaw was deliberately introduced through sustained social engineering of a maintenance process, not accidentally written. It prompted broad reconsideration of maintainer succession, release signing, and build reproducibility - and it should be read as evidence of how thin the maintenance layer of critical infrastructure is, not as a criticism of the maintainers involved. Source: oss-security: backdoor in upstream xz/liblzma. |
| 2024-04-24 (Program milestone) | CISA publishes the Vulnrichment repository, adding decision-support data to CVE Records as an Authorized Data Publisher. The program adds Stakeholder-Specific Vulnerability Categorization decision points - covering exploitation status, automatability, and technical impact - to published records, and pushes results back into the CVE corpus through the Authorized Data Publisher mechanism rather than requiring consumers to track a separate feed. It is the practical response to a growing gap in record enrichment. Source: CISA Vulnrichment. |
| 2024-04-25 (Program milestone) | NIST publishes an updated program announcement about National Vulnerability Database enrichment. The announcement acknowledged a growing backlog in the analysis that adds severity metrics and product identifiers to CVE Records, and described the program's plan to address it. It marked the point at which downstream tooling could no longer assume that a published CVE Record would arrive already enriched, and drove the adoption of multiple complementary data sources. Source: NVD Program Announcement. |
| 2024-05-08 (Practice change) | CISA launches the Secure by Design Pledge for enterprise software manufacturers. The pledge is a voluntary, non-binding commitment covering goals such as increasing multi-factor authentication, reducing default passwords, reducing entire classes of vulnerability, and improving the timeliness and completeness of CVE publication. It shifts part of the conversation from "how fast do operators patch" to "how many of these defects should have existed at all". Sources: CISA Announces Secure by Design Commitments from Leading Technology Providers, CISA Secure by Design Pledge. |
| 2024-12-10 (Regulation) | The EU Cyber Resilience Act enters into force. The regulation sets cybersecurity requirements for products with digital elements placed on the EU market, including obligations relating to vulnerability handling and reporting, with conformity indicated by CE marking. Its phased application dates are what make it operationally significant, and they appear later in this table. Source: European Commission: Cyber Resilience Act. |
| 2025-07-20 (Alert) | CISA publishes guidance on exploitation of on-premises collaboration server vulnerabilities including CVE-2025-53770. The alert was issued and subsequently updated as vendor guidance developed, and it followed the now-standard pattern for internet-facing enterprise servers: assume compromise, hunt, then remediate. Source: CISA Alert: Microsoft releases guidance on exploitation of SharePoint vulnerabilities. |
| 2025-09-10 (Program milestone) | CISA publishes a strategic focus for the CVE Program, describing a transition from its Growth Era to a Quality Era. The document sets out priorities for governance, modernization, transparency, data quality, and responsiveness, following a period in which the program's funding arrangements and record quality had both come under scrutiny. Source: CISA presents vision for the CVE Program. |
| 2025-09-22 (Practice change) | GitHub publishes its plan to harden the npm supply chain after a surge in package registry attacks. The plan covers stricter authentication, granular tokens, and expanded trusted publishing, in response to self-propagating attacks that abused publishing credentials to compromise further packages. It is the registry-operator counterpart to the maintainer-side lessons of the 2024 compression-utility case. Source: GitHub: Our plan for a more secure npm supply chain. |
| 2025-10-15 (Directive issued) | CISA issues Emergency Directive 26-01 covering vulnerabilities in widely deployed application delivery devices. The directive is one of a series in which the emergency response concerns network edge appliances rather than general-purpose servers, reflecting where exploitation activity has concentrated. Source: CISA Emergency Directive 26-01. |
| 2026-02-05 (Directive issued) | CISA issues Binding Operational Directive 26-02 on mitigating risk from end-of-support edge devices. The directive treats devices that have passed end of support and remain at the network edge as a standing risk requiring action, rather than as a matter to be resolved on a procurement schedule. It formalizes the lesson that the 2017 and 2019 out-of-support emergency patches demonstrated the hard way. Source: CISA BOD 26-02. |
| 2026-02-25 (Directive issued) | CISA issues Emergency Directive 26-03 concerning vulnerabilities in software-defined WAN systems, with supplemental hunting and hardening direction. The directive was accompanied on the same date by supplemental guidance covering hunt and hardening steps, and was revised in March 2026. The pairing of a remediation directive with explicit hunting instructions is now the default shape of emergency response for management-plane systems. Source: CISA Emergency Directive 26-03. |
| 2026-06-10 (Directive issued) | CISA issues Binding Operational Directive 26-04, which supersedes and revokes BOD 22-01 and replaces catalog-triggered deadlines with risk-based ones. The same directive also revokes BOD 19-02, the 2019 directive that had set fixed remediation timelines for vulnerabilities found by Cyber Hygiene scanning of internet-accessible systems, so the two previous federal remediation-deadline models were retired together. The directive determines remediation urgency from four variables - whether the asset is publicly exposed, whether the vulnerability is in the Known Exploited Vulnerabilities catalog, whether exploitation can be fully automated, and what technical impact successful exploitation confers - and points to the Vulnrichment program as the source of the last three. Low-risk vulnerabilities may be deferred, which is a significant departure from the previous uniform-deadline model. Source: CISA BOD 26-04. |
| 2026-07-27 (Regulation) | The European Commission publishes practical guidance for meeting Cyber Resilience Act obligations. The guidance is aimed at manufacturers, developers, and businesses of all sizes, and arrives ahead of the first substantive compliance date. Source: European Commission: Cyber Resilience Act. |
| 2026-09-11 (Regulation, scheduled) | Cyber Resilience Act reporting obligations begin to apply. From this date, manufacturers of products with digital elements placed on the EU market become subject to the Act's reporting obligations, ahead of the main body of obligations, which applies from 2027-12-11. This is the point at which coordinated vulnerability disclosure stops being purely a matter of norms for a large part of the industry. Source: European Commission: Cyber Resilience Act. |
There may be slight variations between these dates and dates cited elsewhere, because sources differ in which event of the disclosure cluster they treat as definitive. The date column above states which event each date marks, so that rows can be compared safely.
Current Overview of the Vulnerability Response Ecosystem
Having followed the chronology, this section describes the machinery as it stands in 2026: how a vulnerability becomes a public record, who performs which function, which signals are used to decide what to fix first, and what the 2026 shift from catalog-triggered deadlines to risk-based ones means in practice.How a Vulnerability Becomes a Public Record
The path from "someone noticed something" to "an entry your scanner can act on" passes through several independent organizations. Understanding the handoffs explains most of the confusion about dates, and most of the gaps operators run into.
- Report. A finder - an internal engineer, an external researcher, a customer, or an automated system - reports the issue. Where the finder cannot identify a contact, RFC 9116's security.txt is the standardized way to publish one. Where the finder and vendor cannot communicate productively, a coordination center such as CERT/CC can act as an intermediary.
- Triage and identifier assignment. The vendor confirms the issue and, if it is a CVE Numbering Authority, reserves a CVE identifier itself. Otherwise a parent CNA or the program's root does so. The identifier exists before the details are public; this is why an identifier alone does not mean a vulnerability is publicly known.
- Fix development and coordinated timing. The vendor develops a fix. Disclosure timing is negotiated, subject to the finder's disclosure policy - a fixed deadline in the Project Zero model, or a negotiated date in a traditional coordinated model.
- Publication. The vendor publishes an advisory and the CVE Record becomes public. For issues affecting many downstream products, a coordination center note that aggregates per-vendor status is frequently more useful than any single advisory.
- Enrichment. Additional data - severity metrics, affected-product identifiers, and decision-support attributes - is attached to the record. This is performed by NVD analysis and, since 2024, also by Authorized Data Publishers such as CISA's Vulnrichment program.
- Exploitation signal. If exploitation is confirmed, the vulnerability is added to the Known Exploited Vulnerabilities catalog, with its own date that is distinct from every date above.
- Operator action. Downstream, the operator has to answer a question that none of the previous steps answers: do we run this, and where? This is where software inventory and SBOM data are consumed, and it remains the step that most often determines actual response time.
The Several Dates of a Single Vulnerability
One vulnerability produces many dates. Conflating them is the single most common error in vulnerability writing, and it has practical consequences: a metric such as "time to remediate" means something different depending on which date starts the clock.| Date type | What it marks | Why it matters operationally |
|---|---|---|
| Discovery | When the finder identified the issue. | Rarely published, and rarely verifiable. Useful only for retrospectives, not for measurement. |
| Vendor notification | When the vendor was told privately. | Starts the disclosure clock. The interval to publication is the main indicator of how a coordinated process performed. |
| Identifier reservation | When a CVE ID was reserved by a CNA. | A reserved identifier is not public knowledge. Seeing an ID in a commit or bug tracker does not mean disclosure has occurred. |
| Public disclosure | When details became public. | The start of the exposure window most operators care about, because it is when opportunistic scanning begins. |
| Vendor advisory or patch | When the fix and its documentation shipped. | The earliest point at which most operators can actually act. May precede or follow public disclosure. |
| Record publication and enrichment | When the CVE Record was published, and when metrics and product identifiers were attached. | Determines when automated tooling can match the vulnerability to inventory. Enrichment can lag publication. |
| Catalog addition | When exploitation was confirmed and the entry was cataloged. | Under the current U.S. federal model this is a primary input to remediation urgency, and it can occur long after disclosure. |
Who Does What in the Ecosystem Today
The functions below are performed by different organizations with different mandates. Treating any one of them as "the vulnerability database" leads to blind spots.| Function | Performed by | Role |
|---|---|---|
| Identifier assignment | CVE Program and its CVE Numbering Authorities | Assigns and publishes CVE Records so that different tools can refer to the same flaw unambiguously. CNAs are typically the vendors and projects themselves, with the program acting as coordinator. |
| Analysis and enrichment | NIST National Vulnerability Database | Adds severity metrics, weakness classification, and product identifiers to published records so they can be matched against inventory automatically. |
| Decision-support enrichment | CISA Vulnrichment (Authorized Data Publisher) | Adds Stakeholder-Specific Vulnerability Categorization decision points - exploitation status, automatability, and technical impact - directly into the CVE corpus. |
| Exploitation evidence | CISA Known Exploited Vulnerabilities catalog | Publishes the set of vulnerabilities with confirmed exploitation, which is the most widely reused prioritization signal outside the U.S. federal context as well as inside it. |
| Severity framework | FIRST (CVSS) | Maintains the scoring framework used to express intrinsic technical severity. Scores are published by CNAs and by NVD, and the two do not always agree. |
| Exploitation probability | FIRST (EPSS) | Publishes model-derived probability estimates that a vulnerability will be exploited in the near term, updated continuously. |
| Multi-party coordination | CERT/CC and other national or sector CSIRTs | Coordinates disclosure when many vendors are affected by one underlying defect, and publishes vendor status matrices. |
| Composition transparency | SBOM formats and VEX documents | Describe what a product contains, and separately whether a given vulnerability in a contained component is actually exploitable in that product. |
| Regulatory obligation | Government directives and legislation | Convert the above from good practice into a requirement for defined populations - U.S. federal civilian agencies via CISA directives, and manufacturers selling into the EU via the Cyber Resilience Act. |
Prioritization Signals: Severity, Exploitation, and Probability
There are now four broadly used signals, and their most important property is that they answer different questions. I do not assign my own severity assessments anywhere in this article; where a score is mentioned, it belongs to the organization that published it.- CVSS, maintained by FIRST, expresses intrinsic technical severity - how bad the outcome would be if the vulnerability were exploited. It deliberately says nothing about whether exploitation is happening. Note also that a CVE Record's score assigned by the CNA and the score assigned during NVD analysis are separate values, and when quoting a score it is worth saying which one it is. See the FIRST CVSS documentation.
- EPSS, also maintained by FIRST, estimates the probability of exploitation activity in the near term. It is designed to be used as a ranking input across a large backlog, not as a verdict on any single vulnerability. See FIRST EPSS.
- The KEV catalog, maintained by CISA, records observed exploitation. It is evidence rather than prediction, which is what makes it valuable and also what makes it lag: absence from the catalog is not evidence of safety. See the CISA KEV catalog.
- SSVC decision points, published into CVE Records by CISA's Vulnrichment program, express decision-relevant attributes - exploitation status, whether exploitation can be fully automated, and the degree of control gained - that feed a decision tree rather than a single number.
From Catalog Deadlines to Risk-Based Remediation
This is the part of the ecosystem that changed most recently, and it is the part where existing published guidance is most likely to be out of date.From 2021 to 2026, the operative model for U.S. federal civilian agencies was BOD 22-01: CISA maintained a catalog of vulnerabilities with confirmed exploitation, and agencies remediated catalog entries within fixed deadlines. The model's virtue was its simplicity, and its influence extended far beyond its formal scope - many private-sector programs adopted "remediate everything in KEV" as an internal standard.
On 2026-06-10, CISA revoked BOD 22-01 and superseded it with BOD 26-04, Prioritizing Security Updates Based on Risk. The catalog continues; what changed is that catalog membership became one input among several rather than the trigger. Remediation urgency is now determined by four variables:
- Asset exposure - whether the vulnerable asset is publicly exposed.
- KEV status - whether the CVE ID is in the Known Exploited Vulnerabilities catalog.
- Exploit automation - whether an adversary can automate all the steps needed to exploit it.
- Technical impact - whether successful exploitation yields partial or total control of the asset.
For anyone outside the U.S. federal population, the significance is not the compliance obligation but the design: the reference implementation of "how should a large organization decide what to patch first" now combines exposure, exploitation evidence, automatability, and impact, rather than relying on a single catalog or a single score. If your internal standard is still "everything in KEV within the deadline", it is worth revisiting against this model. The companion directive BOD 26-02, on end-of-support edge devices, addresses the adjacent problem that some assets cannot be patched at all - a scenario covered from the AWS managed-service angle in my AWS End-of-Support and EOL Reference.
Software Transparency: SBOM, VEX, and Regulation
Log4Shell established the operational problem, and the transparency effort is the industry's answer to it. The difficulty in December 2021 was not writing a patch - fixed versions existed within days - but that a very large number of organizations could not determine whether they shipped or ran the affected component, because it was frequently an indirect dependency bundled inside something else.Two document types address different halves of the problem:
- A software bill of materials answers "what is in this product". Executive Order 14028 introduced the federal procurement expectation, and the NTIA minimum elements gave it a testable definition covering baseline data fields, automation support, and practices.
- A VEX document answers "is this vulnerability actually exploitable in this product". Without it, an SBOM tends to generate a large volume of findings for components that are present but not reachable, which produces alert fatigue and can make the transparency effort counterproductive.
What Changed for Operators
Reading the timeline as a whole, a fairly small number of durable lessons account for most of the practice changes.| Lesson | Where it came from | What it looks like in practice now |
|---|---|---|
| Patch availability is not patch application | MS02-039 and MS17-010, where fixes preceded mass exploitation by months | Remediation deadlines measured from availability, and coverage reporting rather than patch-published reporting. |
| You cannot fix what you cannot find | Shellshock and Log4Shell, where the component was embedded indirectly | Software inventory and SBOM as an operational capability, with VEX to control the resulting noise. |
| Critical infrastructure can be under-resourced | Heartbleed, and the 2024 compression-utility backdoor | Cross-industry funding bodies, maintainer support programs, and bug bounty funding for foundational projects. |
| Disclosure needs a clock | Fixed-deadline disclosure policies from 2014 onward | Published disclosure policies on both sides, a documented contact via security.txt, and pre-announcement for high-impact releases. |
| Exploitation evidence beats severity alone | The 2021 catalog directive and its 2026 successor | Prioritization combining exposure, exploitation evidence, automatability, and impact. |
| The build pipeline is in scope | The 2020 network management software compromise, and package registry attacks | Signed releases, reproducible builds, trusted publishing, and provenance attestation. |
| Unsupported does not mean unexposed | Out-of-support emergency patches in 2017 and 2019 | End-of-support inventory treated as a security control, formalized in BOD 26-02. |
Frequently Asked Questions about Major Security Vulnerabilities History
What was Heartbleed and what changed because of it?
Heartbleed is CVE-2014-0160, a missing bounds check in the OpenSSL implementation of the TLS heartbeat extension. The OpenSSL Project published its advisory on 2014-04-07 and directed users to upgrade to 1.0.1g or to rebuild with heartbeats disabled. Two things changed lastingly. First, it established the branded-vulnerability pattern - a name, a logo, and a dedicated explanation site for high-impact issues - which improved reach but also created an incentive to brand less consequential findings. Second, it drew attention to how little funding supported a component that a large share of internet infrastructure depended on, which led to cross-industry efforts to fund maintenance of critical open source software.What was Log4Shell and why was it so hard to remediate?
Log4Shell is CVE-2021-44228, an issue in Apache Log4j in which a JNDI lookup reachable from logged data could cause code to be loaded from a remote directory service. It became public on 2021-12-09, and the Apache Logging Services security page lists the fixed versions as 2.3.1, 2.12.2, and 2.15.0, with further releases following as related issues were identified. The difficulty was not the fix but the inventory question: Log4j was very frequently an indirect dependency bundled inside other software, so organizations could not readily determine where they were running it. This is the event most directly responsible for the mainstreaming of software bill of materials requirements.Is CISA BOD 22-01 still in effect?
No. BOD 22-01, which created the Known Exploited Vulnerabilities catalog on 2021-11-03, was revoked on 2026-06-10 and is superseded by BOD 26-04, Prioritizing Security Updates Based on Risk. The KEV catalog itself continues to be published and remains widely used. What changed is that catalog membership is now one of four inputs to remediation urgency - alongside asset exposure, exploit automation, and technical impact - rather than the trigger for a uniform deadline, and BOD 26-04 permits deferring action on low-risk vulnerabilities. A significant amount of published guidance still describes the BOD 22-01 model as current.What is the difference between a CVE Record and an NVD entry?
They are produced by different organizations at different stages. A CVE Record is created by a CVE Numbering Authority - usually the affected vendor or project - and establishes the identifier and the basic description. The NIST National Vulnerability Database then analyzes published records and adds enrichment such as severity metrics, weakness classification, and product identifiers that let automated tools match the record against an inventory. Since 2024 that enrichment has also come from Authorized Data Publishers, notably CISA's Vulnrichment program, which adds decision-support attributes directly into the CVE corpus. Because enrichment can lag publication, tooling should not assume a newly published record already carries complete metadata.What is the difference between CVSS, EPSS, and the KEV catalog?
They answer three different questions. CVSS, maintained by FIRST, describes intrinsic technical severity - how bad the outcome would be. EPSS, also maintained by FIRST, estimates the probability that exploitation activity will occur in the near term, and is intended for ranking a large backlog. The CISA Known Exploited Vulnerabilities catalog records observed exploitation, so it is evidence rather than prediction. Because it is evidence, it necessarily lags, and absence from the catalog should not be read as an indication that a vulnerability is safe to defer.Why do different sources give different dates for the same vulnerability?
Because a single vulnerability produces a cluster of distinct events - discovery, private vendor notification, identifier reservation, public disclosure, advisory or patch publication, record publication and enrichment, and catalog addition - and different sources pick different members of that cluster as "the" date. For CVE-2021-44228, for example, public disclosure was on 2021-12-09 while the addition to the KEV catalog is dated 2021-12-10 with a remediation due date of 2021-12-24. This article states the event type alongside every date for that reason.When do the EU Cyber Resilience Act obligations apply?
The Cyber Resilience Act entered into force on 2024-12-10. Its reporting obligations apply from 2026-09-11, and the main body of obligations applies from 2027-12-11. The European Commission published practical guidance for manufacturers, developers, and businesses on 2026-07-27. For manufacturers placing products with digital elements on the EU market, this converts vulnerability handling and coordinated disclosure from a voluntary norm into a documented obligation with defined reporting timelines.What was the xz Utils backdoor and how was it different from other cases?
CVE-2024-3094 concerns a backdoor that was deliberately introduced into the upstream xz compression utility repository and release tarballs, reported to the oss-security mailing list on 2024-03-29 by Andres Freund after he investigated unexplained resource usage and errors. It differs from every other case in this timeline because the defect was not a mistake in code - it was introduced through sustained social engineering of a project's maintenance process. The response focused on maintainer succession practices, release signing, and build reproducibility rather than on a code-level fix, and the case is best understood as evidence of how thinly resourced the maintenance layer of widely used infrastructure can be.Summary
In this article, I built a chronological timeline of the security vulnerabilities and policy milestones that changed how the industry responds to vulnerabilities, and summarized the current state of that response ecosystem.The timeline shows four broad phases. A coordination phase, beginning with the establishment of the CERT Coordination Center in 1988, in which the basic idea of a neutral intermediary between finders and vendors was created. An enumeration phase, from the 1999 proposal for a common vulnerability enumeration, in which shared identifiers and severity metrics made vulnerabilities machine-tractable. A branded disclosure phase, from Heartbleed and Shellshock in 2014, in which high-impact issues acquired names, dedicated sites, and fixed disclosure deadlines - and in which the industry first confronted how little funding sat behind its most widely used components. And a supply chain and regulation phase, from roughly 2020 onward, in which the compromise of build and distribution pipelines, the inventory crisis exposed by Log4Shell, and the deliberate subversion of a maintenance process moved the conversation to software composition transparency and, ultimately, to law.
The most consequential recent change is the least widely reported one. The directive that created the Known Exploited Vulnerabilities catalog in 2021 was revoked in June 2026 and replaced by a risk-based model that weighs exposure, exploitation evidence, automatability, and technical impact together. The catalog remains; the reflex of treating catalog membership as the sole trigger no longer reflects the reference model. Any organization whose internal remediation standard was built on the earlier directive has a reason to revisit it.
By organizing these events in one place, stating what kind of date each row records, and linking a primary source for every one, I hope this article serves as a reference that engineers, incident responders, and AI search agents can consult in a single fetch.
This timeline will be updated as vulnerability disclosure and response practices continue to evolve.
In addition, there are related history-and-timeline articles on this site, so please have a look if you are interested.
AWS History and Timeline - Almost All AWS Services List, Announcements, General Availability(GA)
TLS Certificate Ecosystem History and Timeline - Certificate Authorities, Automation, and Shrinking Certificate Lifetimes
Post-Quantum Cryptography Standardization Timeline and Migration on AWS - From Algorithm Selection to Service Support
Tool Use and Agent Protocol History and Timeline - Function Calling, MCP, and A2A
AWS History and Timeline regarding AWS WAF - Overview, Functions, Features, Summary of Updates, and Introduction
References:
CISA Known Exploited Vulnerabilities Catalog
CISA BOD 26-04: Prioritizing Security Updates Based on Risk
NIST National Vulnerability Database
CERT/CC Vulnerability Notes Database
OpenSSL Security Advisories
Apache Logging Services Security Page
FIRST Common Vulnerability Scoring System
FIRST Exploit Prediction Scoring System
CISA Vulnrichment
European Commission: Cyber Resilience Act
RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
AWS Security Incident Response Playbooks - First-Response Runbooks for Common Scenarios
HTTP Security Headers Complete Reference - CSP, HSTS, COOP, COEP, Permissions Policy
Cryptography Glossary for Engineers - AES, RSA, ECDSA, HKDF, Envelope Encryption, and TLS Explained
References:
Tech Blog with curated related content
Written by Hidekazu Konishi