← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-0611 · CWE-306 · Disclosed 2026-06-02

Spacelabs Healthcare Sentinel versions 10

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a loaded nail gun left behind a locked maintenance door, not a landmine in the lobby

CVE-2026-0611 is an unauthenticated RCE chain in Spacelabs Healthcare Sentinel affecting 10.5.x and later 10.x builds, plus 11.x before 11.6.0. The exposed weakness is an obsolete HTTP .NET Remoting channel on TCP/8989 that can be abused for arbitrary file read/write; from there, an attacker can drop an ASPX webshell into IIS wwwroot and get code execution on the Windows host. Sentinel is customer-hosted software used for cardiology data management and typically sits on Windows/IIS inside hospital networks.

The vendor's 9.8/CRITICAL score is technically defensible in a lab because exploitation is pre-auth and can end in full server compromise. In production, though, the decisive friction is that port 8989 is reportedly not exposed in a default Sentinel install and must be made reachable through deliberate configuration or network policy changes. That turns many deployments from 'internet RCE' into 'internal network or already-inside-the-hospital RCE,' which is still serious, but not emergency-everywhere serious.

"Critical in theory, but real-world risk drops hard because the attack path depends on a non-default remoting port being exposed"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Reach the remoting service on TCP/8989

The attacker first needs network reachability to Sentinel's obsolete HTTP .NET Remoting endpoint on port 8989. VulnCheck/VulDB indicate this listener is the entry point and that exploitation starts only when that channel is reachable from the attacker's position.
Conditions required:
  • Target runs affected Sentinel version
  • TCP/8989 is reachable from attacker network position
  • Windows host is online and Sentinel remoting component is enabled/listening
Where this breaks in practice:
  • VulnCheck/VulDB say port 8989 is not exposed by default
  • Most hospital deployments keep these systems behind internal firewalls or segmented clinical VLANs
  • Internet exposure usually requires an explicit exception, NAT, ACL, or flat east-west access
Detection/coverage: Network scanners can find open TCP/8989, but version detection is likely weak unless authenticated checks or local inspection are used.
STEP 02

Abuse .NET Remoting file primitives

Using standard .NET Remoting client tooling or a custom serializer client, the attacker sends valid remoting requests to invoke arbitrary file read/write operations. This is the practical exploit primitive that converts a missing-auth bug into filesystem access on the server.
Conditions required:
  • Knowledge of the remoting URI/endpoints
  • Ability to speak the legacy .NET Remoting protocol over HTTP
  • No upstream proxy/WAF blocking malformed or legacy remoting traffic
Where this breaks in practice:
  • Legacy remoting is uncommon, so many opportunistic attackers will skip it unless a ready-made PoC exists
  • Protocol-aware middleboxes or reverse proxies may break unusual remoting traffic
  • Some environments will log or choke on unexpected writes into IIS application paths
Detection/coverage: Low-quality perimeter scanners may miss this entirely; IDS/NSM can still flag unusual HTTP traffic to 8989 or .NET Remoting signatures if custom detections exist.
STEP 03

Write an ASPX webshell into IIS

Once arbitrary write is available, the attacker can place an ASPX webshell into Sentinel's IIS-served directory, then call it over normal web ports for code execution. This is the cleanest weaponization path because it pivots from a niche management protocol into standard IIS execution.
Conditions required:
  • IIS hosts the Sentinel web application
  • Attacker can identify a writable path under \inetpub\wwwroot\Sentinel or equivalent
  • Application pool permissions permit the write or the remoting service writes with sufficient privilege
Where this breaks in practice:
  • Write permissions may not map cleanly into a web-executable directory on every install
  • AV/EDR often catches common webshell families and suspicious w3wp.exe child-process activity
  • Locked-down IIS ACLs can break the webshell drop even if file write exists elsewhere
Detection/coverage: EDR is the best stop here: webshell-on-disk, suspicious file creation under IIS roots, and w3wp.exe spawning shells are all high-signal detections.
STEP 04

Execute on the Windows host and pivot into clinical data

