Your patch calendar just got an AI multiplier – or – The firmware baseline in your design now expires before cutover

Arista published 34 security advisories on September 9. A 35th, advisory 0148, exists to summarize the other 34. Over the previous two years, Arista averaged about two a month. Cisco’s next batch lands September 16 and covers its firewalls (ASA, FTD and FMC), ISE and Nexus Dashboard. Both vendors give the same reason: AI tools are finding bugs in their code faster.

In my experience, clients ask for the same thing when it’s time to pick code for a network build. They want the most recent stable or long-term support release, and they want it on every device until the project is done, whether the rollout takes six weeks or 24 months. One release is easier to support, and nobody wants to chase a second release’s bugs halfway through a deployment.

Your network didn’t get more dangerous on September 9. Security advisory volume went up, and that puts the one-release standard in question. If you run a network for a living, at an IT shop or an MSP, your patch calendar just got an AI multiplier. If you design, deploy or refresh networks for clients, the firmware baseline in your design doc now expires before cutover. The advisories are the same for the run team and the build team. The work they create is not.

Why security advisory volume jumped

Arista explained the batch a week before it landed. In a September 2 post, co-founder and CTO Ken Duda and CISO Jason Bevis wrote that Arista has been adding AI-driven vulnerability discovery to its security pipeline. That work includes “access to models such as Mythos and Daybreak” and an early invitation into Anthropic’s Project Glasswing. “The result is a more thorough security review process operating at a much faster machine pace,” they wrote. They expect “an elevated volume of security advisories and batched releases” for “at least the next few months.”

Cisco rebuilt its disclosure process for the same reason. Since July, it has published on the first and third Wednesday of each month at 16:00 UTC, with a week’s notice of which products are coming. A Cisco security hardening release bundles several internally found fixes into one image. Its August IOS XE Security Hardening Release fixed seven CVEs that Cisco says were found “using existing testing processes as well as frontier AI models.” None were known to be exploited.

Anthropic, which counts Cisco as a Glasswing partner, described the new bottleneck in a May update. “Progress on software security used to be limited by how quickly we could find new vulnerabilities,” it wrote. “Now it’s limited by how quickly we can verify, disclose, and patch the large numbers of vulnerabilities found by AI.” The patch is the step that lands on network teams, and it lands whether or not the bug was ever a threat to your network.

Volume and risk are different numbers

An advisory describes a bug that was already in your code. When the vendor finds the bug first, the fix ships with the news. Publishing does start a clock for attackers, and I’ll come back to that clock. For most advisories it barely moves.

Security advisory volume is up across the industry, and VulnCheck’s first-half 2026 report shows what came with it. CVE volume grew 45% over the previous six months, while known-exploited vulnerabilities grew 10%. Of the 1,061 vulnerabilities VulnCheck attributes to AI-assisted discovery, 14 have been confirmed as exploited. The multiplier applies to the reading, not the risk.

Arista’s batch shrinks once you read it next to a running config. Five of the 34 are rated Critical. The P4Runtime bug in 0174 and the gNPSI bug in 0158 need those services configured, and the VeloCloud Edge bug in 0179 needs access to the private HA interconnect. Both perfect 10.0 scores in the batch belong to features that ship turned off.

The one worth reading first is 0156, a DHCP relay bug, because a lot of campus and data center networks run helper addresses. Arista says it isn’t aware of malicious use of 0156, 0158 or 0174, and all three are fixed in 4.36.2F, 4.35.6M and 4.34.8M. For those three, the work is one upgrade on whichever of those trains you run.

The clock matters for a small group, and that group is getting faster. VulnCheck found that the median time from publication to landing on its known-exploited list fell from 120 days in 2025 to 80 days in the first half of 2026. Arista’s customers saw the fastest version of that in July, when attackers were already exploiting a command injection bug in on-premises VeloCloud Orchestrator as the advisory went out. Hosted customers had been patched before it was published. On-premises customers had to apply the fix themselves.

Cisco’s June post announcing its schedule says “the window between disclosure and exploitation has effectively closed.” For that small group, it has. For the large majority of new CVEs, the risk still comes down to whether the vulnerable feature is on and who can reach it. That splits the work into a small fast lane and a large scheduled lane.

CISA turned the same logic into federal policy in June. Binding Operational Directive 26-04, which covers federal civilian agencies, replaced the flat deadlines of BOD 22-01 with four questions: is the asset publicly exposed, is the bug known to be exploited, can exploitation be automated, and would it give an attacker control of the system? The worst combinations get three days. A vulnerability that meets none of the four can wait for the next scheduled upgrade. CISA cites AI shortening the path from discovery to weaponization as part of its reasoning. You don’t have to be a federal agency to borrow the model, and I don’t know of a plainer published statement that security advisory volume and risk are different numbers.

