CybersecuritySolarWinds Observability CVE-2026-28324 and CVE-2026-28325: RCE Risk and Patch Priorities
SolarWinds Observability Self-Hosted 2026.2.3 fixes two serious remote-code-execution vulnerabilities. One can be unauthenticated under affected configurations, making observability infrastructure a priority because it often has broad visibility and privileged integrations.
Editorially reviewed for factual accuracy
Archive coverage note: This Zeph Tech briefing was published on September 27, 2026 and documents a security development from . The historical date in the URL identifies the covered event; it is not a claim that Zeph Tech originally published the page on that date.
Monitoring systems are attractive targets because they collect infrastructure topology, credentials, alerts and operational data across many systems. A compromise of the observability layer can give an attacker both visibility and a trusted position inside the network.
What happened
SolarWinds lists CVE-2026-28324 and CVE-2026-28325 among the fixes in Observability Self-Hosted 2026.2.3. The release notes describe remote code execution conditions, including an unauthenticated deserialization issue when the application is configured to use a specific communication mode.
- CVE-2026-28324 is described as an unauthenticated RCE issue tied to insufficient integrity checks in a non-default, insecure configuration.
- CVE-2026-28325 is described as unauthenticated RCE stemming from deserialization of untrusted data under a specific communication mode.
- SolarWinds lists severity scores of 9.8 and 8.8 respectively in the release notes.
- Canadian cyber authorities advised users to review the vendor links and apply necessary updates.
Why defenders should care
Observability platforms frequently connect to servers, network devices, cloud services and identity systems. Even if the initial vulnerability requires a particular configuration, defenders should verify actual deployment settings rather than assume defaults are still intact.
- Monitoring platforms can hold credentials or tokens that expand attacker reach.
- Broad network visibility can help an attacker identify high-value systems.
- Non-default legacy settings may persist unnoticed for years.
- Compromise of the monitoring layer can reduce confidence in telemetry during incident response.
Priority response
Organizations affected by this development should treat remediation as an operational workflow rather than a single patching checkbox. Confirm exposure, reduce reachable attack surface, apply the vendor-supported fix or control, and then verify whether compromise may have occurred before remediation.
- Upgrade SolarWinds Observability Self-Hosted to a version that includes the vendor fixes.
- Verify communication-mode and integrity-related settings rather than relying on remembered defaults.
- Review the platform for unexpected processes, services, files, accounts and outbound connections.
- Inventory credentials and integrations available to the monitoring platform and rotate exposed secrets when warranted.
- Validate that logging and alerting pipelines were not disabled or manipulated.
- Reduce network reachability to management and internal service interfaces.
Detection and verification
Examine process creation and network telemetry on the SolarWinds host, especially unexpected interpreters or shells, new persistence, changed service configuration, unexplained outbound sessions, and changes to monitoring targets or alert destinations. Correlate with administrative audit logs and configuration history.
Preserve relevant logs before disruptive remediation when practical, compare current configuration with a known-good baseline, and document both the technical fix and the evidence used to determine whether follow-on incident response is required. Where a vulnerability is known to be exploited, patch status alone does not answer whether the system was already compromised.
Longer-term security lesson
Security teams should include observability, orchestration and management products in their tier-zero or privileged-infrastructure inventories. These systems are not passive dashboards; they often have the connectivity and credentials needed to become powerful pivots.
For program owners, this event is also a useful test of asset inventory, ownership, vulnerability prioritization, evidence retention, and communication. Teams should be able to identify affected systems quickly, name an accountable owner, record the mitigation decision, and prove that the control change reached production. Those capabilities are often more important than any one scanner score.
Questions teams should be able to answer
Which version contains the fixes?
SolarWinds documents the addressed CVEs in Observability Self-Hosted 2026.2.3.
Are all configurations equally exposed?
No. The vendor descriptions reference specific non-default or communication-mode conditions, which is why configuration verification matters.
Why is observability infrastructure high value?
It often has broad access to infrastructure metadata, logs, credentials and management integrations across the environment.
Related Zeph Tech guidance
Use the Vulnerability Management Program guide to turn urgent advisories into a repeatable remediation workflow, the free cybersecurity risk register to record residual exposure and treatment ownership, and the Cybersecurity hub for broader defensive guidance.
Scope the operational blast radius
Inventory what the SolarWinds platform can see and authenticate to: servers, network devices, cloud services, storage, hypervisors, databases and alerting destinations. Monitoring systems often have broad connectivity and stored polling credentials, so compromise can provide both reconnaissance and a trusted pivot into otherwise segmented systems.
Preserve host process telemetry, network connections, SolarWinds audit and configuration history, service-account use, monitoring-target changes, alert destination changes and external identity logs. Use alternate telemetry sources to determine whether monitoring data was disabled or manipulated during the suspected exposure window.
Turn remediation into an auditable control
Prefer read-only and least-privilege polling identities, keep privileged configuration authority separate from monitoring, move durable secrets into managed secret stores, isolate management interfaces and restrict outbound connectivity to required integrations. Maintain configuration backups that do not depend on the monitored platform itself.
Measure whether the control is improving instead of counting closed tickets. Useful indicators for this topic include stored privileged credentials; externally reachable management interfaces; supported-version coverage; integrations using scoped service identities; time to detect monitoring outages; independent configuration backup age; and unexplained changes to alert or collection configuration. Review the measures after material architecture changes and after incidents so the program does not optimize for a stale threat model.
Keep a defensible decision record
For SolarWinds Observability, record the installed build, communication mode and other relevant configuration, credentials available to the platform, downstream systems reviewed, alternate telemetry used to validate monitoring integrity, and the evidence confirming the service returned to a trusted state. Capture who approved the final risk disposition and the date the temporary incident controls can be removed or must be reviewed again. A concise decision record prevents emergency actions from becoming undocumented permanent architecture and gives the next responder a verified starting point instead of forcing the team to reconstruct the event from tickets and memory. Revalidate the inventory after the next platform upgrade so configuration drift does not silently recreate the same exposure.
Owner handoff before closure
Before closing the response to SolarWinds, the technical owner and the risk owner should agree on what evidence demonstrates completion. Record the affected inventory, final software or configuration state, temporary controls still in place, credentials or identities changed, detection coverage added, and any systems excluded from remediation with an explicit reason. Confirm that monitoring will detect recurrence and that the service owner knows which future change would invalidate the current risk decision. If the event exposed an inventory, logging, ownership or recovery gap, assign that gap as separate tracked work instead of burying it inside the original patch ticket. A short post-response review should also capture which step consumed the most time and which dependency prevented faster action. That information is operationally valuable: it lets the next incident start with a tested owner map, reliable evidence sources and a known containment path rather than repeating discovery under pressure.
Documentation
- SolarWinds Observability Self-Hosted 2026.2.3 release notes — SolarWinds
- SolarWinds security advisory (AV26-950) — Canadian Centre for Cyber Security
Continue in the Cybersecurity pillar
Return to the hub for curated research and deep-dive guides.
Latest guides
-
Network Security Fundamentals: Segmentation, DNS, Zero Trust & Monitoring | Zeph Tech
A 2026 practitioner guide to network segmentation, firewall policy, DNS security, remote access, encrypted traffic, monitoring, administration, and zero-trust architecture.
-
Small Business Cybersecurity Survival Checklist
A practical 2026 cybersecurity operating guide for small and medium-sized businesses, organized around NIST CSF 2.0 and current FTC guidance with bounded Verizon DBIR threat…
-
Cybersecurity Operations Playbook
Build a defensible cybersecurity operations program around NIST CSF 2.0, current incident-response guidance, exploited-vulnerability prioritization, evidence capture, and…
Coverage intelligence
- Published
- Coverage pillar
- Cybersecurity
- Source credibility
- 40/100 — low confidence
- Topics
- SolarWinds · CVE-2026-28324 · CVE-2026-28325 · Observability security · Remote code execution
- Sources cited
- 2 sources (documentation.solarwinds.com, cyber.gc.ca)
- Reading time
- 6 min
Documentation
- SolarWinds Observability Self-Hosted 2026.2.3 release notes — SolarWinds
- SolarWinds security advisory (AV26-950) — Canadian Centre for Cyber Security
Source feedback
Editorial
Found a factual issue, superseded source, broken citation, or important context we should review? Send the specific claim and supporting source through the correction path so it can be evaluated against the article record.