With a webshell or equivalent code-exec foothold, the attacker can run commands as the IIS app identity or service context, harvest configuration and credentials, and access patient data stores or connected systems. From there the blast radius becomes a standard Windows/IIS post-exploitation problem inside a healthcare network.
Conditions required:
  • Successful webshell execution or equivalent code execution
  • Useful local privileges or access to data and service accounts
  • Lateral movement paths to SQL, file shares, AD, EMR/PACS integrations, or backups
Where this breaks in practice:
  • App pool identity may initially be low privilege
  • Segmentation between Sentinel, SQL, and domain infrastructure can contain blast radius
  • Modern EDR, constrained service accounts, and PAM can blunt follow-on privilege escalation
Detection/coverage: EDR should light up on LOLBins, PowerShell, service creation, credential dumping, and lateral-movement behavior. SIEM should also correlate IIS logs, Windows events, and abnormal east-west traffic.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation found in the provided intel; not KEV-listed as of 2026-06-02.
PoC availabilityNo public PoC located in the sources reviewed. That matters because the exploit path uses legacy .NET Remoting, which raises attacker effort until tooling appears.
EPSS0.00% / very low activity per the VulDB snapshot for 2026-06-02. Treat that as directional, not authoritative.
KEV statusNot listed in CISA KEV; no known KEV due date pressure.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — fair for the raw bug, but it assumes network reachability that many real deployments do not grant to TCP/8989.
Affected versionsSentinel 10.5.x and later 10.x builds; Sentinel 11.x before 11.6.0.
Fixed version11.6.0 is the security fix level cited in the CVE text. Note: Health Canada separately says 11.6.0 should be updated to 11.6.1 for a *patient-safety/data-association* issue unrelated to this CVE.
Exposure realityVulnCheck/VulDB say the vulnerable remoting channel is on TCP/8989 and not exposed by default. For most enterprises, that shifts this from broad internet risk to segment-specific internal exposure unless someone explicitly opened it.
Platform contextSentinel is customer-hosted Windows software with IIS/web components; Spacelabs documents paths under \inetpub\wwwroot\Sentinel and says the product resides in the customer's network.
Disclosure / sourceDisclosed 2026-06-02; CNA/source attribution in public aggregators points to VulnCheck.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (7.4/10)

The single biggest downgrade factor is reachability: the vulnerable remoting channel on TCP/8989 is reportedly not exposed by default, so many environments require an internal foothold or a deliberate network exception before exploitation is even possible. That sharply reduces exposed population compared with a normal internet-facing pre-auth RCE, but the impact stays high wherever that port is reachable because the chain ends in Windows/IIS code execution on a clinical application server.

MEDIUM Severity downgrade from vendor CRITICAL to practical HIGH
HIGH Technical impact if TCP/8989 is reachable
MEDIUM Real-world exposure assumption that most deployments do not expose 8989 by default

Why this verdict

  • Vendor baseline starts at 9.8 because this is pre-auth remote compromise with no user interaction and a plausible path to full host takeover.
  • Downward adjustment: attacker position is often internal, not internet. Requiring reachability to a non-default remoting listener implies either flat hospital east-west access or a prior foothold.
  • Downward adjustment: exposed population is narrower. Sentinel is a specialized healthcare product, customer-hosted inside clinical networks, not a mass edge appliance with broad internet footprint.
  • Downward adjustment: modern controls should catch stage 3. Even if the remoting write primitive lands, EDR/AV plus IIS monitoring frequently catches the webshell drop or w3wp.exe follow-on execution.
  • Upward adjustment: blast radius is ugly where reachable. The target is a Windows/IIS server handling clinical workflows and patient data, so successful exploitation is materially damaging.

Why not higher?

This is not automatically internet-reachable based on the best public technical detail available. The exploit depends on a legacy remoting service on TCP/8989 that public reporting says is not exposed by default, and there is no KEV listing or confirmed active exploitation pushing this into emergency territory everywhere.

Why not lower?

