Cisco, SonicWall and Splunk published security advisories in the first week of October 2026, covering critical and high-severity vulnerabilities across network infrastructure, secure-access appliances and observability platforms. The releases are separate vendor disclosures that administrators should assess against their own inventories and support contracts.
The most urgent details are product-specific. SonicWall’s bulletin includes a CVSS 10.0 pre-authentication flaw in SMA1000 Work Place. Splunk’s Enterprise advisory includes a CVSS 9.8 critical issue in the Patroni REST API. Cisco’s October 7 publication spans several product families, with critical issues in NX-OS, APIC, Smart License On-Prem and Meraki. [1] [2] [3]
Key points
- Cisco’s October 7 release covers multiple product families, including NX-OS, Nexus switches, APIC, Smart License On-Prem, Meraki and Finesse.
- SonicWall’s four disclosed SMA1000 flaws affect specific 6210, 7210 and 8200v builds, not SonicWall firewalls or the SMA 100 Series.
- SonicWall fixes the affected branches in 12.4.3-03670 and 12.5.0-03082, or later versions.
- Splunk lists Enterprise fixes in 10.4.3, 10.2.7, 10.0.10 and 9.4.15, with additional steps for selected CVEs.
- The retrieved advisories do not establish active exploitation of these October issues; that status needs a fresh check before publication.
What happened
Cisco’s Product Security Incident Response Team published its scheduled October 7 advisories across several product groups. The primary Cisco notice lists critical security-hardening releases for NX-OS, Application Policy Infrastructure Controller, Smart License Manager On-Prem and Meraki. It also lists other vulnerabilities affecting Nexus switches and Finesse. Cisco’s notice gives a maximum CVSS base score of 10.0 for some releases and tells customers to move to the fixed software identified in the individual advisories. [1]
The Cisco summary is a release map rather than a universal patch instruction. A customer running NX-OS needs the NX-OS advisory and its fixed release; a Meraki customer needs the Meraki notice; and an organization using Smart License Manager On-Prem needs the relevant hardening release. Cisco cautions that upgrade decisions depend on entitlement, hardware and configuration support. [1]
SonicWall’s separate advisory covers four vulnerabilities in SMA1000 models 6210, 7210 and 8200v. The highest-rated issue, CVE-2026-102255, is a pre-authentication server-side request forgery vulnerability in the Work Place interface and carries a CVSS 10.0 score. The same bulletin describes post-authentication command injection, Zip Slip/path traversal and stored cross-site scripting issues. [2]
SonicWall identifies 12.4.3-03526 and older, and 12.5.0-02952 and older, as affected platform-hotfix branches. The fixed branches are 12.4.3-03670 and 12.5.0-03082, or later. The vendor says the advisory does not apply to SSL-VPN running on SonicWall firewall products or to the SMA 100 Series, which uses a separate codebase. [2]
Splunk’s SVD-2026-1001 advisory, published on October 7, addresses 17 vulnerabilities across Splunk Enterprise, Splunk Secure Gateway and related apps. Its most severe entry is CVE-2026-76268, a missing-authentication flaw in the Patroni REST API in Splunk Enterprise, rated Critical with a CVSS 9.8 score. The advisory also lists authorization, input-validation, SSRF, information-disclosure and denial-of-service issues with different prerequisites and scores. [3] [4]
Which versions are affected
For Splunk Enterprise, the primary advisory identifies affected ranges as 10.4.0 through 10.4.2, 10.2.0 through 10.2.6, 10.0.0 through 10.0.9 and 9.4.0 through 9.4.14. The corresponding fixes are 10.4.3, 10.2.7, 10.0.10 and 9.4.15. Some entries also require updates to Splunk Secure Gateway, whose fixed versions are 3.10.11, 3.9.25 and 3.8.72 or later. [3]
Splunk says upgrading the Enterprise package alone is not the complete remedy for every CVE. Its instructions include additional configuration or app-level steps for selected issues, including the scripted-lookup setting for CVE-2026-76264 and changes involving Secure Gateway, the Splunk Observability Cloud apps and the PostgreSQL sidecar. Those are environment-dependent changes, so administrators should follow the vendor advisory rather than copy a generic checklist into production. [3]
The Canadian Centre for Cyber Security’s AV26-1018 alert, dated October 8, independently points administrators to the same Splunk Enterprise fixed branches and identifies a separate Splunk MCP Server advisory for versions before 1.2.1. It confirms the timing of the vendor release but does not replace the product-specific Splunk notices. [5]
Cisco does not provide all fixed versions in the advance notice. Instead, it links each affected product family to its own advisory. That design matters: a roundup can identify the release and risk, but it cannot safely infer one Cisco version number for every device. Administrators should match the exact advisory to the deployed product, train and support status. [1]
Why it matters
The three releases illustrate why patch headlines need product boundaries. A CVSS 10.0 score on a specific SonicWall SMA1000 Work Place interface does not mean every SonicWall firewall is exposed. Likewise, Splunk’s 9.8 issue is one entry in a larger advisory with different access requirements, and Cisco’s critical issues are distributed across separate products. [1] [2] [3]
Independent reporting adds useful context without changing those boundaries. SecurityWeek reported Cisco’s October publication as 35 vulnerabilities, including more than a dozen critical-severity issues, and said Cisco was not aware of exploitation in the wild. Its separate report described the SonicWall and Splunk fixes and repeated the vendors’ statements. Censys independently confirmed the SonicWall CVE, affected and fixed versions, and its not-confirmed exploitation status as of October 7. [6] [7] [8]
The practical priority is inventory-led. Security teams should identify whether the named product and affected branch are deployed, confirm the maintenance path, review internet exposure and privileged access, and preserve logs under their incident-response policy.
What remains uncertain
The sources retrieved for this private draft were accessed after the 2026-10-09T10:47:05+05:30 cutoff. Their displayed publication dates are recorded, but the article needs a fresh source check before release. Advisory pages can be revised, and vendor statements about exploitation are time-bounded.
The retrieved material does not establish active exploitation of CVE-2026-102255, CVE-2026-76268 or the other October issues. SonicWall explicitly says it had no evidence of in-the-wild exploitation, while Censys says the SonicWall issue was not confirmed and was not in the CISA Known Exploited Vulnerabilities catalog as of October 7. Cisco’s secondary report similarly says Cisco was not aware of exploitation. This is not proof that exploitation is impossible or that a patched system was never exposed. [2] [6] [7] [8]
No source here establishes a customer count, confirmed breach, public proof of concept or organization-specific impact. Those claims should remain out of any public version unless current primary evidence supports them. Earlier exploited SonicWall vulnerabilities discussed by Censys are background and must not be presented as exploitation of this October advisory. [8]
What happens next
Administrators should begin with a current asset and version inventory, then open the exact Cisco, SonicWall or Splunk advisory for the product in use. For Cisco, the individual product advisory is essential because the October notice spans distinct software families. For SonicWall, the SMA1000 model and platform-hotfix branch determine whether the bulletin applies. For Splunk, both the Enterprise version and the dependent apps or gateways matter. [1] [2] [3]
Before release, editors should recheck the vendor pages and CISA’s KEV catalog, confirm any advisory revisions, and keep the language limited to what the sources establish. If an organization finds an affected internet-facing system, its security team should follow its own change-control and incident-response procedures. Patching addresses the vulnerable software; it does not by itself prove that no earlier unauthorized access occurred.
