Why Repeat Zero-Days in One Product Need a Different Plan

Repeat zero-days in one product are a signal that the product is under sustained attention from attackers. Each emergency patch fixes one bug, but the exposure and the attacker's interest stay. When a product has had two or three exploited flaws in a year, plan as if another one is coming: restrict where it can be reached, assume compromise when each advisory lands, and decide in advance whether you will contain it, move it to a hosted service or replace it.

What counts as a repeat zero-day pattern?

A repeat zero-day pattern is two or more vulnerabilities in the same product exploited in the wild within a short period, typically a year. The pattern matters more than any single bug because it shows that capable attackers are actively studying that product.

Arista's VeloCloud Orchestrator is a current example. On-prem VCO has had three exploited flaws in four months:

• CVE-2026-16812, published July 27, 2026: unauthenticated OS command injection, CVSS 10.0
• CVE-2026-93952, September 22, 2026: unauthenticated improper input validation, CVSS 10.0, added to the CISA Known Exploited Vulnerabilities catalog the same day
• CVE-2026-114625, October 22, 2026: SQL injection that lets any authenticated user become a superuser operator, CVSS 9.9

The first two needed no login. When those were closed, the latest VeloCloud Orchestrator zero-day required an account, but the lowest read-only role was enough. Aviatrix reads the three as one campaign adapting to each fix. Arista has not attributed them.

Why does a patch alone not close the risk?

A patch alone does not close the risk because it fixes only the vulnerability that was disclosed. It does not remove access the attacker already gained, and it does not reduce the attacker's interest in finding the next flaw in the same code.

Two problems follow. First, a device exploited before the patch may still carry a backdoor afterwards. Arista's September advisory listed implant files and a systemd service on compromised VCO hosts, and recommended rebuilding from trusted sources after confirmed compromise. Second, the same management interface, input handling and internal functions keep producing bugs. A pattern of repeat zero-days suggests the next one is a question of when.

Change the default response

For a product with a repeat pattern, the normal response of "patch within the SLA" is not enough. Adjust it in four ways.

Patch on the vendor's day, not your cycle

Treat every advisory for that product as an emergency change. Pre-approve the change, keep the upgrade procedure tested and have rollback ready. If your change board needs a week, the attacker gets a week.

Assume compromise with every advisory

When the vendor says a bug was exploited before disclosure, check for compromise before and after patching. Keep logs first, then hunt for the indicators in the current advisory and every earlier one. A device cleaned after the first incident may have been re-entered through the second.

Shrink the exposure permanently

Every advisory in this pattern recommends restricting the web interface to trusted administrative networks. Do it once and keep it. Put the portal behind a jump host or VPN, limit outbound traffic from the host and remove accounts nobody needs. Our guide on how to audit read-only accounts on a management portal covers the account side.

Track the product as a named risk

Add the product to the risk register with its incident count, the hours spent on each emergency and the business functions that depend on it. That record turns a vague sense of "this keeps happening" into numbers a budget owner can act on.

When should you consider replacing the product?

Consider replacing a product when you cannot contain its exposure, when its emergency patches keep breaking your change process, or when the cost of repeated incident response approaches the cost of migrating. Replacement is a business decision, so bring numbers.

Useful questions for that decision:

• Can the exposure be contained? If the portal must be reachable from the internet for partners or devices, restriction may not be possible.
• Is a hosted version available? For VCO, Arista patched hosted and Dedicated instances before each advisory went out. Moving to the hosted service shifts patching to the vendor, though you still own accounts and tenant review.
• How does the vendor respond? Fast advisories, clear indicators and fixes for every supported train count in the vendor's favor. Missing indicators or slow fixes for some trains count against.
• What would migration cost? Count hardware, licensing, staff time and the risk of the migration itself.

Do not treat a single exploited bug as a reason to switch. Every widely used product gets them. The repeat pattern, combined with an exposure you cannot shrink, is what justifies the cost.

How do you spot a repeat pattern early?

Spot a repeat pattern early by tracking exploited vulnerabilities per product across your estate, not just per advisory. A short list of products with their exploited CVE counts for the last 12 months is enough.

The CISA Known Exploited Vulnerabilities catalog is a free starting point, because it groups entries by vendor and product. Vendor advisories and research write-ups fill the gaps for bugs CISA has not listed yet. Review the list quarterly. Any product that appears twice should get the treatment above, especially management systems such as the one described in what an SD-WAN orchestrator is, because one compromise reaches every site they manage.