This is a factory intercom that will obey anyone who can reach the wire, but the wire usually stays inside the building
Per the user-provided intel, BarTender 2010, 2016, and 2019 expose an unauthenticated remote code execution flaw in a .NET Remoting service. In plain terms, a network client can talk to a legacy remoting endpoint and feed it untrusted serialized data, which is a class of bug Microsoft explicitly warns can lead to DoS, information disclosure, or RCE when BinaryFormatter-style deserialization crosses a trust boundary. BarTender is a Windows-centric labeling/printing platform with multiple companion services, and vendor documentation shows several network-facing BarTender services and ports in 2019-era deployments.
The vendor's 9.8/CRITICAL label is technically defensible if an attacker can directly reach the vulnerable remoting service. In enterprise reality, though, BarTender usually sits on an internal print, integration, or license host rather than a public edge system, so the decisive friction is attacker position: this is more often a post-initial-access lateral movement primitive than a day-one internet spray target. That drops it out of top-tier emergency territory, but not by much, because once reachable it is unauthenticated, low-complexity, and likely service-context code execution on infrastructure that can disrupt production labeling and printing.
4 steps from start to impact.
Find a reachable BarTender server
nmap or Test-NetConnection. Vendor documentation confirms these services exist in BarTender 2019-era environments and that some accept remote clients.- Network reachability to the target host
- BarTender 2010, 2016, or 2019 installed
- Relevant service started and bound to a reachable interface
- BarTender is typically deployed on internal print or application servers, not broad internet edge infrastructure
- Host firewalls and segmentation often restrict who can talk to these ports
- Some BarTender applications explicitly do not accept remote clients
Talk to the legacy remoting endpoint
- The vulnerable remoting endpoint is reachable
- No extra authentication gate in front of the remoting channel
- The exact ObjectURI / endpoint details may require light recon or reverse engineering if the vendor has not published them
- Non-default service bindings can slow first-pass exploitation
Deliver a deserialization gadget payload
ysoserial.net-style gadget chains or custom payload code, to trigger unsafe object materialization. Microsoft's own guidance is blunt here: BinaryFormatter and related patterns are unsafe with untrusted input and can result in remote code execution.- A usable gadget path exists in the target runtime/application context
- Payload reaches the deserialization sink intact
- Application-specific type restrictions or environment differences can break a stock gadget chain
- Some hosts may crash or only yield DoS before a stable RCE path is tuned
Execute in service context and pivot
- Successful code execution from the remoting service
- Service account has meaningful local privileges or access to shared resources
- Least-privilege service accounts reduce blast radius
- Application allowlisting, EDR containment, and restricted service rights can limit follow-on actions
The supporting signals.
| In-the-wild status | No reviewed evidence of active exploitation for this specific CVE. It is not present in the CISA KEV catalog as reviewed for this assessment. |
|---|---|
| Proof-of-concept availability | No public PoC specific to CVE-2026-25550 found in reviewed primary sources. That said, generic .NET Remoting / unsafe deserialization tradecraft is mature, so lack of a branded PoC should not be mistaken for hard exploitation. |
| EPSS | No CVE-specific EPSS value located in reviewed FIRST EPSS resources. Treat as *unknown*, not *low*. |
| KEV status | Not KEV-listed per the user-provided intel and current CISA KEV catalog. |
| CVSS vector reality check | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H describes the technical path well, but it assumes the attacker can actually reach the remoting service. In real estates that reachability is usually internal-only, which is why the operational score comes down. |
| Affected versions | Per user-provided intel: BarTender 2010, 2016, and 2019 are affected. |
| Fixed / supported path | Vendor update guidance points customers toward BarTender 11.4 and later / 12.x as the current branch. BarTender 2019 is listed as Extended Support Only with EOS dates published by Seagull; 2016 and earlier are effectively legacy from a support standpoint. |
| Exposure surface | Vendor docs show BarTender-era services on TCP 5150, TCP 5160, and TCP 7375 / UDP 7371 among others. The important point is not internet scale; it is that east-west reachability inside the enterprise can be enough. |
| Deployment reality | BarTender commonly lives on print, integration, and licensing servers tied to manufacturing, warehouse, or labeling workflows. That population is meaningful inside large enterprises, but much narrower than browsers, VPNs, or email gateways. |
| Disclosure / attribution | Disclosure date in the supplied intel: 2026-06-04. Researcher / reporting org not identified in reviewed sources. |
noisgate verdict.
The single biggest reason this drops below CRITICAL is attacker position: in most enterprises, the vulnerable BarTender remoting service is reachable from inside the network, not from the public internet. Once that prerequisite is met the bug is ugly, but the reachable population is much smaller than the raw vendor CVSS assumes.
Why this verdict
- Start at the vendor's 9.8 baseline because a reachable unauthenticated remoting deserialization bug is legitimately severe in a vacuum
- Attacker position pulls it down: this usually requires internal network reachability to a BarTender server, which implies post-compromise lateral movement or unusually poor exposure
- Reachable population is limited: BarTender is enterprise software on specialized Windows hosts, not a mass internet-facing platform; many environments will have only a handful of such servers
- Modern controls should block some paths to Step 1: segmentation, Windows Firewall, and server VLAN boundaries materially reduce who can touch the service ports
- It stays HIGH because exploitation is still pre-auth once reachable: no user click, no credentials, and likely code execution in a service context on operational infrastructure
Why not higher?
There is no KEV listing, no reviewed evidence of live campaigns, and no public vendor-backed exploitation bulletin for this CVE at assessment time. More importantly, the most common prerequisite is internal reachability to a niche Windows application server, which sharply narrows victim exposure compared with true internet-edge CRITICALs.
Why not lower?
This is still unauthenticated network-triggered code execution against a server-side service. If an attacker can see the host, the exploitation path is short, and the impact on centralized labeling or print infrastructure can be operationally serious.
What to do — in priority order.
- Restrict BarTender service ports — Apply host firewall and network ACL rules so only approved management, integration, and BarTender client subnets can reach TCP 5150, 5160, 7375 and UDP 7371. For a HIGH verdict, deploy this compensating control within 30 days.
- Isolate legacy BarTender servers — Move BarTender 2010/2016/2019 hosts into dedicated server VLANs or micro-segmented groups with tightly defined east-west policy. This cuts off the most realistic abuse path—lateral movement from a compromised workstation—and should be in place within 30 days.
- Disable unused BarTender services — If Integration, Licensing, or System services are not needed on a given node, stop them and set startup to manual/disabled after application-owner validation. Shrinking the running service set is one of the fastest ways to reduce exposure and should be completed within 30 days.
- Hunt for BarTender child-process abuse — Create EDR detections for
powershell.exe,cmd.exe,wscript.exe,cscript.exe,mshta.exe,rundll32.exe, or suspicious network egress spawned by BarTender services. This does not prevent exploitation, but it improves containment and should be deployed within 30 days. - Constrain service account privileges — Review the logon identity and rights for BarTender services; remove local admin where not strictly required and deny unnecessary network access. This limits blast radius after exploitation and should be implemented within 30 days.
- MFA does not help because the exploit path is described as unauthenticated network service abuse
- Email gateway controls do not help because the primary path is east-west service exploitation, not phishing delivery
- A public-facing WAF generally does not help unless the vulnerable service is somehow fronted by HTTP, which BarTender remoting typically is not
- Patching only SQL Server components does not address this issue; the flaw is in the BarTender remoting service exposure, not just bundled database dependencies
Crowdsourced verification payload.
Run this on the target Windows host where BarTender may be installed: powershell -ExecutionPolicy Bypass -File .\Check-CVE-2026-25550.ps1. Local administrator is recommended so the script can inspect services, uninstall data, and listening ports reliably; standard user often works but may return UNKNOWN on locked-down systems.
#requires -version 5.1
[CmdletBinding()]
param()
# Check-CVE-2026-25550.ps1
# Purpose: Best-effort local exposure check for BarTender 2010/2016/2019 remoting-related risk.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
$ErrorActionPreference = 'SilentlyContinue'
function Get-UninstallEntries {
$paths = @(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
foreach ($p in $paths) {
Get-ItemProperty $p | Where-Object { $_.DisplayName -match 'BarTender' } | Select-Object DisplayName, DisplayVersion, InstallLocation, Publisher
}
}
function Get-BarTenderServices {
Get-Service | Where-Object {
$_.Name -match 'BarTender|Seagull|Maestro' -or $_.DisplayName -match 'BarTender|Seagull|Maestro'
} | Select-Object Name, DisplayName, Status, StartType
}
function Get-ListeningEvidence {
$tcpPorts = 5150,5160,7375
$udpPorts = 7371
$tcp = @()
if (Get-Command Get-NetTCPConnection -ErrorAction SilentlyContinue) {
$tcp = Get-NetTCPConnection -State Listen | Where-Object { $tcpPorts -contains $_.LocalPort }
} else {
$tcp = netstat -na | Select-String -Pattern 'LISTENING' | Select-String -Pattern ':(5150|5160|7375)\s'
}
$udp = @()
if (Get-Command Get-NetUDPEndpoint -ErrorAction SilentlyContinue) {
$udp = Get-NetUDPEndpoint | Where-Object { $udpPorts -contains $_.LocalPort }
} else {
$udp = netstat -na | Select-String -Pattern ':(7371)\s'
}
[PSCustomObject]@{
Tcp = $tcp
Udp = $udp
}
}
$entries = @(Get-UninstallEntries)
$services = @(Get-BarTenderServices)
$listeners = Get-ListeningEvidence
$foundAffected = $false
$foundClearlyNewer = $false
$details = @()
foreach ($e in $entries) {
$name = [string]$e.DisplayName
$ver = [string]$e.DisplayVersion
$details += "$name [$ver]"
if ($name -match '2010|2016|2019') {
$foundAffected = $true
continue
}
if ($name -match '2021|2022|11\.4|11\.5|11\.8|11\.11|12') {
$foundClearlyNewer = $true
continue
}
}
$runningRelevant = $services | Where-Object { $_.Status -eq 'Running' }
$hasPortEvidence = (($listeners.Tcp | Measure-Object).Count -gt 0) -or (($listeners.Udp | Measure-Object).Count -gt 0)
Write-Host '--- BarTender CVE-2026-25550 local check ---'
if ($details.Count -gt 0) {
Write-Host ('Installed entries: ' + ($details -join '; '))
} else {
Write-Host 'Installed entries: none found via standard uninstall registry paths'
}
if (($services | Measure-Object).Count -gt 0) {
Write-Host 'Services:'
$services | Format-Table -AutoSize | Out-String | Write-Host
} else {
Write-Host 'Services: none matched BarTender/Seagull patterns'
}
Write-Host ('Port evidence present: ' + $hasPortEvidence)
if ($foundAffected) {
Write-Host 'VULNERABLE'
if (-not $hasPortEvidence) {
Write-Host 'Note: affected version found, but no expected listening ports were observed during this check. Exposure may still depend on service state/configuration.'
}
exit 1
}
elseif ($foundClearlyNewer -and -not $foundAffected) {
Write-Host 'PATCHED'
exit 0
}
elseif (($entries | Measure-Object).Count -eq 0 -and ($services | Measure-Object).Count -eq 0) {
Write-Host 'PATCHED'
Write-Host 'Note: BarTender does not appear to be installed on this host.'
exit 0
}
else {
Write-Host 'UNKNOWN'
Write-Host 'Note: could not confidently map installed product/version to the affected set.'
exit 2
}
If you remember one thing.
Sources
- Seagull: What Are the Primary Network Ports Used by BarTender?
- Seagull: Automating BarTender
- Seagull: Do I Have to Install SQL Server Express for BarTender to Work?
- Seagull: Updating to the Current Version of BarTender
- Seagull: Seagull Software Technical Support Guidelines
- Microsoft Learn: BinaryFormatter security guide
- FIRST: EPSS data and stats
- CISA: Known Exploited Vulnerabilities Catalog
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.