CERT-In Vulnerability Notes: Wireshark, Cisco Nexus Dashboard and SolarWinds

How to read the three CERT-In notes

The 2026 vulnerability-note index lists CIVN-2026-0483, CIVN-2026-0482 and CIVN-2026-0481 with a 29 September 2026 issue date. The individual pages preserve the same date and describe three different products. Treating the batch as a single incident would erase the differences between a desktop or analyst tool, a data-centre management platform, and enterprise access-rights software.

The severity labels are also advisory prioritisation signals, not incident findings. CERT-In rates Wireshark HIGH, Cisco Nexus Dashboard CRITICAL, and SolarWinds HIGH. Those labels communicate potential consequence and urgency; they do not say that any Indian organisation was attacked or that a vulnerable installation was reached. Affected-version matching is therefore the first defensible decision point.

The useful unit of work is a product-specific record: owner, deployment, version, exposure, vendor guidance, change window, verification evidence, and residual uncertainty. Keep the three records separate in ticketing and reporting even when the same team owns all three technologies.

CIVN-2026-0483: Wireshark applicability and impact

CERT-In identifies Wireshark 4.6.0 through 4.6.8 and 4.4.0 through 4.4.18 as affected. The note describes weaknesses in protocol dissectors, file parsers, utilities, and profile-import functionality. Its risk paths include malformed network traffic, malicious packet captures, malformed files, and a malicious configuration profile being imported by a user.

The stated outcomes range from application crashes and excessive resource consumption to denial-of-service conditions, memory leaks, and potentially arbitrary code execution. Those are possible effects of successful exploitation, not a statement that exploitation has occurred. A capture file found on a workstation is not by itself proof of malicious intent, and a crash is not by itself proof of code execution.

Wireshark’s linked security pages were opened before recording a fixed-version claim. The reviewed pages for this advisory family state 4.6.9 and 4.4.19 as fixed versions. That is a vendor-page finding, not a release inferred from the CERT-In note. Teams should still confirm the current download and release state in their controlled change process, especially where packaging or operating-system repositories lag upstream releases.

CIVN-2026-0482: Cisco Nexus Dashboard scope

The Cisco note covers Nexus Dashboard 4.2 and earlier, and 4.3 versions before 4.3.1.175. It lists CVE-2026-20322, CVE-2026-20325, CVE-2026-20326, CVE-2026-20360, CVE-2026-20361 and CVE-2026-76409. CERT-In describes improper access control, command or SQL input handling, missing authentication for critical functions, and pathname restrictions as contributing conditions.

The possible impact is materially different from the Wireshark note because the platform is a central management and automation layer for data-centre networks. CERT-In describes remote arbitrary-code execution, security-restriction bypass, privilege escalation and unauthorised access, with potential for complete system compromise. This describes risk capability; it does not establish that a remote request succeeded in any environment.

Cisco’s opened advisory states that 4.3 is fixed in 4.3.1.175 and that 4.2 and earlier should migrate to a fixed release. It also says Cisco PSIRT was not aware of public announcements or malicious use of the vulnerabilities in that advisory. The 4.2-and-earlier instruction is intentionally not converted into a made-up version number: the correct action is to identify a supported target release with Cisco’s current guidance and validate platform compatibility.

CIVN-2026-0481: SolarWinds product boundaries

CERT-In identifies SolarWinds Observability Self-Hosted 2026.2.2 and prior, and SolarWinds Access Rights Manager 2026.2 and prior. It links CVE-2026-28324, CVE-2026-28325 and CVE-2026-28326. The note attributes the potential remote unauthenticated arbitrary-code-execution outcome to hardcoded static cryptographic keys, insufficient authenticity verification, and insecure deserialisation conditions.

The product split matters. Observability Self-Hosted and Access Rights Manager are not interchangeable inventory labels, and a company may operate one without the other. A finding on a management server should be recorded with its exact product, deployment model, build, host, owner, network reachability, and administrative dependencies rather than as a generic SolarWinds finding.

The opened SolarWinds advisories state fixed releases of Observability Self-Hosted 2026.2.3 for CVE-2026-28324 and CVE-2026-28325, and Access Rights Manager 2026.2.1 for CVE-2026-28326. These are vendor-specific claims validated before inclusion. They do not establish that an upgrade was completed, that the application is safe in every configuration, or that a vulnerable version was exploited.