If your network can reach the vulnerable remoting channel, the rest of the chain is nasty: no auth, no user interaction, arbitrary file write, webshell, code execution. That is far beyond routine hygiene and absolutely warrants priority handling on exposed or cross-segment-reachable Sentinel servers.

05 · Compensating Control

What to do — in priority order.

  1. Block TCP/8989 to Sentinel — Apply ACLs, Windows Firewall rules, or upstream segmentation so only explicitly required admin paths can reach the remoting listener. For a HIGH verdict, deploy this within 30 days; if any Sentinel host is internet-exposed or cross-zone exposed today, do it immediately.
  2. Restrict IIS write paths — Review ACLs under \inetpub\wwwroot\Sentinel and remove unnecessary write permissions for service identities. This breaks the cleanest webshell weaponization path and should be completed within 30 days while the upgrade is scheduled.
  3. Hunt for webshell and IIS abuse — Deploy detections for new .aspx files under Sentinel web roots, w3wp.exe child processes, suspicious PowerShell/cmd launches, and unusual HTTP traffic to port 8989. Put those detections in place within 30 days because they cover both exploitation attempts and post-exploitation behavior.
  4. Constrain east-west access to clinical servers — Move Sentinel into a tightly scoped application segment and allow only required peers such as SQL, AD, PACS, or EMR integrations. For a HIGH verdict, enforce segmentation changes within 30 days to reduce the reachable population even before full remediation.
What doesn't work
  • MFA alone doesn't help because the exploit path is pre-auth against the remoting service.
  • TLS/HTTPS on the normal web app doesn't fix this if TCP/8989 remains reachable; the problem is the unauthenticated remoting channel, not user login hardening.
  • Perimeter WAF only is weak coverage if traffic reaches the backend listener directly or the remoting service is not fronted by the WAF.
06 · Verification

Crowdsourced verification payload.

Run this on the target Sentinel Windows host from an elevated PowerShell session. Example: powershell -ExecutionPolicy Bypass -File .\check-cve-2026-0611.ps1. It needs local admin rights to read uninstall keys, inspect IIS paths, and enumerate listeners on port 8989.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# check-cve-2026-0611.ps1

# Detect likely exposure state for CVE-2026-0611 on a Sentinel host.

# Exit codes:

#   0 = PATCHED

#   1 = UNKNOWN

#   2 = VULNERABLE


[CmdletBinding()]
param()

$ErrorActionPreference = 'SilentlyContinue'

function Write-Result {
    param(
        [string]$Status,
        [string]$Reason,
        [int]$Code
    )
    Write-Output $Status
    Write-Output $Reason
    exit $Code
}

function Get-VersionFromUninstall {
    $paths = @(
        'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
        'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
    )

    $hits = foreach ($p in $paths) {
        Get-ItemProperty -Path $p | Where-Object {
            $_.DisplayName -match 'Sentinel' -and $_.Publisher -match 'Spacelabs|OSI Systems|Del Mar Reynolds'
        } | Select-Object DisplayName, DisplayVersion, Publisher
    }

    if ($hits) {
        $best = $hits | Where-Object { $_.DisplayVersion } | Select-Object -First 1
        if ($best) { return $best.DisplayVersion }
    }
    return $null
}

function Get-VersionFromFiles {
    $candidates = @(
        'C:\inetpub\wwwroot\Sentinel\Bin\Spacelabs.Lomond.WebPortal.dll',
        'C:\inetpub\wwwroot\Sentinel\Bin\Spacelabs.Lomond.WebPortal.dll.config',
        'C:\Program Files\Spacelabs*\*',
        'C:\Program Files (x86)\Spacelabs*\*'
    )

    foreach ($path in $candidates) {
        $items = Get-ChildItem -Path $path -File -Recurse -ErrorAction SilentlyContinue | Select-Object -First 20
        foreach ($item in $items) {
            $ver = $item.VersionInfo.ProductVersion
            if (-not $ver) { $ver = $item.VersionInfo.FileVersion }
            if ($ver -match '\d+\.\d+(\.\d+)?(\.\d+)?') {
                return $Matches[0]
            }
        }
    }
    return $null
}

