SAGO RELEASED: THE N-DAY OPEN DATABASE by N4C
SAGO: N-DAY OPEN DATABASE
Hello, this is juhan.
SAGO is a public database that reverse-engineers disclosed vulnerabilities and publishes complete, in-depth 1-day reports covering everything from root-cause analysis and reproducible PoCs to exploit code. The project is led by heegong within N4C, TeamH4C’s internal N-Day research team.
We understand that publishing detailed 1-day vulnerability research inevitably raises concerns.
This document explains why we chose to pursue this project, and the principles and responsibilities that govern how we disclose our research.
We will keep the introduction to SAGO itself brief here and go into the details below.
A link to SAGO is provided at the end of this document.
1. Introduction: On the Risks of This Project
We know the first question we need to answer.
“Does publishing exploit code make it easier for attackers?”
That question, however, often rests on an underlying assumption: that until someone publishes the technical details, the vulnerability remains safely hidden.
That assumption is simply not true.
Once a vendor releases a patch, placing the vulnerable and patched versions side by side can often reveal, with considerable precision, what changed, where the flaw existed, and why it was exploitable. With the rise of LLMs, this process has become dramatically faster.
At the same time, countless CVEs are published every day, yet most defenders and security practitioners are still expected to build defenses from a few terse lines in a vendor advisory and a collection of fragmented public references.
Meanwhile, malicious actors and participants in underground exploit markets may already have completed the weaponization process.
We want to narrow this critical asymmetry in capability.
And we want to make one thing clear from the outset:
We understand that this is a double-edged sword.
That is precisely why we separate the disclosure timelines for PoCs and exploits.
The PoCs we publish are intended only to demonstrate that a vulnerability exists and, where appropriate, are limited to effects such as a controlled crash.
Exploit code is delayed by 90 days and constrained to limited demonstrations such as launching cmd or calc; weaponization components are excluded entirely.
The disclosure policy described later in this document was not designed because we deny the risks.
It was designed because we acknowledge them.
It is a double-edged sword, but our goal is to make one edge as blunt as possible.
2. Why We Publish, Part I: Silence Does Not Eliminate Vulnerabilities
From two years to thirteen hours.
This extraordinary figure represents the reduction, from 2018 to 2026, in the average time required for vulnerabilities to progress toward exploitation, according to Zeroday Clock.
In 2017, Google Project Zero researcher Mateusz Jurczyk wrote:
“For software that can be reverse engineered, the risk of post-patch vulnerability exploitation is unavoidable and should be considered a natural part of the ecosystem.”
In the conclusion of the same article, he also noted that the patch-diffing work he had performed required neither extensive low-level expertise nor deep knowledge of operating-system internals. Much of it took place at the pseudocode level, and even a relatively inexperienced attacker could have used the same techniques to identify three vulnerabilities with very little effort (Jurczyk).
Maddie Stone, also of Project Zero, wrote in 2020:
“Patch diffing is a frequently overlooked part of the perennial vulnerability-disclosure debate. A vulnerability effectively becomes public knowledge when a software update is released, not when it is announced in the release notes.”
She further pointed out that when a patch is released without detailed vulnerability information, researchers capable of diffing that patch may end up knowing more about the vulnerability than the defenders responsible for deploying the fix (Stone).
Finally, CERT/CC addresses the question directly in its vulnerability disclosure policy:
“If there is no update available, wouldn’t it be better to simply keep quiet?”
CERT/CC notes that vulnerabilities are routinely discovered and disclosed even before vendors have had an opportunity to fix them, and that such disclosures frequently include working exploits (CERT Coordination Center).
These examples form the factual foundation for why we created this project.
The moment a patch is distributed, information about what changed is already available. Extracting that information increasingly requires less specialized expertise, and the time required to do so continues to shrink.
Malicious actors do not need SAGO to reach that point. They do not necessarily wait for us—or even for a patch (Project Zero).
What we disclose 90 days after a patch may therefore provide relatively little incremental value to highly capable attackers.
But there are clearly defenders who cannot do anything meaningful without this kind of analysis.
It is exceedingly rare for an ordinary enterprise development or security team to have people with advanced offensive exploitation capabilities.
With open-source software, researchers can inspect the commit history.
With closed-source binaries, they may need to obtain both vulnerable and patched versions, reverse engineer them, and perform binary diffing.
The organizations capable of doing this work are disproportionately concentrated on the offensive side.
On the defensive side, these capabilities tend to exist within major security companies and a small number of highly mature enterprise SOCs.
A two-person security team at a mid-sized manufacturer, an IT administrator handling security as an additional responsibility at a regional hospital, or an information-systems team at a local government agency generally cannot perform this kind of analysis themselves.
The barrier here is not access. It is capability.
And choosing not to publish does not necessarily hide the vulnerability from those who already possess that capability.
It may only hide it from those who do not.
LLMs have made this asymmetry even more significant.
Attackers can now move from patches to working exploitation on dramatically shorter timelines. In one Mandiant analysis, 12% of observed n-day vulnerabilities were exploited within one day of a patch becoming available, and 29% within one week. Enterprise patch deployment, by contrast, often still operates on timelines measured in weeks or months (Charrier and Weiner).
The gap between those two timelines is where a substantial amount of real-world compromise occurs.
During that window, what defenders need most is not necessarily an exploit. They need evidence on which to make decisions.
A vendor advisory might say:
“Remote code execution may be possible under certain conditions.”
That sentence is not enough to make an operational decision.
Does our environment satisfy those “certain conditions”?
Do we need to wake people up tonight and perform an emergency patch?
Can this wait until the next scheduled maintenance window?
Without technical context, those questions are difficult to answer.
SAGO’s root-cause analysis aims to turn that vague advisory into something more concrete, for example:
“The issue is exploitable only after an authentication bypass and only when a specific parameter is enabled; that setting is not enabled by default.”
At that point, defenders can begin to establish real priorities.
Expensive, indiscriminate patch-everything responses can become targeted remediation.
There is another important point.
Non-disclosure does not mean disappearance.
An exploit that is not publicly released does not cease to exist. It may instead remain concentrated among state-sponsored actors, exploit brokers, initial-access sellers, or a small number of private research teams.
Silence does not create the absence of a vulnerability.
It creates concentration of ownership and capability.
Public research cannot completely eliminate that imbalance, but it can at least give defenders, educators, and legitimate researchers a foundation on which to validate the same techniques and build defenses against them.
There are also many cases in which a vendor patch can be bypassed, or where the same underlying vulnerability must be fixed multiple times.
Attackers can begin diffing the moment a patch becomes available, using AI as an accelerator to turn technical changes into working exploitation.
Refusing to give defenders equivalent means of validation is like asking them to defend a system without instrumentation.
So we changed the question.
“Should the ability to read the vulnerability map remain exclusively in the hands of those who already know how?”
SAGO was created to answer that question.
3. Why We Publish, Part II: LLMs Did Not Make Only Attackers Faster
Earlier, I wrote that LLMs have dramatically accelerated the process of reconstructing vulnerabilities from patches.
That is only half the story.
LLMs are accelerating defenders as well.
And that second half is one of the reasons we decided to build this project.
Consider what has already happened on the defensive side.
Governments and enterprises around the world have already begun treating AI as an applied tool and building AI capabilities into their organizations.
In August 2025, the U.S. General Services Administration signed three government-wide agreements within a three-week period (GSA): ChatGPT Enterprise from OpenAI at $1 per agency per year, Claude from Anthropic for $1 across the executive, legislative, and judicial branches, and Gemini for Government from Google at $0.47 per agency.
The private sector is moving in the same direction.
JPMorgan Chase has deployed its internal LLM Suite to more than 200,000 employees. Goldman Sachs, after an initial pilot involving 10,000 employees, made its AI assistant available to approximately 46,000 employees across the firm in 2025.
Korea is no exception. In some respects, regulation and policy are moving ahead of the market.
- April 2026: The Financial Services Commission and Financial Supervisory Service amended the Enforcement Rules of the Electronic Financial Supervisory Regulations, allowing financial institutions to use SaaS within internal business networks without undergoing a separate approval process.
*> - May–June 2026: Emergency easing of network-separation requirements was introduced, and AI security testing began.
*> - May 2026: The Financial Services Commission convened the chairpersons of Korea’s five major financial groups to discuss emerging security threats associated with frontier AI systems, including Anthropic’s Claude Mythos.
*> - July 2026: At an event hosted by the Financial Security Institute, the chairman stated:
“Traditional reactive approaches—closing networks and restricting access—cannot keep pace with evolving AI-powered attacks. We need a system in which ‘AI attacks are defended against with AI.’” (FSC)
Xint, an AI-based vulnerability detection solution developed by Theori, one of the world’s top-tier security companies, has also been adopted by major enterprises and first-tier financial institutions including Samsung, POSCO, and Woori Financial Group.
AI in the hands of defenders can, depending on the model, discover vulnerabilities through its own capabilities.
But in many other cases, the quality of the reference material available to the model becomes critically important.
We already see something similar in CTFs: when 1-day challenges appear, participants often solve them by searching for publicly available 1-day research and using those references to understand the vulnerability.
4. What N4C Publishes
SAGO covers only CVEs for which the vendor has already released a patch. We do not publish undisclosed vulnerabilities or 0-days.
In other words, if there is no patch, we do not cover it.
SAGO reports are published in both Korean and English.
Each report is managed under an identifier such as SG-2026-0001.
A report records information including the vulnerability class, severity, disclosure status, availability of a PoC, availability of an exploit, tags, public references, and the full technical analysis.
At present, SAGO tracks vulnerabilities in the following categories:
- RCE
- LPE
- Information Leak
- DoS
- Escape
SAGO treats PoCs and exploits as separate classes of artifacts.
A PoC exists to demonstrate that a vulnerability exists and can be reproduced.
As a general rule, the PoC associated with a SAGO report is released alongside the report itself.
The purpose is to allow defenders and researchers to understand the conditions and impact of the vulnerability more precisely.
An exploit, by contrast, can much more directly increase offensive capability.
For that reason, N4C applies a 90-day delay before exploit code is considered for release.
Our baseline disclosure timeline is therefore:
PoC: Released with the report
Exploit: Eligible for release 90 days after the report
Exploit Release Decisions
SAGO does not decide whether to release an exploit solely on the basis of vulnerability class or the amount of time that has elapsed since a patch was released.
Before publication, we conduct an internal review of real-world exploitability and the potential scope of harm.
Where the risk is considered too high, exploit publication may be restricted or withheld entirely.
Our primary review criteria include:
1. Attack prerequisites: authentication, a local account, specific privileges, network position, or other conditions required for exploitation2. User interaction: whether exploitation requires the victim to execute a file, click a link, open a document, or perform another action3. Attack complexity and reproducibility: whether the published exploit can be used easily without further analysis or modification4. Remote exploitability: whether the vulnerability can be exploited directly over the Internet or a general network connection5. Scope of exposure: the number and prevalence of products and systems affected under default configurations6. Severity of impact: potential RCE, privilege escalation, sandbox or container escape, service disruption, information disclosure, and related outcomes7. Exploit reliability: whether exploitation can be repeated consistently with a high success rate8. Chaining potential: whether the vulnerability could serve as a critical primitive when combined with other vulnerabilities9. Patch availability: whether security updates are genuinely available for supported products and versions10. Evidence of exploitation in the wild: whether the same or a similar vulnerability is actively being exploited
These criteria are combined with the following internal publication controls:
1. Two-person approval: publication requires review and approval from at least two members
2. Staged disclosure: root-cause analysis and a constrained PoC are released first; the exploit is reviewed again only after a separate waiting period
3. Emergency withdrawal: if active exploitation, a patch rollback, or a newly discovered impact is identified after publication, exploit downloads can be disabled immediately
4. External reporting: a clearly identified abuse/security contact allows third parties to report active exploitation or unexpected risks quickly
We treat several classes of vulnerabilities as particularly high-risk:
RCEs that can be exploited remotely without authentication or user interaction, escapes that directly cross a security or isolation boundary, and remote DoS vulnerabilities that can repeatedly disrupt services from an external position.
Even after the normal waiting period has elapsed, we may choose not to publish exploits for vulnerabilities in these categories.
Where appropriate, we may disclose only the root cause, patch analysis, and constrained reproduction information necessary for defensive and research purposes, while withholding the full exploit.
SAGO publishes an exploit only when we determine that its technical value to security research and defense sufficiently outweighs the anticipated risk of abuse.
4.1 Who the 90 Days Are For
Google Project Zero’s 90-day policy exists primarily to create pressure on vendors to fix reported vulnerabilities (Project Zero).
Without a published deadline, there is often little incentive to move quickly.
SAGO’s 90-day period is aimed at a different actor:
the organizations responsible for applying the patch.
Simply announcing that “an exploit will be released in 90 days” does not, by itself, provide defenders with anything comparable to a useful advisory.
That is why SAGO publishes the root-cause analysis and PoC first—during those 90 days—so defenders have actionable technical information before the exploit becomes eligible for release.
After more than a decade of coordinated disclosure, Project Zero observed that many fixes still took more than six months and some vulnerabilities were never fixed at all. The team concluded that deadlines helped create a healthier balance of incentives.
According to Project Zero, one vendor improved response times by 40%, while another doubled the frequency of its security update cycle.
Project Zero also applies an additional 30-day period after a vendor patch has been released.
That phase serves a different purpose: P0 has stated that it hopes this additional period will help incentivize patch adoption across the ecosystem (Project Zero).
That 30-day period is the closest analogue to SAGO’s own waiting period.
We place 90 days in that position—three times as long.
Our approach has been informed in significant part by disclosure practices and policies used by organizations such as Google Project Zero and CERT/CC.
5. Closing
At first, SAGO may not contain a large number of reports. What matters more to us is quality—and whether the system actually works.
The purpose of SAGO is to analyze vulnerability information according to a consistent standard, preserve it in a form that remains useful over time, and distinguish clearly between information that can be safely disclosed and information that requires additional review.
N4C’s 1-day research reports will continue to be published on SAGO over time.
We are not claiming that exploit disclosure is absolutely safe.
Our position is that controlled disclosure—while acknowledging and managing its risks—can create greater defensive value than permanently keeping offensive knowledge private and concentrated among a small number of actors.
We may also be wrong.
If part of this policy proves to have been poorly designed, we will change it.
We will continue to monitor the real-world impact of SAGO.
If you discover a bug, unexpected behavior, or another issue, please contact us at:
h4cish4c@gmail.com
We hope SAGO becomes more useful to defenders, learners, and good-faith researchers than it ever is to attackers.
SAGO: https://sago.h4c.team
TeamH4C N4C
6. Appendix: Anticipated Questions and Responses
The sections above describe our design.
There are, however, legitimate objections that remain.
We want to address them directly.
6.1 “If It Can Be Easily Used for Attacks, It Should Not Be Published.”
First, consider where that principle leads if applied consistently.
Metasploit contains thousands of working exploit modules. It is maintained by a NASDAQ-listed company, and a commercial version is sold as a product.
Kali Linux goes even further by packaging an extensive collection of offensive security tools into a single distribution.
Certifications such as the OSCP formally assess practical proficiency in this broader offensive security toolset and methodology.
And these tools have not, simply by virtue of being published or distributed, been treated as unlawful under Korea’s Information and Communications Network Act.
The global security industry does not broadly prohibit Metasploit because it believes the platform is risk-free.
It accepts the offensive risk while recognizing substantial defensive value, including:
Validating whether a scanner-reported vulnerability is actually exploitablePrioritizing patchesPenetration testing and red-team trainingTesting security controls and detection capabilitiesUnderstanding the real-world impact of vulnerabilitiesReproducibility and standardization in security research
If the possibility of offensive use were sufficient grounds for prohibiting publication entirely, the same logic would need to be applied to Metasploit, IDA, Ghidra, pwntools, fuzzers, GitHub, Kali Linux, and much of the modern offensive-security ecosystem.
The principle the security community has actually adopted is not prohibition.
It is responsible disclosure and controlled use.
There is, of course, an obvious counterargument:
Metasploit modules often implement vulnerabilities whose technical details are already public, whereas SAGO may sometimes become the first source to publish a working exploit.
That criticism is partly correct.
But once we accept it, the nature of the debate changes.
It is no longer simply:
“Should exploit code ever be published?”
The question becomes:
“When should it be published, and in what sequence?”
The Metasploit argument does not prove that SAGO is automatically justified.
It demonstrates that the central question is not the mere existence of exploit publication, but its timing and the controls surrounding it.
And timing is precisely what our disclosure policy in Section 4 is designed to address.
6.2 “Publishing Exploits Increases the Number of Attackers.”
That is true.
But one side of the equation is missing.
Publication also increases the number of people capable of defending against the vulnerability.
To evaluate the impact of disclosure properly, both effects need to be considered.
The relevant question is:
Which increases more: the offensive capability created by SAGO, or the defensive capability created by SAGO—and how can the disclosure process be structured so that the difference favors defenders?
An argument that calculates only the marginal benefit to attackers while ignoring the marginal benefit to defenders successfully identifies a risk.
It does not establish that the net effect of disclosure is negative.
We should also consider who the newly enabled attackers actually are.
By definition, the attackers added by public exploit availability are those who could not have independently developed the exploit themselves.
Nation-state actors and sophisticated ransomware groups are generally not being added to that population.
They either already possess the capability or can develop it independently.
There is another asymmetry.
Attackers who reuse public exploit code can also expose themselves to the detection logic built around that public implementation, including ASM and other published defensive signatures.
A sophisticated attacker using a privately developed implementation may not match those signatures at all—and that attacker existed independently of the publication.
The two edges of the sword do not necessarily cut the same population.
6.3 “What About Organizations That Still Cannot Patch After 90 Days?”
We will not deny the risk here.
Some organizations that remain unpatched after SAGO’s 90-day waiting period may become easier to attack once an exploit is published.
But that fact does not automatically lead to the following conclusion:
“As long as even one vulnerable system remains unpatched, vulnerability research must never be fully disclosed.”
Under that standard, there would effectively never be an appropriate time to publish.
The objective of a vulnerability disclosure policy is not to reduce risk to zero.
That is impossible.
The goal is to allocate responsibility reasonably.
Responsible disclosure therefore does not mean risk-free disclosure.
It means ensuring that defenders receive a meaningful opportunity to prepare before additional offensive capability is released.
We are not making the excessive claim that a publisher bears no responsibility once 90 days have passed.
But the opposite claim—that research must remain permanently sealed as long as any unpatched organization exists—is equally excessive.
And one fact remains:
Those organizations were given 90 days of validated technical information at no cost—information they may not have had without SAGO.
There is another point worth considering.
High-quality 1-day research blogs and archives already exist around the world.
Some companies sell comparable technical research at significant prices, both in Korea and internationally.
Anyone who has spent time in offensive security is familiar with this market.
So another question follows:
If the same technical analysis is distributed commercially, does it become “threat intelligence,” while publishing it for free becomes irresponsible?
It is not the price tag that makes vulnerability research exploitable.
It is the technical content.
An exploit in a paid report is not inherently less dangerous than the same exploit in a free report.
If selling such research can be legitimate, the relevant standard for SAGO should not simply be:
“You must not publish it.”
It should instead be:
“Under what conditions should it be published?”
And on that question, we deliberately apply conservative controls.
We give defenders the root-cause analysis and PoC first.
We provide a 90-day lead time.
We exclude full weaponization features.
We publish our disclosure policy and maintain a record of our decisions.
With paid intelligence products, the public generally cannot know whether equivalent safeguards are applied.
6.4 In Summary
The fact that an exploit can be used offensively is not, by itself, sufficient grounds for prohibiting its publication.
If it were, much of the modern security-validation ecosystem—including Metasploit—could not exist.
The key question is not simply whether something is published.
It is who gets the opportunity to prepare first, what level of capability is disclosed, in what sequence, and under what safety policy.
SAGO is designed to give defenders root-cause analysis, a constrained PoC, and at least 90 days of lead time before any exploit is subsequently considered for release.
Our goal is to ensure that defensive capability begins spreading before additional offensive capability does.
We also subject exploit publication itself to a separate risk review before making a final decision.
This is not a claim that exploit publication is inherently or universally safe.
Responsibility ultimately lies in how a capability is used.
Our position is that, while acknowledging the risks, controlled disclosure can create more defensive value than permanent non-disclosure.
6.5 What “SAGO” Means
The name SAGO carries two meanings in Korean.
The first comes from 사고 in the sense of an incident or accident.
In security, a vulnerability does not necessarily remain a mere defect in code.
A patch is released.
A PoC appears.
An exploit follows.
And eventually the vulnerability may become part of a real-world attack.
SAGO is intended to preserve and document these security events rather than letting them disappear into the stream of disclosures.
The second meaning comes from 사고하다—to think, reason, or reflect.
SAGO is not intended merely to collect vulnerability information.
It is a place to continuously ask why a vulnerability matters, under what conditions it can be reproduced, and what conclusions can responsibly be drawn from the information that has been made public.
In that sense, SAGO is both:
a platform for recording security incidents, and a platform for thinking critically about them.
Thank you.
Works Cited
CERT Coordination Center. “Vulnerability Disclosure Policy.” CERT Coordination Center, Carnegie Mellon University,
certcc.github.io/certcc_disclosure_policy/. Accessed 3 Aug. 2026.
Charrier, Casey, and Robert Weiner. “How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends.” Google Cloud Blog, Mandiant, 15 Oct. 2024,
cloud.google.com/blog/topics/threat-intelligence/time-to-exploit-trends-2023.
Collins, Georgia. “How JPMorgan Is Embedding AI into Employee Performance.” AI Magazine, BizClik Media, 10 Nov. 2025,
aimagazine.com/news/how-jpmorgan-is-embedding-ai-into-employee-performance.
“From Vulnerability to Exploitation.” Zeroday Clock, zerodayclock.com. Accessed 3 Aug. 2026.
“Full-Scale AI Transformation in the Financial Sector: Easing Network Separation Regulations to Broaden Innovation and Strengthen Security — Roundtable on Financial Sector Security Threats Related to High-Performance AI.” Financial Services Commission of Korea, 26 May 2026,
fsc.go.kr/po010101/86972.
Google Project Zero. “Vulnerability Disclosure Policy.” Project Zero, Google,
projectzero.google/vulnerability-disclosure-policy.html. Accessed 3 Aug. 2026.
———. “Vulnerability Disclosure FAQ.” Project Zero, Google, last updated 29 July 2025,
projectzero.google/vulnerability-disclosure-faq.html.
“GSA, Google Announce Transformative ‘Gemini for Government’ OneGov Agreement.” U.S. General Services Administration, 21 Aug. 2025,
www.gsa.gov/about-gsa/newsroom/news-releases/gsa-google-announce-gemini-onegov-agreement-08212025.
“GSA Propels Government into AI Revolution with Addition of Leading Solutions to Multiple Award Schedules.” U.S. General Services Administration, 5 Aug. 2025,
www.gsa.gov/about-gsa/newsroom/news-releases/gsa-propels-government-into-ai-revolution-with-addition-of-leading-solutions-08052025.
Jurczyk, Mateusz. “Using Binary Diffing to Discover Windows Kernel Memory Disclosure Bugs.” Project Zero, Google, 5 Oct. 2017,
projectzero.google/2017/10/using-binary-diffing-to-discover.html.
Kang, Ryu-na. “Lee Eok-won: Full Lifting of Network Separation Rules for Financially Secure Firms.” Yonhap News, 10 July 2026. Financial News,
www.fnnews.com/news/202607100830241506.
Park, Mun-su. “Emergency Easing of Network Separation Rules for Mythos-Response AI: FSC Also Reviewing Full Lifting.” Financial News, 24 May 2026,
www.fnnews.com/news/202605241114438761.
Stone, Maddie. “TFW You-Get-Really-Excited-You-Patch-Diffed-a-0day-Used-in-the-Wild-but-Then-Find-Out-It-Is-the-Wrong-Vuln.” Project Zero, Google, 2 Apr. 2020,
projectzero.google/2020/04/tfw-you-get-really-excited-you-patch.html.