Zero-Day Without a Patch: How to Respond When Vendors Can't Keep Up With Mythos-Era Discovery

A vulnerability is disclosed. Proof-of-concept code surfaces. Your security team confirms affected systems. The vendor says a patch is coming, but it is not available yet. That gap, between knowing about the risk and having an official fix, is where exposure remains open. Zero-day without a patch scenarios can arise when Mythos-era discovery surfaces a vulnerability before an approved vendor fix is ready.

Waiting alone leaves exposure unresolved. Teams need a documented decision on whether to mitigate, isolate, or formally accept the remaining risk. A pre-patch response model can help reduce exploitability through available controls, validate whether those controls are holding, and keep leadership informed until a permanent fix arrives. For more context on why response speed matters, see our analysis of the vulnerability remediation response gap.

The New Gap: Discovery Before Vendor Remediation

Vendors and maintainers need time to reproduce a vulnerability, assess its impact, develop a safe fix, test for unintended consequences, and coordinate disclosure. Even when that process works as intended, security teams may learn that exposure exists before an approved patch is ready for deployment.

Anthropic reports that Claude Mythos Preview has identified vulnerabilities at significant volume, including thousands of high- or critical-severity findings across partner and open-source software. Anthropic's Project Glasswing update also describes human capacity to verify, disclose, and patch those findings as a growing bottleneck.

As discovery volume increases, vendors and maintainers may face greater pressure to verify findings and develop safe fixes. A vendor patch delay does not necessarily indicate a failure in the vendor process; safe remediation takes development and testing. Organizations that only know how to respond with a patch therefore have a gap in their operating model. The practical question is what to do with confirmed exposure in the time between disclosure and an approved vendor fix.

What a Zero-Day Without a Patch Should Trigger Operationally

The moment a zero-day is confirmed with no vendor patch available, three operational workstreams should run in parallel.

The first is exposure assessment. Which endpoints are running the affected software in the affected configuration? An accurate, current inventory is the prerequisite for everything that follows. Without it, mitigation effort cannot be targeted and validation cannot be meaningful. The scope of the affected population determines the urgency and the resource requirement for response.

The second is mitigation planning. Based on the nature of the vulnerability, what controls are available? Options may include disabling the vulnerable component or service, enforcing a safer configuration, restricting network access, removing affected software where operationally feasible, or isolating endpoints where the risk is unacceptable without a fix. The appropriate control depends on the advisory, application dependencies, business criticality, and testing results.

A compensating control is not equivalent to a permanent fix. Its purpose is to reduce exploitability while the vendor patch is developed, tested, and deployed. Teams should document the control's limitations and the residual risk that remains.

The third is validation planning. Before deploying a mitigation, the team needs a method for checking whether the required state was achieved on targeted endpoints. A deployment record alone does not establish that exposure was reduced. Post-action endpoint evaluation and ongoing monitoring help identify systems that still require attention.

Why Custom Remediation Matters

When no vendor patch exists, pre-built patch content cannot provide the permanent fix. For organizations using BigFix, custom Fixlet remediation can support approved temporary endpoint actions while a vendor fix is unavailable.

Custom Fixlets allow security and IT teams to define endpoint conditions and approved actions for a specific mitigation. Relevance criteria can identify affected software, versions, configurations, or services, while the action can apply the temporary control selected through the organization's response process.

This supports more precise targeting. A custom Fixlet can use defined relevance criteria to target endpoints that match the affected software or configuration conditions. That matters in a no-patch scenario because a temporary mitigation may introduce operational trade-offs and should be applied only where the approved conditions are met.

Custom Fixlet content developed during one event may provide a reusable starting point for a similar future scenario, subject to technical validation, testing, and change approval. Teams should treat each use as a controlled endpoint action rather than assume that a previous mitigation applies unchanged.

How the BigFix Agent Helps Reduce Operational Delay

The speed at which a mitigation reaches affected endpoints depends on deployment infrastructure, endpoint connectivity, action configuration, and operational approvals, not just the content of the mitigation itself. Teams need a deployment model that can extend approved actions across the managed population while maintaining visibility into systems that have not yet reported an outcome.

The BigFix agent evaluates relevance on managed endpoints and executes approved custom Fixlet remediation when defined conditions are met. This distributed approach can help teams extend remediation across endpoints operating under different network conditions.

Deployment timing still depends on factors such as connectivity, infrastructure design, action settings, and change controls. Teams should monitor action status and investigate endpoints that have not reported a validated outcome. In a zero-day without a patch scenario, that visibility is essential for understanding residual exposure.

What to Prove After Taking Action

Acting without proof of effect is operationally incomplete. Once mitigation actions have been deployed, teams need to confirm three things: that the action succeeded on each targeted endpoint, that the mitigation is holding over time, and that the affected population is fully covered.

Confirmation that the action succeeded requires evaluating endpoint state after deployment, not relying on deployment logs alone. An action sent to an endpoint and a mitigation confirmed as applied are different outcomes. Post-action endpoint evaluation can help teams determine whether the required state was achieved and identify systems that still require attention.

Confirmation that mitigation is holding requires ongoing monitoring rather than a one-time check. Endpoint state changes, software is reinstalled, and configurations drift. Evidence against the defined mitigation state can help teams identify when a previously protected endpoint requires further action. For a deeper treatment, see our guide to continuous compliance and endpoint drift management.

Confirmation that the affected population is fully covered requires comparing the validated remediated population against the original exposure scope. Endpoints that were in scope but did not receive or confirm the mitigation represent residual exposure that needs to be tracked explicitly.

When to Escalate to Risk Reporting

Not every zero-day without a patch will be fully mitigated within the initial response period. Some vulnerabilities will have no available compensating control that is operationally acceptable. Some affected endpoints will have dependencies that prevent mitigation deployment. Some exceptions will be formally accepted pending vendor patch availability. Each of those outcomes represents residual exposure that belongs in risk reporting, not just in operational tracking.

Vulnerability risk prioritization can add context to unresolved exposure using signals such as known exploitation, exploit likelihood, asset importance, and the number of affected systems. HCL BigFix CyberFOCUS can support that prioritization within the broader remediation process. Leaders can then use the resulting context to inform decisions about exceptions, resources, and escalation.

When residual exposure from a zero-day without a patch requires leadership visibility, the relevant information includes which business-critical systems remain unmitigated, what compensating controls are in place, what residual risk remains, and which decisions are needed. For a fuller treatment of translating that operational picture into executive reporting, see our CISO guide to endpoint exposure management in the Mythos era.

Conclusion

Zero-day without a patch is a scenario organizations should be prepared to manage as Mythos-era discovery increases the volume and pace of vulnerability findings. A pre-patch response model, exposure assessment, approved temporary controls, post-action validation, ongoing monitoring, and documented residual risk, helps replace passive waiting with governed action.

HCL BigFix can support this model through custom endpoint actions, distributed agent-based execution, and post-action validation. These capabilities help teams manage temporary mitigations and maintain visibility while a permanent vendor fix is developed and deployed. Learn more about zero-day remediation without a vendor patch.

Talk to HCLBigFix about zero-day remediation readiness. Contact us.