function Parse-Version {
    param([string]$VersionText)

    if (-not $VersionText) { return $null }
    if ($VersionText -match '(\d+)\.(\d+)(?:\.(\d+))?(?:\.(\d+))?') {
        $maj = [int]$Matches[1]
        $min = [int]$Matches[2]
        $bld = if ($Matches[3]) { [int]$Matches[3] } else { 0 }
        $rev = if ($Matches[4]) { [int]$Matches[4] } else { 0 }
        return [version]::new($maj,$min,$bld,$rev)
    }
    return $null
}

function Test-AffectedRange {
    param([version]$v)

    if (-not $v) { return $false }

    # Based on public CVE text: affected Sentinel 10.5.x and later 10.x builds,

    # and 11.x before 11.6.0.

    if ($v.Major -eq 10 -and $v.Minor -ge 5) { return $true }
    if ($v.Major -eq 11 -and $v -lt [version]'11.6.0.0') { return $true }
    return $false
}

function Test-PatchedRange {
    param([version]$v)

    if (-not $v) { return $false }
    if ($v.Major -gt 11) { return $true }
    if ($v.Major -eq 11 -and $v -ge [version]'11.6.0.0') { return $true }
    return $false
}

$versionText = Get-VersionFromUninstall
if (-not $versionText) { $versionText = Get-VersionFromFiles }
$parsedVersion = Parse-Version -VersionText $versionText

$listener = Get-NetTCPConnection -State Listen -LocalPort 8989 | Select-Object -First 1
$listenerPresent = $null -ne $listener

$sentinelPath = Test-Path 'C:\inetpub\wwwroot\Sentinel'
$iisWebConfig = Test-Path 'C:\inetpub\wwwroot\Sentinel\Web.config'

$notes = @()
if ($versionText) { $notes += "Detected version: $versionText" } else { $notes += 'Detected version: none' }
$notes += "Listener on 8989: $listenerPresent"
$notes += "Sentinel IIS path present: $sentinelPath"
$notes += "Web.config present: $iisWebConfig"

if (Test-PatchedRange -v $parsedVersion) {
    Write-Result -Status 'PATCHED' -Reason ($notes -join '; ') -Code 0
}

if (Test-AffectedRange -v $parsedVersion) {
    if ($listenerPresent) {
        Write-Result -Status 'VULNERABLE' -Reason ($notes -join '; ') -Code 2
    } else {
        Write-Result -Status 'UNKNOWN' -Reason (($notes + 'Affected version found, but TCP/8989 listener not observed. Exposure may be disabled or not currently active.') -join '; ') -Code 1
    }
}

if ($listenerPresent -and $sentinelPath) {
    Write-Result -Status 'UNKNOWN' -Reason (($notes + 'Sentinel artifacts and TCP/8989 listener observed, but product version could not be confirmed.') -join '; ') -Code 1
}

Write-Result -Status 'UNKNOWN' -Reason (($notes + 'Could not confirm an affected or patched Sentinel version on this host.') -join '; ') -Code 1
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: inventory every Sentinel host, identify any system where TCP/8989 is reachable across trust boundaries, and block that path first. For this HIGH reassessment, the noisgate mitigation SLA is ≤30 days — use that window to enforce segmentation/firewall controls, tighten IIS write permissions, and put webshell/w3wp.exe detections in place; if any host is internet-exposed or broadly cross-segment reachable, patch or isolate it immediately, within hours even though it is not KEV-listed. The noisgate remediation SLA is ≤180 days — upgrade affected Sentinel deployments to 11.6.0 or later, while planning beyond 11.6.0 if you also need the separate 11.6.1 Health Canada quality/safety update.

Sources

  1. MITRE CVE record
  2. NVD entry
  3. VulDB / VulnCheck technical summary
  4. Spacelabs MDS2 for Sentinel
  5. Spacelabs ASP.NET advisory showing Sentinel IIS paths and platform context
  6. Spacelabs data management / Sentinel security features
  7. Health Canada recall for Sentinel V11 11.6.0
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.