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.
4 steps from start to impact.
Reach the remoting service on TCP/8989
- Target runs affected Sentinel version
- TCP/8989 is reachable from attacker network position
- Windows host is online and Sentinel remoting component is enabled/listening
- 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
Abuse .NET Remoting file primitives
- 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
- 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
Write an ASPX webshell into IIS
- IIS hosts the Sentinel web application
- Attacker can identify a writable path under
\inetpub\wwwroot\Sentinelor equivalent - Application pool permissions permit the write or the remoting service writes with sufficient privilege
- Write permissions may not map cleanly into a web-executable directory on every install
- AV/EDR often catches common webshell families and suspicious
w3wp.exechild-process activity - Locked-down IIS ACLs can break the webshell drop even if file write exists elsewhere
w3wp.exe spawning shells are all high-signal detections.Execute on the Windows host and pivot into clinical data
- 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
- 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
The supporting signals.
| In-the-wild status | No confirmed active exploitation found in the provided intel; not KEV-listed as of 2026-06-02. |
|---|---|
| PoC availability | No public PoC located in the sources reviewed. That matters because the exploit path uses legacy .NET Remoting, which raises attacker effort until tooling appears. |
| EPSS | 0.00% / very low activity per the VulDB snapshot for 2026-06-02. Treat that as directional, not authoritative. |
| KEV status | Not listed in CISA KEV; no known KEV due date pressure. |
| CVSS vector | CVSS: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 versions | Sentinel 10.5.x and later 10.x builds; Sentinel 11.x before 11.6.0. |
| Fixed version | 11.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 reality | VulnCheck/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 context | Sentinel 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 / source | Disclosed 2026-06-02; CNA/source attribution in public aggregators points to VulnCheck. |
noisgate verdict.
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.
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.exefollow-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.
What to do — in priority order.
- 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.
- Restrict IIS write paths — Review ACLs under
\inetpub\wwwroot\Sentineland 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. - Hunt for webshell and IIS abuse — Deploy detections for new
.aspxfiles under Sentinel web roots,w3wp.exechild 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. - 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.
- 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.
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.
# 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
If you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.