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

Landray EIS 2001 through 2006

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

This is a bad lock on an interior office door, not a hole in the front gate

CVE-2025-22214 is an SQL injection in Landray EIS affecting versions 2001 through 2006, specifically the Message/fi_message_receiver.aspx?replyid= path. The published CVSS vector says the attacker needs *low privileges* (PR:L), so this is not an unauthenticated internet-edge smash-and-grab; it starts with a valid account, session, or equivalent authenticated access to the application.

The vendor's 4.3 / MEDIUM is slightly generous in real enterprise conditions. The decisive friction is the attacker position: an authenticated user against what is usually an internal collaboration portal. With *no KEV listing, no cited in-the-wild exploitation, and only low confidentiality impact in the published scoring*, this lands better as LOW for patch scheduling, not because SQLi is harmless, but because the reachable population and blast radius are both materially narrower than the label suggests.

"Authenticated, likely internal-only SQLi with no exploitation signal: real bug, low patching urgency."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Get a valid EIS foothold

The attacker first needs authenticated access to Landray EIS, whether through a stolen user session, compromised credentials, or an insider account. Tools here are the usual credential-access stack, not an exploit-specific pre-auth chain: commodity phishing kits, infostealers, password reuse, or session theft. That requirement alone makes this a *post-initial-access* problem in many enterprises.
Conditions required:
  • A reachable Landray EIS instance exists
  • The attacker has a valid account, cookie, or equivalent authenticated position
  • The vulnerable fi_message_receiver.aspx path is exposed to that user role
Where this breaks in practice:
  • SSO, MFA, and conditional access can block the initial authenticated foothold
  • Many EIS deployments are intranet-only or VPN-gated
  • Low-privilege users may not hit the vulnerable workflow in normal deployments
Detection/coverage: Unauthenticated scanners will often miss this entirely. Authenticated web app testing or internal DAST is needed to validate reachability.
STEP 02

Reach the injectable endpoint

Once inside, the attacker browses to Message/fi_message_receiver.aspx and manipulates the replyid parameter. Weaponization is straightforward with sqlmap or a hand-rolled request repeater in Burp Suite because the published description identifies the exact parameter. The endpoint-level specificity lowers exploit development effort *after* access is obtained.
Conditions required:
  • The application route exists on the target build
  • The authenticated user can invoke the message receiver page
  • Parameter handling is still vulnerable in the deployed code
Where this breaks in practice:
  • Custom reverse proxies or WAFs may normalize or block obvious metacharacters
  • Error suppression can slow confirmation of injection
  • The feature may be disabled or lightly used in some deployments
Detection/coverage: WAFs may catch noisy payloads; internal app logs and IIS logs can expose abnormal replyid values. Scanner coverage improves if you can replay an authenticated session.
STEP 03

Exploit with SQLi tooling

The attacker uses sqlmap, Burp Intruder, or manual boolean/error-based payloads against replyid to extract data from the backend. The CNA-scored impact only claims *low confidentiality loss* and no integrity/availability loss, so the public record does not support assuming turnkey admin takeover or destructive write access. In practice, the likely win is targeted data disclosure from the app's backing database.
Conditions required:
  • The backend database responses are distinguishable enough to infer injection success
  • The application account has read access to useful data
  • No effective parameterized-query fix or compensating filter is present
Where this breaks in practice:
  • Least-privileged DB accounts can cap what the attacker can see
  • Generic SQLi payloads may fail if the page uses unusual query construction
  • Monitoring may flag repetitive, high-volume sqlmap behavior
Detection/coverage: Look for bursty requests, quote-heavy replyid values, SQL metacharacters, and repeated 500-series errors from a single authenticated principal.
STEP 04

Pull data, not a full-domain collapse

The end state is most plausibly selective application-data exposure through the EIS database context. This is annoying and absolutely worth fixing, but it is not the same operational class as a pre-auth RCE on an internet-facing edge appliance. That gap between *technical flaw type* and *real-world reachability* is why the score comes down.
Conditions required:
  • Useful data exists behind the queried tables
  • The compromised user context is not heavily segmented
  • Defenders do not detect and terminate the authenticated session quickly
Where this breaks in practice:
  • Blast radius stays bounded to the application/database scope described by the public record
  • There is no public evidence here of wormable behavior or unauthenticated chaining
  • Enterprise response can revoke the user/session without emergency infrastructure work
