Unauthenticated deserialization RCE in SolarWinds Observability Self-Hosted

SolarWinds Observability Self-Hosted was found to be affected by an unauthenticated remote code execution vulnerability stemming from deserialization of untrusted data when the application is configured to use a specific communication mode.

• SolarWinds Observability Self-Hosted 2026.2.2 and below: identified by SolarWinds as affected.
• The normalized affected range records versions less than 2026.2.3 as affected, with default status affected.
• SolarWinds identifies 2026.2.3 as the fixed software release. The available evidence does not establish the status of later or parallel release branches beyond that named release.
• Exposure requires the application to use a specific communication mode, but the public advisory does not name the mode. The release notes discuss WPM player installation types and communication-mode changes, but do not state that every WPM installation is affected by this vulnerability.

This is a CWE-502 vulnerability in which the application deserializes untrusted data when configured to use a specific communication mode. If attacker-supplied serialized data reaches that processing path, the documented outcome is remote code execution without authentication. The normalized record characterizes reachability as adjacent network, with low attack complexity and no user interaction. The public advisory does not identify the endpoint, protocol, serialization format, affected service, or exact communication mode. The associated release notes discuss WPM components and server-initiated versus player-initiated communication, but do not explicitly map one of those modes to this vulnerability; deployment scope should not be inferred from that material alone.

The normalized record describes adjacent-network reachability, low complexity, no authentication, and no user interaction. An attacker therefore does not need to sign in to the application, but must have a network position consistent with the adjacent attack scope. The endpoint, protocol, and vulnerable communication mode have not been publicly identified. No public exploit is recorded in the supplied record, and the record does not identify an exploited-in-the-wild status; this absence does not prove that exploitation has not occurred.

Successful exploitation could provide code execution in the security context of the affected service. The structured impact fields indicate serious confidentiality, integrity, and availability consequences; in practical terms, this could expose monitoring data, alter configuration or monitored state, or interrupt service, depending on process permissions. The record does not establish whether the process runs with elevated OS privileges or whether host-level isolation limits the blast radius. Because no authentication or user interaction is required, compromise of a reachable instance could precede further action against the deployment, but lateral movement is not established by the available evidence.

An attacker who can reach the vulnerable service from an adjacent network may be able to execute code in the security context of the affected service. This could affect the confidentiality, integrity, and availability of the monitoring deployment and data accessible to it. The lack of an application authentication requirement removes an important access-control layer, while the actual OS or service privileges and deployment isolation boundaries are not established by the available evidence. Reachable instances should therefore receive priority review and patching, but vulnerability status alone does not establish that a breach occurred.

1. Upgrade SolarWinds Observability Self-Hosted to version 2026.2.3, the fixed software release identified by SolarWinds.
2. Use the normal SolarWinds upgrade process and verify the entire deployment, including scalability engines, reaches the intended fixed release. The release notes state that the SolarWinds Installer upgrades all SolarWinds Platform products and scalability engines in the deployment.
3. For deployments with WPM players, confirm that default and remote players completed the upgrade. The release notes specifically note that remote passive players with Enable Upgrade disabled are not upgraded automatically.
4. If the upgrade must be delayed, restrict adjacent-network access to the affected service and isolate the management deployment as a precaution. This is defense in depth, not a vendor-confirmed workaround. Do not treat changing the communication mode as a fix because the public material does not identify the vulnerable mode.

1. Inventory every SolarWinds Observability Self-Hosted instance and record its installed release, deployment topology, and communication-mode configuration.
2. Prioritize instances within the affected version boundary described above and instances using the mode referenced by the advisory. Because the public advisory does not name that mode, retain the uncertainty and confirm the condition with SolarWinds if necessary.
3. For WPM deployments, enumerate the default polling-engine player, remote passive players, and remote active players, then verify upgrade status for each. Pay particular attention to remote passive players with Enable Upgrade disabled, because the release notes state that these players are not upgraded automatically.
4. After remediation, independently verify the product release and every scalability engine, not only the central server.
5. Review network telemetry and host monitoring for unexpected unauthenticated connections from adjacent network segments, unexpected process or service changes, or other anomalous execution around the affected service. These are precautionary review points, not vendor-published indicators for this vulnerability.
6. The supplied record and inspected vendor material do not provide a CVE-specific IOC or log signature. The absence of such evidence does not prove that a system is safe or was not exploited.