If you run the network

For an IT team or MSP, security advisory volume arrives as a longer list every other Wednesday. Five habits keep a longer list from becoming a riskier network.

Sort before you schedule. Run each advisory through CISA’s four questions, then add the one the directive assumes: is the affected feature turned on? That question takes both of Arista’s perfect 10s out of scope for most networks before anyone opens a change request. Arista points customers to CloudVision to see the affected devices and the fixed release, and Cisco’s Software Checker does the same job for many of its platforms.

Put the vendor calendar on your change calendar. Cisco publishes at 16:00 UTC, which is noon Eastern for most of the year, and names the products a week ahead. Arista gave a week’s notice too. Use publication day for triage and schedule the changes after it. Cisco says the notice is there so customers can “pre-stage change windows, lab validation, and maintenance approvals,” which is the right use of the week.

Pre-approve the routine upgrades. A vendor that publishes twice a month doesn’t fit a change board that meets once a month. I would push for a standard change type covering tested baseline updates, so the board approves the process once and saves its meetings for the fast lane.

Test the fix before you trust it. Arista’s post says “the newest EOS release is also the highest-quality release, so you can move to it with confidence instead of waiting it out.” Arista may be right about EOS. Cisco’s August IOS XE hardening release is why I would still run the lab step. In a Cisco community AMA, Cisco staff confirmed the release carried two high-severity wireless defects. One left downstream 802.11 action frames unseen over the air, and the other had 9800 foreign controllers dropping client traffic from the anchor. Cisco staff described both as “corner case scenarios” and fixed them with AP service packs and software maintenance updates on top of the release.

Automated pre- and post-checks make the lab step cheap to repeat. ANTA does this for Arista and pyATS for Cisco, and a virtual lab with cEOS in containerlab or Cisco Modeling Labs catches software-only regressions. Wireless still needs real radios.

If you’re an MSP, price the fast lane on its own. The scheduled lane fits the managed service contract you already have. An emergency upgrade inside a three-day window needs different staffing and a different approval path, so price it separately and put it in the contract.

If you build the network

Build teams feel security advisory volume between design sign-off and the last cutover. Depending on the solution, getting from design to proof of concept, pilot or first cutover can take a few weeks. With one site or a handful, cutovers follow in quick succession and one release holds. With dozens or hundreds of sites, the rollout can run a year or two.

A long rollout has always picked up a few advisories along the way, and at two a month a project could absorb them. Arista’s September batch delivered about 17 months of that volume in one day, and Arista expects the higher pace to last for months. That leaves three choices, and each one costs something.

Keep the design release on every site and hand over a network with known advisories against it. Put a newer release on the sites still to come and run mixed releases across the estate, which is the problem the one-release standard exists to prevent. Or re-baseline the whole rollout and coordinate testing of the newer release with the client’s run team, whether that’s in-house IT or an MSP. They may already be running the sites you cut over last quarter.

Any of the three can be right for a given client, as long as the choice gets made during design. Four changes make that possible.

Write the baseline as a rule with a date. Put the rule that produced the release number into the low-level design, next to the number. Mine would read: the latest vendor-recommended stable or long-term support release on the chosen train, with no open Critical or High advisories that apply to this design, as of a named date. Re-check the rule at gates the project already has, such as design sign-off, staging entry, pilot and two weeks before each cutover wave. The release can stay the same through every check. The date shows someone checked.

Keep the design’s feature list machine-readable. The design already records what’s turned on, from DHCP relay and OSPFv3 to MLAG, 802.1X and OpenConfig services. Keep that list in a form a script can read, and each advisory batch becomes a lookup. This is a good defensive job for AI. A model can take the first pass at matching advisory text to the feature list and the staged configs, and an engineer signs off on what applies.

Set the re-baseline triggers before the first site. Agree with the client up front on which advisories force a change mid-rollout. My default would be the fast lane only, meaning a bug known to be exploited, in a feature you run, on a device an attacker can reach. Everything else waits for a planned wave boundary. I would also cap the estate at two releases at a time, the current baseline and the next one, with a date to converge.

Put the re-baseline in the SOW. State that the target release is as of a dated review. Include a set number of re-baseline cycles and price the lab regression time for each. Name who tests newer releases on sites already handed over, whether that’s the build team or the client’s run team. Leave that line out and the question gets answered on a cutover weekend by whoever is on the bridge call.

Where the two meet

The run team and the build team share one document, the handoff pack. For this problem it needs more than a release number. I would add four things: the date advisories were last reviewed, each advisory that applies to the design with its status, any mitigation the run team has to keep in place, and the date of the vendor’s next publication.

