← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-25606 · CWE-89 · Disclosed 2026-05-22

A SQL injection vulnerability has been identified in STER

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

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.

"Authenticated-only SQLi in a niche internal OSH app: real risk, but not a fire drill"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Reach the STER application and obtain a valid session

The attacker first needs network reachability to the STER deployment and a working user account. In practice this means logging into the Windows/networked deployment or the Java-based web implementation described by the vendor before any injection attempt starts.
Conditions required:
  • Access to the internal network or externally exposed STER/SterWeb instance
  • Valid STER credentials
  • A live target running a version earlier than 9.5
Where this breaks in practice:
  • 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
Detection/coverage: External scanners will often miss this because the flaw sits behind authentication and business logic. Asset discovery should key off installed software or named web apps, not just perimeter banners.
STEP 02

Probe searchable fields with Burp Suite

After login, the attacker uses an intercepting proxy such as 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.
Conditions required:
  • Authenticated browser session or API/session cookie
  • Ability to reach search/filter functionality
Where this breaks in practice:
  • The attacker still needs product familiarity or time to map the app
  • Some deployments may log verbose SQL or application errors during probing
Detection/coverage: WAF coverage is weak if the app is internal or uses nonstandard endpoints. App logs, unusual filter syntax, and repeated malformed search requests are the better hunt points.
STEP 03

Automate exploitation with sqlmap or manual payloads

Once one injectable parameter is confirmed, the attacker can pivot to 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.
Conditions required:
  • Confirmed injectable parameter
  • Stable authenticated session
  • Database responses visible enough for extraction
Where this breaks in practice:
  • 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
Detection/coverage: DAST tools may validate the issue if given credentials. Commodity vuln scanners without authenticated workflows are unlikely to prove exploitation.
STEP 04

Read cross-user or enterprise OSH records

The business impact is unauthorized disclosure of workplace safety, employee, accident, and related compliance data stored in STER. That matters to defenders because a low-privileged insider or an attacker with stolen credentials can move laterally across records they should not see.
Conditions required:
  • Application DB account has access to target tables
  • Records of interest exist in the deployment
Where this breaks in practice:
  • 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
Detection/coverage: Look for anomalous search volume, broad result harvesting, and repeated access to records outside a user's normal organizational scope.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusAs 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 availabilityI 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.
EPSS0.00034 from the user-provided intel, which is extremely low and consistent with a niche, low-observed exploitation surface.
KEV statusNot listed in CISA KEV as of 2026-05-29.
CVSS / vector contextThere 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 versionsCERT Polska states all STER versions before 9.5 are affected.
Fixed versionCERT 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 populationCIOP-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 visibilityThis 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 / creditPublic disclosure was 2026-05-22 via CERT Polska, which credits Michelin CERT for the report.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.6/10)

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.

HIGH Affected version range and fixed release (before 9.5 / fixed in 9.5)
MEDIUM Severity assessment based on real-world exposure and attacker-position friction
MEDIUM Lack of public exploitation or PoC evidence as of 2026-05-29

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:L means 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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# 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
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as a credential-dependent internal-app data exposure issue, not an all-hands edge emergency. Inventory every STER/SterWeb instance, confirm whether it is before 9.5, and if you cannot patch immediately, tighten access paths and account scope as hardening steps; for a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window. Complete the actual upgrade to STER 9.5 or later within the noisgate remediation SLA of 365 days, and sooner anywhere the app is externally reachable or shared across many business units.

Sources

  1. CERT Polska advisory (English)
  2. NVD record for CVE-2026-25606
  3. CIOP-PIB STER product page (English)
  4. CIOP-PIB STER product page (Polish)
  5. CIOP-PIB project page noting deployments in hundreds of enterprises and SterWeb Java work
  6. CIOP-PIB 2025 report snippet referencing STER 9.5
  7. FIRST EPSS
  8. CISA Known Exploited Vulnerabilities Catalog
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.