Detection/coverage: DB audit logs, unusual query timing, and anomalous authenticated access to messaging workflows are the best places to look.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence found in the reviewed sources of active exploitation, and no CISA KEV listing was found for this CVE.
Proof-of-concept availabilityA public GitHub technical reference by Zerone0x00 is cited by both MITRE/NVD. That means the vulnerable path and parameter are public, even though I could not independently verify a polished one-click exploit from accessible sources.
EPSSUser-supplied EPSS is 0.00258, which is very low. Third-party views of the same CVE also place it in a low percentile band, reinforcing that there is little observed exploit pressure.
KEV statusNot listed in the CISA Known Exploited Vulnerabilities Catalog.
CVSS meaningAV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N means network-reachable and easy to exercise once authenticated, but with only low confidentiality impact and no claimed integrity or availability impact.
Affected versionsPublished record says Landray EIS 2001 through 2006 are affected, with the vulnerable route identified as Message/fi_message_receiver.aspx?replyid=.
Fixed version / backportsI found no vendor-published fixed version or distro backport in the reviewed sources. Treat patch intelligence as incomplete until Landray publishes a remediation build or advisory.
Exposure / scanning dataI found no public GreyNoise, Shodan, or Censys result tied specifically to this CVE or a reliable Landray EIS fingerprint in accessible sources. That usually means asset discovery will require custom internal fingerprinting rather than relying on commodity internet-search signatures.
DisclosureThe CVE was created/published around 2025-01-02 in MITRE-linked sources, with NVD showing the record and reference shortly thereafter.
Deployment contextLandray states it serves over 30% of PRC top 500 enterprises and positions EIS within enterprise collaboration workflows. That says *material installed base*, but likely in geographically concentrated and often internal-only deployments.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.1/10)

The single biggest downgrade driver is attacker position: this CVE requires authenticated access to an enterprise collaboration application, which makes it a post-foothold problem in many real deployments. With no KEV entry, no reviewed evidence of active exploitation, and a publicly scored impact limited to low confidentiality loss, this does not justify emergency patch handling.

HIGH No public active-exploitation signal / no KEV listing
MEDIUM Real-world exposure assumptions for typical EIS deployments
LOW Availability of a vendor-fixed version in public sources

Why this verdict

  • Baseline starts at 4.3 MEDIUM from the CNA, but that baseline assumes the authenticated prerequisite is just another metric, not the operational choke point it becomes in enterprise environments.
  • Authenticated remote only is a hard downward adjustment. PR:L means the attacker already has a user foothold, stolen session, or insider position; that is not how defenders should rank an edge-exploitable bug.
  • Reachable population is likely narrow because collaboration portals like Landray EIS are commonly intranet, VPN, or SSO gated rather than broadly exposed internet edge services.
  • Impact is modest in the published record: low confidentiality impact, no integrity loss, no availability loss, and no public evidence here of RCE or destructive follow-on built into the flaw itself.
  • Threat pressure is weak: no KEV listing, very low EPSS, and no reviewed exploitation reporting materially reduce urgency.

Why not higher?

If this were unauthenticated against a commonly internet-exposed portal, or if there were confirmed campaigns, KEV status, or credible reports of reliable privilege expansion beyond limited data access, the score would climb fast. None of that is present in the sources reviewed, and the authenticated prerequisite compounds with likely internal placement to cap the real-world risk.

Why not lower?

It is still a real SQL injection in an enterprise application, and those are never zero-risk once an attacker is inside. If your environment actually runs affected EIS builds and exposes them broadly to users, a compromised low-privilege account could still turn this into useful data theft, which keeps it above IGNORE.

05 · Compensating Control

What to do — in priority order.

  1. Keep EIS off the internet — If any Landray EIS nodes are internet-reachable, pull them behind VPN, reverse-proxy allowlists, or private access. For a LOW verdict there is no formal mitigation SLA; treat this as backlog hygiene and complete it in the normal hardening cycle, accelerating only if you discover public exposure.
  2. Constrain access to the messaging workflow — Limit which user groups can reach Message/fi_message_receiver.aspx, and prefer SSO plus conditional access over broad local-account exposure. Again, no SLA for LOW; fold this into your next access-control cleanup window.
  3. Add a targeted WAF or reverse-proxy rule — Inspect and block obviously malicious replyid patterns such as quotes, comment markers, stacked-query syntax, or abnormal length. This is a compensating control, not a fix; for LOW, deploy during normal change control unless the app is externally exposed.
  4. Hunt for authenticated SQLi noise — Review IIS, WAF, and application logs for replyid= requests containing quotes, union, comments, or bursty request sequences that look like sqlmap. There is no mitigation SLA for LOW, but this is a cheap detection uplift you can add immediately.
What doesn't work
  • MFA does not fix the vulnerable query; it only helps with the upstream credential-theft step.
  • EDR on the Windows host won't reliably stop SQLi over HTTP because the attack can stay inside normal web/database request paths.
  • Unauthenticated external vuln scans will often miss this because the CVE requires authenticated reachability to the application flow.
06 · Verification

Crowdsourced verification payload.

Run this from an auditor workstation or jump host that can reach the target web app. Invoke it as powershell -ExecutionPolicy Bypass -File .\Test-Landray-CVE-2025-22214.ps1 -BaseUrl https://eis.example.com -Cookie "ASP.NET_SessionId=..."; no local admin rights are required, but you usually need a valid authenticated session cookie because the CVE is PR:L.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# Test-Landray-CVE-2025-22214.ps1

# Purpose: Safe verification for potential SQLi behavior on Landray EIS Message/fi_message_receiver.aspx?replyid=

# Output: VULNERABLE / PATCHED / UNKNOWN

# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=ERROR


param(
    [Parameter(Mandatory=$true)]
    [string]$BaseUrl,

    [Parameter(Mandatory=$false)]
    [string]$Cookie = "",

    [Parameter(Mandatory=$false)]
    [int]$TimeoutSec = 20
)