That page is where the build team’s firmware baseline becomes the run team’s patch calendar. If you’re on the receiving end, ask for it before you sign acceptance. A release number without a review date tells you nothing about the advisories published since the design was approved.

Here is how I would split the work on a single advisory. The questions come from CISA BOD 26-04, and the lanes are my own working model.

The advisory	If you run the network	If you’re building it
Known exploited, feature in use, reachable	Emergency change within days	Stop the wave. Upgrade or mitigate before the next cutover.
Known exploited, feature in use, not reachable	Mitigate now, upgrade in the next window	Cut over with the mitigation in place, note it in the handoff pack, re-baseline at the next wave boundary
Critical or High, feature in use, no sign of exploitation	Next scheduled baseline update	Next planned wave boundary
Feature not in use	Record it as not applicable	Record it as not applicable in the handoff pack

Cisco’s next batch lands Wednesday, September 16, at noon Eastern. If ISE, Nexus Dashboard or a Cisco firewall is on your network or in your next cutover wave, read those advisories with the feature list open. Then write a date next to the release.

Sources

1. Ken Duda and Jason Bevis, Arista. “Racing Against Machine-Speed Threats: How Arista Is Using AI.” September 2, 2026. https://blogs.arista.com/blog/racing-against-machine-speed-threats
2. Arista. “Security Advisory 0148” (summary of advisories 0149 to 0182). Published September 2, 2026, updated September 9, 2026. https://www.arista.com/en/support/advisories-notices/security-advisory/24535-security-advisory-0148
3. Arista. “Security Advisory 0156.” September 9, 2026. https://www.arista.com/en/support/advisories-notices/security-advisory/24712-security-advisory-0156
4. Arista. “Security Advisory 0158.” September 9, 2026. https://www.arista.com/en/support/advisories-notices/security-advisory/24714-security-advisory-0158
5. Arista. “Security Advisory 0174.” September 9, 2026. https://www.arista.com/en/support/advisories-notices/security-advisory/24730-security-advisory-0174
6. Arista. Security advisories listing (advisory 0179). https://www.arista.com/en/support/advisories-notices/security-advisory
7. Arista. “Security Advisory 0100.” July 8, 2024. https://www.arista.com/en/support/advisories-notices/security-advisory/19904-security-advisory-0100
8. Michael Cooney, Network World. “AI tools driving ‘elevated volume’ of security advisories, Arista warns.” September 2, 2026. https://www.networkworld.com/article/4217638/arista-warns-customers-ahead-of-next-weeks-security-disclosures.html
9. Cisco. “Cisco’s Transition to a Risk-Based Vulnerability Disclosure Model.” https://sec.cloudapps.cisco.com/security/center/resources/risk-based-disclosure
10. Russ Smoak, Cisco. “Strengthening the Foundation: A Predictable, Customer-Focused Response to AI-Accelerated Vulnerability Discovery.” June 2, 2026. https://blogs.cisco.com/security/strengthening-the-foundation-a-predictable-customer-focused-response-to-ai-accelerated-vulnerability-discovery
11. Cisco. “Cisco Advance Notification for Publication of September 16, 2026, Security Advisories.” September 9, 2026. https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-notice-jfxK98ZP
12. Cisco. “Cisco IOS XE Software Security Hardening Release: August 2026.” August 5, 2026. https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-hardening-iosxe-V8NMuMZJ
13. Cisco Community. “AMA: 2026 IOS XE Software Security Hardening update.” August 2026. https://community.cisco.com/t5/wireless/ama-2026-ios-xe-software-security-hardening-update/td-p/5569459
14. Anthropic. “Project Glasswing: An initial update.” May 22, 2026. https://www.anthropic.com/research/glasswing-initial-update
15. Help Net Security. “Anthropic: Claude Mythos identified 10,000+ software flaws” (Project Glasswing partners). May 26, 2026. https://www.helpnetsecurity.com/2026/05/26/anthropic-project-glasswing-update/
16. Patrick Garrity, VulnCheck. “State of Exploitation 1H-2026.” July 28, 2026. https://www.vulncheck.com/blog/state-of-exploitation-1h-2026
17. The Register. “Arista patches actively exploited VeloCloud bug as CISA puts admins on the clock.” July 28, 2026. https://www.theregister.com/security/2026/07/28/arista-patches-actively-exploited-velocloud-bug-as-cisa-puts-admins-on-the-clock/5279414
18. Tenable. “What is CISA BOD 26-04: Impact on vulnerability remediation.” 2026. https://www.tenable.com/blog/cisa-bod-26-04-FAQ-vulnerability-remediation-impact
19. CISA. “BOD 26-04: Prioritizing Security Updates Based on Risk.” June 2026. https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk