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.
4 steps from start to impact.
Get a valid EIS foothold
- A reachable Landray EIS instance exists
- The attacker has a valid account, cookie, or equivalent authenticated position
- The vulnerable
fi_message_receiver.aspxpath is exposed to that user role
- 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
Reach the injectable endpoint
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.- 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
- 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
replyid values. Scanner coverage improves if you can replay an authenticated session.Exploit with SQLi tooling
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.- 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
- 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
sqlmapbehavior
replyid values, SQL metacharacters, and repeated 500-series errors from a single authenticated principal.Pull data, not a full-domain collapse
- 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
- 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
The supporting signals.
| In-the-wild status | No public evidence found in the reviewed sources of active exploitation, and no CISA KEV listing was found for this CVE. |
|---|---|
| Proof-of-concept availability | A 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. |
| EPSS | User-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 status | Not listed in the CISA Known Exploited Vulnerabilities Catalog. |
| CVSS meaning | AV: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 versions | Published record says Landray EIS 2001 through 2006 are affected, with the vulnerable route identified as Message/fi_message_receiver.aspx?replyid=. |
| Fixed version / backports | I 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 data | I 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. |
| Disclosure | The CVE was created/published around 2025-01-02 in MITRE-linked sources, with NVD showing the record and reference shortly thereafter. |
| Deployment context | Landray 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. |
noisgate verdict.
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.
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:Lmeans 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.
What to do — in priority order.
- 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.
- 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. - Add a targeted WAF or reverse-proxy rule — Inspect and block obviously malicious
replyidpatterns 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. - Hunt for authenticated SQLi noise — Review IIS, WAF, and application logs for
replyid=requests containing quotes,union, comments, or bursty request sequences that look likesqlmap. There is no mitigation SLA for LOW, but this is a cheap detection uplift you can add immediately.
- 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.
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.
# 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
}
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.