This is a filing-cabinet key left with an employee badge, not a crowbar through the front door
CVE-2026-25606 is a SQL injection flaw in multiple STER search filters affecting all versions before 9.5. CERT Polska says an authenticated attacker can abuse unsafe input handling to read sensitive data belonging to other users, plus any other records the application itself can access. STER is a workplace safety and health management system used to track hazards, employee-related OSH data, accidents, and compliance records; the vendor describes both a Windows deployment model and an evolving Java-based *SterWeb* implementation.
The scary part is the bug class, not the deployment reality. In a vacuum, SQL injection gets people excited, but this one is not unauthenticated internet-edge RCE: it requires a valid account, appears tied to app-level search workflows, and sits in a specialized enterprise product with a much narrower exposed population than commodity web stacks. With no vendor-issued baseline severity to inherit, the first honest assessment lands at = ASSESSED AT MEDIUM.
4 steps from start to impact.
Reach the STER application and obtain a valid session
- Access to the internal network or externally exposed STER/SterWeb instance
- Valid STER credentials
- A live target running a version earlier than 9.5
- This is a niche occupational safety platform, not a broadly exposed internet service
- The published impact explicitly requires authentication
- MFA, SSO, VPN gating, or internal-only hosting can block this step outright
Probe searchable fields with Burp Suite
Burp Suite to identify the vulnerable search-filter parameters and replay modified requests. Because CERT Polska mentions *multiple Search Filters*, the discovery work is probably straightforward once an authenticated workflow is mapped.- Authenticated browser session or API/session cookie
- Ability to reach search/filter functionality
- The attacker still needs product familiarity or time to map the app
- Some deployments may log verbose SQL or application errors during probing
Automate exploitation with sqlmap or manual payloads
sqlmap using the authenticated cookie jar or continue manually. The likely outcome from the public advisory is data extraction rather than arbitrary code execution: other users' records and any data the application's DB account can read.- Confirmed injectable parameter
- Stable authenticated session
- Database responses visible enough for extraction
- Least-privilege DB accounts can cap what is retrievable
- Blind-only behavior slows extraction and increases noise
- EDR or server monitoring may catch follow-on tooling or suspicious process behavior on the app host
Read cross-user or enterprise OSH records
- Application DB account has access to target tables
- Records of interest exist in the deployment
- Published advisory stops at data access; it does not claim full host takeover
- Blast radius is bounded by what the app account and role model expose
The supporting signals.
| In-the-wild status | As of 2026-05-29, I found no KEV entry and no public campaign reporting for this CVE. That keeps this in the *plausible but not pressured* bucket. |
|---|---|
| PoC availability | I found no public GitHub PoC or researcher exploit write-up for CVE-2026-25606. Still, the attack path is conventional authenticated SQLi, so Burp Suite + sqlmap is the obvious weaponization route. |
| EPSS | 0.00034 from the user-provided intel, which is extremely low and consistent with a niche, low-observed exploitation surface. |
| KEV status | Not listed in CISA KEV as of 2026-05-29. |
| CVSS / vector context | There is no vendor-issued baseline score to compare against. NVD shows a CERT.PL CNA CVSS v4 base of 8.7 with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N, which already bakes in the key limiting factor: PR:L authenticated access required. |
| Affected versions | CERT Polska states all STER versions before 9.5 are affected. |
| Fixed version | CERT Polska says the issue was fixed in STER 9.5. A 2025 CIOP-PIB report snippet also states that version 9.5 was produced during that project cycle, even though a public product page still prominently advertises 9.4, so inventory validation matters. |
| Exposure population | CIOP-PIB project material says STER had been deployed in hundreds of enterprises in Poland, not mass-scale global internet exposure. Vendor pages describe MS Windows deployments over TCP/IP and a separately developed SterWeb Java implementation, which points to mostly internal enterprise hosting. |
| Scanner / exposure visibility | This is a poor fit for unauthenticated perimeter scanning. The vulnerability sits behind login and business workflows, so coverage will rely more on authenticated DAST, software inventory, and targeted validation than on internet-wide banner matching. |
| Disclosure / credit | Public disclosure was 2026-05-22 via CERT Polska, which credits Michelin CERT for the report. |
noisgate verdict.
The decisive factor is the attacker position: this flaw requires authenticated access to a specialized enterprise application before exploitation even begins. That makes it a post-auth data-exposure problem with a narrower reachable population, not the kind of vulnerability that reliably turns into immediate broad compromise across a 10,000-host estate.
Why this verdict
- Start point: with no vendor baseline to inherit, an authenticated SQLi with sensitive-data exposure starts in the midrange rather than at emergency level.
- Downward pressure from attacker position: CERT Polska's published impact requires a logged-in user.
PR:Lmeans the attacker is already past identity controls, VPN edges, or app onboarding, which sharply reduces real-world reach. - Downward pressure from exposure population and blast radius: STER is a specialized OSH platform reportedly used in hundreds of enterprises, and the disclosed impact is data access through search filters rather than unauthenticated takeover, wormability, or proven code execution.
Why not higher?
There is no evidence here of unauthenticated exploitation, KEV listing, broad internet exposure, or live attack activity. The public write-up describes unauthorized data access by an authenticated user, not a straight line to server compromise or estate-wide control.
Why not lower?
It is still SQL injection in a business system that can expose other users' records and whatever the application account can read. If an attacker already has credentials, exploitation is technically straightforward and could expose sensitive employee, accident, or compliance data at scale inside that deployment.
What to do — in priority order.
- Restrict STER access paths — Keep STER/SterWeb reachable only from approved admin or OSH user networks, VPN segments, or jump hosts. For a MEDIUM verdict there is no mitigation SLA — use this as a hardening task during normal change control while driving the actual patch inside the 365-day remediation window.
- Tighten account scope — Review who truly needs STER access and strip dormant, generic, or over-privileged accounts. This directly attacks the biggest real-world amplifier — authenticated attacker access — and should stay in place until every instance is patched within the 365-day remediation window.
- Monitor abnormal search behavior — Alert on repeated malformed search-filter requests, unusually broad result harvesting, and access to records outside a user's normal organizational scope. For MEDIUM, there is no mitigation SLA — implement this opportunistically, but do not let it substitute for patching within 365 days.
- Constrain database privileges — Verify the STER application account has only the minimum table and operation rights it needs. This will not fix the injection, but it can materially cap disclosure if an authenticated user reaches the vulnerable filters before you finish patching.
- MFA alone does not solve this. It helps protect the login step, but once a valid session exists the injection path still works.
- Perimeter vulnerability scanning alone will miss a lot here because the flaw is behind authentication and business logic.
- Endpoint AV on user workstations is mostly irrelevant to the vulnerable condition; the issue lives in the STER application and its database interactions.
Crowdsourced verification payload.
Run this on the Windows host where STER is installed or from your software deployment tooling with local file-system access. Invoke it as powershell -ExecutionPolicy Bypass -File .\check-ster-cve-2026-25606.ps1 -Path 'C:\Program Files\STER'; local read access is usually enough, and admin rights help if you also want it to inspect uninstall registry keys.
# check-ster-cve-2026-25606.ps1
# Purpose: determine whether an installed STER instance appears vulnerable to CVE-2026-25606
# Logic: versions earlier than 9.5 are VULNERABLE; 9.5 or later are PATCHED
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
[CmdletBinding()]
param(
[string]$Path
)
function Normalize-Version {
param([string]$Value)
if ([string]::IsNullOrWhiteSpace($Value)) { return $null }
$m = [regex]::Match($Value, '(\d+)(?:\.(\d+))?(?:\.(\d+))?(?:\.(\d+))?')
if (-not $m.Success) { return $null }
$parts = @()
for ($i = 1; $i -le 4; $i++) {
if ($m.Groups[$i].Success) { $parts += [int]$m.Groups[$i].Value } else { $parts += 0 }
}
return [version]::new($parts[0], $parts[1], $parts[2], $parts[3])
}
function Get-RegistrySterVersions {
$roots = @(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
$results = @()
foreach ($root in $roots) {
try {
$items = Get-ItemProperty -Path $root -ErrorAction SilentlyContinue |
Where-Object { $_.DisplayName -match '(^|\s)STER(\s|$)' -or $_.Publisher -match 'Centralny Instytut Ochrony Pracy|CIOP' }
foreach ($item in $items) {
$ver = Normalize-Version $item.DisplayVersion
$results += [pscustomobject]@{
Source = 'Registry'
Name = $item.DisplayName
Path = $item.InstallLocation
Raw = $item.DisplayVersion
Ver = $ver
}
}
} catch {}
}
return $results
}
function Get-FileSterVersions {
param([string]$BasePath)
if ([string]::IsNullOrWhiteSpace($BasePath) -or -not (Test-Path -LiteralPath $BasePath)) {
return @()
}
$results = @()
$targets = Get-ChildItem -LiteralPath $BasePath -Recurse -File -ErrorAction SilentlyContinue |
Where-Object {
$_.Name -match 'STER|SterWeb' -or
$_.VersionInfo.ProductName -match 'STER|SterWeb' -or
$_.VersionInfo.CompanyName -match 'Centralny Instytut Ochrony Pracy|CIOP'
}
foreach ($file in $targets) {
$raw = $file.VersionInfo.ProductVersion
if ([string]::IsNullOrWhiteSpace($raw)) { $raw = $file.VersionInfo.FileVersion }
$ver = Normalize-Version $raw
$results += [pscustomobject]@{
Source = 'File'
Name = $file.Name
Path = $file.FullName
Raw = $raw
Ver = $ver
}
}
return $results
}
$patchedFloor = [version]'9.5.0.0'
$findings = @()
$findings += Get-RegistrySterVersions
if ($Path) { $findings += Get-FileSterVersions -BasePath $Path }
# De-duplicate roughly by path+raw version
$findings = $findings | Sort-Object Source, Path, Raw -Unique
if (-not $findings -or $findings.Count -eq 0) {
Write-Output 'UNKNOWN - No STER installation evidence found in registry or provided path.'
exit 2
}
$valid = $findings | Where-Object { $_.Ver -ne $null }
if (-not $valid -or $valid.Count -eq 0) {
Write-Output 'UNKNOWN - STER found, but version could not be parsed.'
$findings | ForEach-Object { Write-Output ("SOURCE={0} NAME={1} PATH={2} RAW={3}" -f $_.Source, $_.Name, $_.Path, $_.Raw) }
exit 2
}
# Use the highest discovered version as the best indicator; if any clearly vulnerable instance is present, flag it.
$vulnHits = $valid | Where-Object { $_.Ver -lt $patchedFloor }
if ($vulnHits.Count -gt 0) {
Write-Output 'VULNERABLE - Found STER version earlier than 9.5.'
$vulnHits | ForEach-Object { Write-Output ("SOURCE={0} NAME={1} PATH={2} VERSION={3}" -f $_.Source, $_.Name, $_.Path, $_.Ver) }
exit 1
}
$patchedHits = $valid | Where-Object { $_.Ver -ge $patchedFloor }
if ($patchedHits.Count -gt 0) {
Write-Output 'PATCHED - Found STER version 9.5 or later.'
$patchedHits | ForEach-Object { Write-Output ("SOURCE={0} NAME={1} PATH={2} VERSION={3}" -f $_.Source, $_.Name, $_.Path, $_.Ver) }
exit 0
}
Write-Output 'UNKNOWN - STER evidence found, but patch status could not be determined confidently.'
$findings | ForEach-Object { Write-Output ("SOURCE={0} NAME={1} PATH={2} RAW={3}" -f $_.Source, $_.Name, $_.Path, $_.Raw) }
exit 2
If you remember one thing.
Sources
- CERT Polska advisory (English)
- NVD record for CVE-2026-25606
- CIOP-PIB STER product page (English)
- CIOP-PIB STER product page (Polish)
- CIOP-PIB project page noting deployments in hundreds of enterprises and SterWeb Java work
- CIOP-PIB 2025 report snippet referencing STER 9.5
- FIRST EPSS
- CISA Known Exploited Vulnerabilities Catalog
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.