Unknown vulnerabilities make early progression detection essential

The next critical vulnerability may not be in your vulnerability feed yet.

That is not a reason to lower the priority of patching. It is a reason to be honest about what patching can and cannot do.

Vulnerability management is essential when a flaw is known, understood, and can be remediated quickly. But organisations also operate during the period before a flaw is discovered, while a patch is being developed, and while remediation is still moving through complex environments.

That period is becoming more important.

Recent work on AI-assisted vulnerability discovery, including Anthropic's Mythos Preview research, shows why this assumption deserves renewed attention. Even allowing for uncertainty about the capability and availability of any individual model, the time between an undiscovered flaw, a working exploit, and attempted use may shrink.

For security leaders, the question is not only:

How quickly can we patch the next known vulnerability?

It is also:

If an attacker gets in before we can patch, can we see them progressing toward sensitive data?

Unknown flaws create a decision gap

When a vulnerability is known, security teams can assess exposure, prioritise remediation, and apply mitigations. Those actions remain indispensable.

When a vulnerability is unknown, those decisions begin later. A team may only learn that it was exposed after a suspicious event, a vendor advisory, an incident response engagement, or a breach notification.

This does not make vulnerability management futile. It makes defence in depth more important. Organisations need to reduce what a compromised system can reach and be able to recognise the movement from initial access toward high-consequence data while remediation catches up.

The first question after an exploit is not only, "Which systems need a patch?" It is also, "What did the vulnerable system make reachable before we knew it was vulnerable?"

That is a data-risk question, not simply a CVE-management question.

The first foothold is not the whole attack

A vulnerability is an entry condition. A data breach is an outcome.

Between the two, an attacker has work to do. They may enumerate permissions, use a service account, assume a role, find a connected system, access a secret, invoke an integration, or identify a path to customer, financial, workforce, or operational data.

Those steps determine whether the initial foothold becomes material.

This is especially important in cloud and enterprise environments, where a vulnerable workload or application may have legitimate connections to identities, data stores, deployment systems, ERP platforms, finance workflows, and third-party services. The first compromised system is rarely the full blast radius.

What should be visible before remediation is complete

Traditional vulnerability management follows a familiar sequence:

1. A vulnerability is discovered.
2. It is assigned a severity and published.
3. Security teams identify affected assets.
4. Teams patch, mitigate, or isolate them.

That sequence remains valuable. It is not guaranteed to complete before an attacker starts using the flaw.

In that interval, security teams need a practical view of the potential consequence. The focus should be on four questions:

• Which identities, administrators, service accounts, and integrations can the affected application use?
• Which sensitive data and high-consequence workflows are reachable through those relationships?
• Which changes would reduce that reachability while a permanent fix is rolled out?
• Which observed actions would show an attacker using the foothold to move closer to data?

This gives incident responders more than an asset inventory. It gives them an ordered containment problem: isolate the paths that matter most first.

ERP incidents make the consequence tangible

Enterprise applications demonstrate why this matters. Nissan disclosed an employee-data breach stemming from a zero-day campaign targeting Oracle PeopleSoft. Estée Lauder Companies disclosed that employee data was taken from an Oracle E-Business Suite environment during a separate zero-day campaign.

These are separate incidents. They do not establish that every ERP compromise follows the same path. They do show why a critical application vulnerability should trigger an immediate investigation beyond the affected server or product version.

ERP systems can connect workforce data, finance, suppliers, procurement, identity administration, and customer-adjacent processes. A team needs to understand which administrator accounts can reach the system, which service accounts and integrations run through it, and which downstream data stores, secrets, payment processes, or employee records could become reachable.

Patching is urgent. Containing the consequential paths is urgent too.

Detection needs to identify movement before impact

An attacker using a newly discovered vulnerability may gain access through an application or workload identity that already has legitimate permissions. They may issue normal API calls, inspect roles, or interact with integrations before touching the target.

The relevant detection question is not whether every action is anomalous. It is whether the activity is creating, shortening, or activating a credible route to sensitive data.

Most security teams have tools that identify vulnerabilities, flag suspicious events, and observe data movement. Those tools are important, but they can leave a gap between the first foothold and the final impact. That gap is attacker progression.

vec0 Detect uses detection agents to investigate whether identity activity is materially increasing data breach risk before sensitive data is reached. Rather than treating a role assumption, service-account action, or application event as an isolated signal, vec0 Detect agents evaluate whether it creates, shortens, or activates a credible path toward sensitive data.

This makes the key operational question more concrete:

Is this activity moving an attacker closer to data right now?

That is the question that matters when the vulnerability is known. It matters even more when it was not.

The goal is not perfect prediction

No team can predict every unknown flaw or prevent every initial foothold.

The practical goal is to reduce the opportunity for a foothold to become a breach. That means patching quickly, limiting what identities and applications can reach, and detecting the transitions that materially increase risk to sensitive data.

As vulnerability discovery accelerates, the advantage will go to teams that can do more than count critical CVEs. They will understand which compromises can become consequential, see attacker progression early, and interrupt the path before sensitive data is accessed or exfiltrated.

Sources

• Anthropic's Mythos Preview research, on AI-assisted discovery and exploitation of previously unknown vulnerabilities.
• SecurityWeek on Nissan's PeopleSoft breach.
• SecurityWeek on Estée Lauder's Oracle EBS incident.

Mythos was not involved in the Nissan or Estée Lauder incidents. The incidents are examples of why defenders need to understand the paths beyond a vulnerable enterprise application; they do not establish a shared root cause or a universal ERP attack pattern.