Hunting Half-Day Vulnerabilities: The Dangerous Gap Between CVE Publication and Patch Release
Hook
When Log4Shell was disclosed, there was a dangerous gap between the public fix and patch release. That gap? It’s called a half-day vulnerability, and it’s a goldmine for attackers.
Context
The traditional vulnerability disclosure timeline assumes a clean handoff: researchers find a bug, vendors patch it, a CVE gets published, and security teams update their systems. Reality is messier. Modern open-source development happens in public—commits land on GitHub, pull requests discuss security implications, issues detail exploitation techniques—all before official releases ship. The National Vulnerability Database might publish a CVE with GitHub references, giving everyone a roadmap to vulnerable code, while the patched version sits unreleased in the main branch.
This creates what security researchers call a ‘half-day’ vulnerability: known to those paying attention, fixed in code but not in releases, and exploitable by anyone who notices the disconnect. CVE Half-Day Watcher, developed by Aqua Nautilus, automates the detection of this dangerous window. It’s a proof-of-concept tool that scans both the NVD feed for recently published CVEs with GitHub references and specific repositories for security-related issues that might not have CVE assignments yet. The goal isn’t just alerting—it’s demonstrating how trivially attackers can harvest early vulnerability intelligence from public sources.
Technical Insight
CVE Half-Day Watcher operates in two distinct modes, each addressing a different facet of early vulnerability exposure. The first mode, NVD feed scanning, leverages the National Vulnerability Database (NVD) API for CVEs published within a configurable time window (default: 3 days). For each CVE, it extracts GitHub references—commits, pull requests, or issues—from the CVE description metadata. Here’s where it gets interesting: the tool then queries GitHub’s API to determine whether the referenced commit has been included in any official release.
The implementation is straightforward Python, but the logic reveals the gap. When you run the tool in feed mode, you’re essentially asking: ‘Show me vulnerabilities where the fix is public but the release isn’t.’
python scan.py --github_token YOUR_GITHUB_TOKEN --mode feed --days 7 --min_stars 500This command scans the last 7 days of NVD publications, filtering for repositories with at least 500 stars (a proxy for impact—compromising a widely-used library matters more than a hobby project). The --min_stars parameter is crucial for signal-to-noise ratio. Without it, you’d drown in CVEs for abandoned repositories where the half-day window is irrelevant because nobody’s using them anyway.
The second mode, repository scanning, takes a proactive approach. Instead of waiting for NVD to publish CVEs, it monitors specific repositories for security-relevant issues and pull requests using keyword matching. This catches vulnerabilities before they get CVE identifiers—the true zero-to-half-day transition:
python scan.py --github_token YOUR_GITHUB_TOKEN --mode repo --repo_full_name kubernetes/kubernetes --openai_token YOUR_OPENAI_KEYThe keyword matching uses a word-matching algorithm—searching titles and bodies for security-related terms—but the optional OpenAI integration adds a validation layer. When enabled, the tool sends suspicious issues to OpenAI’s API for semantic analysis, filtering out false positives like ‘vulnerability to user confusion’ or ‘exploiting performance optimizations’. This is particularly valuable for high-traffic repositories where security-adjacent language appears frequently in non-security contexts.
The architecture is intentionally simple—no database, no complex state management—making it easy to extend or integrate into existing security pipelines. The output flags CVEs or issues where the vulnerability details are public but the patch isn’t broadly available, creating an actionable list of ‘harvest targets’ that attackers might be exploiting.
The most powerful insight from this tool isn’t the code itself—it’s what it reveals about the vulnerability disclosure ecosystem. The screenshot in the repository shows results from November 2, 2023, identifying 5 half-day vulnerabilities in a single scan. Each represents a window where defenders running scheduled vulnerability scans would show ‘no issues’ while attackers with this data could be developing exploits. The Log4Shell timeline included in the documentation perfectly illustrates this: the vulnerable code was identified and fixed in commits before the CVE was even assigned, creating a multi-day window where the information asymmetry favored attackers.
Gotcha
CVE Half-Day Watcher is explicitly labeled a proof of concept, and that positioning is honest about its limitations. The keyword matching for repository scanning is rudimentary—terms like ‘security’ or ‘vulnerability’ appear in countless non-security contexts, generating false positives that require manual triage. Even with OpenAI validation, you’re trading API costs and latency for better (but not perfect) precision. If you’re monitoring dozens of high-velocity repositories, the signal-to-noise ratio becomes a problem.
The bigger limitation is structural: the tool only detects vulnerabilities that leave GitHub breadcrumbs. CVEs disclosed through mailing lists, private security trackers, or vendors who don’t reference GitHub commits in NVD entries won’t appear. You’re also dependent on NVD’s update cadence and GitHub API rate limits. For production security monitoring, you’d need significant hardening and more sophisticated natural language processing than simple keyword matching. This is a research tool that demonstrates a vulnerability disclosure problem, not a turnkey monitoring solution.
Verdict
Use CVE Half-Day Watcher if you’re a security engineering team responsible for open-source supply chain risk and need visibility into the dangerous window between public vulnerability disclosure and patch availability. It’s particularly valuable if you maintain an inventory of critical dependencies and want early warning when fixes exist but releases don’t—giving you time to explore backports, vendor patches, or compensating controls before exploits hit the wild. The repository scanning mode is useful for maintainers of high-profile projects who want to catch security issues in their own repos before they get CVE assignments and wider attention. Skip it if you need production-grade, low-maintenance vulnerability monitoring with comprehensive coverage and minimal false positives—this is a proof of concept that requires customization and manual oversight. Also skip it if your dependencies aren’t primarily GitHub-based open source. This tool’s real value is educational: run it once to see how much vulnerability information is publicly harvestable before patches ship, and you’ll never think about disclosure timelines the same way.