Advisory comparison matrix

The matrix below separates what is observed in the primary notes from what must be verified locally. “Affected range” is the vendor or CERT-In version boundary. “Potential impact” is the outcome described by the advisory. “Status” is not a breach assessment: the reviewed CERT-In notes do not report exploitation, victims, or Indian compromise for any of the three products.

For Wireshark, the main exposure question is which analysts or endpoints open captures, parse traffic, or import profiles. For Nexus Dashboard, the key question is the management plane’s exact release and reachability. For SolarWinds, the key question is whether the named Self-Hosted or Access Rights Manager product and version are actually installed, and which vendor fix applies.

India context without overclaiming

The India relevance is defensible because CERT-In, India’s national computer emergency response body, published the three notes and identifies organisations and individuals using the named products as the audience. That makes the notices useful for Indian asset owners, managed service teams, data-centre operators, public-sector environments, and security teams that process packet captures. It does not prove that any particular Indian entity is affected.

No reviewed source establishes exploitation in India, victims in India, an affected Indian sector, or a compromise linked to these notes. A product’s presence in an Indian inventory is an applicability fact; it is not an incident fact. Likewise, severity should guide prioritisation without being rewritten as evidence of an active campaign.

India-based teams should preserve the original CERT-In note identifiers in their records and route technical decisions through the relevant product owner. Where a change affects a regulated or operational environment, document the chosen release, compatibility checks, rollback plan, and verification result. This is a governance discipline, not a claim that CERT-In imposed a new product-specific deadline in the reviewed pages.

A defensible inventory and remediation workflow

Begin with discovery rather than assumptions. Query endpoint, server, virtual-appliance, container, and software-management inventories for the exact product names and branches. Reconcile those results with procurement records, administrator knowledge, and network telemetry. For Wireshark, include analyst workstations and forensic toolkits; for Nexus Dashboard and SolarWinds, include management servers, appliances, backup images, and standby nodes.

Next, capture evidence of version and exposure. Record the installed build, deployment role, internet or partner reachability, privileged functions, connected systems, and last successful update. A version comparison without a deployment owner is not a completed assessment. If the version cannot be established, mark it unknown and assign an owner rather than treating absence of data as absence of risk.

Use the validated vendor path for the product and vulnerability family. Test the proposed release against supported integrations, schedule the change with service owners, and retain pre-change and post-change evidence. Verification should include the installed version, service health, management-plane access, relevant logs, and a closure link to the change record. If a system cannot be updated promptly, record the temporary risk decision and compensating restrictions separately from the permanent fix.

Observed, inferred and unknown: a clean evidence boundary

Observed in the sources: three CERT-In notes were issued on 29 September; the notes name affected ranges and possible impact; Wireshark, Cisco and SolarWinds publish linked remediation material; and the opened vendor pages provide the fixed releases recorded in this article. These are publication and product-advisory facts.

Reasonably inferred for operations: an organisation that runs a listed version should prioritise inventory and vendor-guided remediation; a management platform with broader reach may deserve a tighter change window; and imported captures or profiles deserve careful handling when Wireshark is in scope. These are defensive interpretations, not evidence of an attack.

Unknown in the reviewed evidence: whether any reader’s system is affected, whether exploitation occurred, how many systems or people may be involved, whether data was accessed, and whether any Indian organisation was targeted. Do not fill those gaps with severity labels, internet exposure, scanner alerts, or a successful patch. Those signals can direct investigation, but they do not prove compromise.

Verification records that survive review

A useful closure packet should show the original advisory identifier, affected asset list, version evidence, vendor advisory consulted, change approval, implementation timestamp, validation result, and any exception. Keep the three CERT-In records distinct so that a completed SolarWinds update is not accidentally counted as closure for Wireshark or Nexus Dashboard.

For Wireshark, record the endpoint or toolkit owner and the fixed branch confirmed from the vendor page. For Cisco, record the branch decision, including whether a 4.2-or-earlier installation migrated to a supported fixed release. For SolarWinds, record whether the asset is Observability Self-Hosted or Access Rights Manager and match the remediation to the applicable vendor advisory rather than to a broad product family.

If evidence suggests unusual access or behaviour, open the organisation’s established incident process as a separate decision. Do not label the advisory itself an incident, and do not destroy logs during an upgrade. The source material supports careful remediation and investigation; it does not support an assertion that these three notes describe a breach.