$ErrorActionPreference = 'Stop'

function Invoke-Probe {
    param(
        [string]$Url,
        [string]$CookieHeader,
        [int]$Timeout
    )

    $headers = @{}
    if ($CookieHeader -and $CookieHeader.Trim().Length -gt 0) {
        $headers['Cookie'] = $CookieHeader
    }

    try {
        $resp = Invoke-WebRequest -Uri $Url -Method GET -Headers $headers -MaximumRedirection 3 -TimeoutSec $Timeout -UseBasicParsing
        return [pscustomobject]@{
            Ok = $true
            StatusCode = [int]$resp.StatusCode
            Content = [string]$resp.Content
            FinalUrl = [string]$resp.BaseResponse.ResponseUri.AbsoluteUri
        }
    }
    catch {
        $status = $null
        $content = ""
        $finalUrl = ""

        if ($_.Exception.Response) {
            try {
                $status = [int]$_.Exception.Response.StatusCode
            } catch {}
            try {
                $reader = New-Object System.IO.StreamReader($_.Exception.Response.GetResponseStream())
                $content = $reader.ReadToEnd()
                $reader.Close()
            } catch {}
            try {
                $finalUrl = [string]$_.Exception.Response.ResponseUri.AbsoluteUri
            } catch {}
        }

        return [pscustomobject]@{
            Ok = $false
            StatusCode = $status
            Content = [string]$content
            FinalUrl = [string]$finalUrl
        }
    }
}

function Has-SqlError {
    param([string]$Text)

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

    $patterns = @(
        'sql syntax',
        'odbc',
        'oledb',
        'unclosed quotation mark',
        'incorrect syntax near',
        'sqlserver',
        'mysql',
        'native client',
        'exception of type',
        'database error',
        'system\.data\.sqlclient'
    )

    foreach ($p in $patterns) {
        if ($Text -match $p) { return $true }
    }
    return $false
}

try {
    $base = $BaseUrl.TrimEnd('/')
    $endpoint = "$base/Message/fi_message_receiver.aspx"

    # Benign baseline and quote probe. We do NOT use stacked queries or destructive payloads.

    $baselineUrl = "$endpoint?replyid=1"
    $probeUrl = "$endpoint?replyid=1'"

    $baseline = Invoke-Probe -Url $baselineUrl -CookieHeader $Cookie -Timeout $TimeoutSec
    $probe = Invoke-Probe -Url $probeUrl -CookieHeader $Cookie -Timeout $TimeoutSec

    $combined = (($baseline.Content | Out-String) + "`n" + ($probe.Content | Out-String)).ToLowerInvariant()
    $loginIndicators = @('login', 'signin', 'logon', 'passport', 'sso', 'authentication required')
    $looksLikeLogin = $false
    foreach ($li in $loginIndicators) {
        if ($combined -match $li) { $looksLikeLogin = $true; break }
    }

    # UNKNOWN conditions

    if (($baseline.StatusCode -eq 404) -and ($probe.StatusCode -eq 404)) {
        Write-Output 'UNKNOWN'
        exit 2
    }

    if ($looksLikeLogin -and (-not $Cookie -or $Cookie.Trim().Length -eq 0)) {
        Write-Output 'UNKNOWN'
        exit 2
    }

    # Positive signal: quote probe creates SQL error behavior not seen in baseline

    $baselineHasSql = Has-SqlError -Text $baseline.Content.ToLowerInvariant()
    $probeHasSql = Has-SqlError -Text $probe.Content.ToLowerInvariant()

    if (($probeHasSql -and -not $baselineHasSql) -or (($probe.StatusCode -ge 500) -and ($baseline.StatusCode -lt 500))) {
        Write-Output 'VULNERABLE'
        exit 1
    }

    # If endpoint exists and quote probe does not trigger obvious error deltas, treat as PATCHED/NOT EVIDENT

    if (($baseline.StatusCode -in 200,302,401,403,500) -or ($probe.StatusCode -in 200,302,401,403,500)) {
        Write-Output 'PATCHED'
        exit 0
    }

    Write-Output 'UNKNOWN'
    exit 2
}
catch {
    Write-Error $_.Exception.Message
    Write-Output 'UNKNOWN'
    exit 3
}
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: first confirm whether you even run Landray EIS 2001-2006 anywhere and whether any instance is internet-reachable. This is a LOW reassessment, so there is no noisgate mitigation SLA — treat it as backlog hygiene and drive straight through normal remediation planning; if Landray publishes a fixed build, fold it into the noisgate remediation SLA for LOW findings, which is also backlog hygiene rather than an emergency clock. If you discover public exposure or broad user access, pull the app behind private access controls in the current hardening cycle while you wait for a vendor-fixed version, because I found no public patched version in the reviewed sources.

Sources

  1. NVD record for CVE-2025-22214
  2. MITRE CVE record
  3. CWE-89 definition
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS overview
  6. FIRST EPSS API documentation
  7. Landray company/about page
  8. Indusface January 2025 bulletin noting coverage for CVE-2025-22214
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.