CVE Half-Day Watcher: Monitoring the Dangerous Gap Between Vulnerability Disclosure and Patch Release

Hook

The average time between a CVE being published with a public fix and an official release containing that fix? Often days or weeks—a window where attackers have the roadmap but defenders have no patch to deploy.

Context

Modern vulnerability disclosure operates on a gentleman's agreement: researchers find bugs, maintainers fix them privately, and CVEs are published alongside patched releases. But this coordinated dance frequently breaks down. A security researcher publishes a CVE referencing a GitHub commit or pull request that fixes the vulnerability. The problem? That fix might live in the main branch for days or weeks before maintainers cut an official release. During this 'half-day' window, the vulnerability is fully disclosed—attackers can reverse-engineer the exploit from the patch itself—but there's no official version number defenders can upgrade to.

This isn't theoretical. High-profile projects regularly ship CVE fixes in commits while releases lag behind. Security teams monitoring CVE feeds see the alert, check their dependency versions, find they're on the 'latest' release, and assume they're safe—unaware that 'latest' is already vulnerable by disclosure standards. CVE Half-Day Watcher emerged from Aqua Security's Nautilus research team to automate the detection of exactly this scenario: correlating NVD CVE publications with GitHub activity to identify when fixes exist in code but not in releases. It also flips the script, proactively scanning repositories for security-related discussions that might become CVEs tomorrow.

Technical Insight

CVE Half-Day Watcher implements two distinct scanning modes, each solving a different aspect of the half-day problem. The architecture is straightforward Python with API orchestration at its core—no fancy frameworks, just disciplined API polling and correlation logic.

The NVD feed scanner mode polls the National Vulnerability Database API for recently published CVEs (configurable lookback window, default 7 days). For each CVE, it parses the references section looking for GitHub URLs—commits, pull requests, or issues. Here's where it gets interesting: the tool doesn't just flag that a CVE exists. It extracts the repository from those GitHub URLs, queries the GitHub API for all releases, and checks timestamps. If the CVE references a commit that's newer than the latest release, you've found a half-day vulnerability. The fix is public, merged, and documented in a CVE, but end users have no release to upgrade to.

The correlation logic is elegantly simple but powerful:

# Simplified correlation logic from the scanner
def check_half_day_status(cve_data, github_refs):
    for ref in github_refs:
        if ref['type'] == 'commit':
            commit_date = get_commit_date(ref['url'])
            repo = extract_repo_from_url(ref['url'])
            latest_release = get_latest_release(repo)
            
            if latest_release is None:
                # No releases exist - all fixes are unreleased
                flag_half_day(cve_data, "No releases found")
            elif commit_date > latest_release['published_at']:
                # Fix exists but hasn't been released
                days_gap = (datetime.now() - commit_date).days
                flag_half_day(cve_data, f"Fix unreleased for {days_gap} days")

This pattern—correlating temporal data across multiple APIs—is the tool's core value proposition. The NVD API gives you vulnerability metadata, but it doesn't tell you whether the fix is actually shippable. GitHub gives you release history, but it doesn't connect that to security implications. CVE Half-Day Watcher is the glue.

The second mode—repository scanning—takes a more proactive approach. Instead of waiting for CVEs to be published, it monitors GitHub repositories directly for security-related activity that hasn't been assigned a CVE yet. The tool accepts a list of repositories and scans open pull requests and issues, looking for security keywords: 'vulnerability', 'exploit', 'CVE', 'security fix', 'patch', etc. This is where the proof-of-concept nature shows:

# Basic keyword matching for potential vulnerabilities
SECURITY_KEYWORDS = [
    'vulnerability', 'exploit', 'CVE', 'security',
    'injection', 'XSS', 'CSRF', 'authentication bypass',
    'privilege escalation', 'remote code execution'
]

def scan_repo_for_potential_vulns(repo_name, min_stars=100):
    repo_data = github_api.get_repo(repo_name)
    if repo_data['stargazers_count'] < min_stars:
        return []  # Skip low-impact repos
    
    potential_vulns = []
    open_prs = github_api.get_pulls(repo_name, state='open')
    
    for pr in open_prs:
        text = f"{pr['title']} {pr['body']}".lower()
        if any(keyword in text for keyword in SECURITY_KEYWORDS):
            potential_vulns.append({
                'type': 'PR',
                'url': pr['html_url'],
                'title': pr['title'],
                'match': 'keyword'
            })
    
    return potential_vulns

The minimum stars filter is crucial for noise reduction—scanning every repository on GitHub would produce overwhelming false positives. By focusing on popular projects (default 100+ stars), the tool targets vulnerabilities that would have broad impact.

Optional OpenAI integration adds a validation layer. Instead of just keyword matching, the tool can send PR/issue text to GPT models with a prompt asking: 'Is this actually a security vulnerability?' This reduces false positives but introduces API costs and latency. The architecture makes this optional—you can run in pure keyword mode for speed and cost, or enable AI validation for precision.

The tool outputs JSON reports with structured data about each finding: CVE ID, affected repository, GitHub references, release status, and the calculated gap in days. This makes it trivial to integrate into existing security workflows—pipe the JSON into Slack alerts, JIRA tickets, or security dashboards. The emphasis is on machine-readable output, not human-friendly reports.

Gotcha

This is explicitly labeled a proof-of-concept, and it shows. The keyword matching for repository scanning is primitive—any PR mentioning 'security' gets flagged, even if it's just updating a security policy document. Without the OpenAI validation (which costs money per API call), expect significant false positives that require manual triage. The tool doesn't learn or improve its detection over time; it's stateless keyword matching on every run.

The reliance on structured GitHub references in NVD entries is a fundamental limitation. If a CVE doesn't explicitly link to a GitHub commit or PR in its references—maybe it just mentions a version number, or links to a vendor security advisory—the tool misses it entirely. This isn't a flaw in the code; it's a constraint of the NVD data model. Many CVEs, especially for projects with poor disclosure practices, lack the GitHub metadata this tool depends on. You're also at the mercy of API rate limits. GitHub's unauthenticated API allows 60 requests per hour; authenticated bumps that to 5,000. For scanning multiple repositories or processing large CVE batches, you'll hit limits quickly without proper token management and request throttling. The codebase doesn't include sophisticated rate limit handling—you'll need to add that yourself for production use.

Verdict

Use if: You're a security researcher or DevSecOps team monitoring critical open-source dependencies and need automated alerts for the specific window between vulnerability disclosure and patch availability. This is particularly valuable if your threat model includes attackers who monitor CVE feeds and reverse-engineer exploits from patch commits—sophisticated adversaries absolutely do this. The repository scanning mode is useful for maintainers of popular projects who want early warning when security discussions emerge in their ecosystem before CVEs are assigned. Skip if: You need production-ready, low-maintenance vulnerability monitoring with minimal false positives. This tool requires customization, tuning, and manual triage. If you're looking for comprehensive vulnerability coverage beyond GitHub-hosted projects, or if you need commercial-grade accuracy without the effort of customizing keyword lists and validation logic, established tools like Snyk or Trivy are better fits. Also skip if you're uncomfortable running proof-of-concept security tooling—this isn't hardened software, it's a research artifact meant for experimentation and customization by people who understand its limitations.