CVE-2026-18854: Shandong Hoteam PDM SQLi Vulnerability

CVE-2026-18854 Overview

CVE-2026-18854 is a SQL injection vulnerability in Shandong Hoteam PDM Product Data Management System versions up to 8.3.10. The flaw resides in the GetStoredClassByFilter function within /Base/BaseService.asmx/DataService. Attackers can manipulate the FilterString argument to inject arbitrary SQL statements into backend database queries. The vulnerability is exploitable remotely over the network without authentication or user interaction. Public disclosure of the exploit technique has occurred, and the vendor did not respond to disclosure attempts, leaving affected deployments without an official patch.

Critical Impact
Unauthenticated remote attackers can inject SQL commands through the FilterString parameter, potentially exposing or modifying data stored in the PDM database.

Affected Products

Shandong Hoteam PDM Product Data Management System versions up to 8.3.10
/Base/BaseService.asmx/DataService web service endpoint
Deployments exposing the GetStoredClassByFilter function to untrusted networks

Discovery Timeline

2026-08-05 - CVE-2026-18854 published to NVD
2026-08-05 - Last updated in NVD database

Technical Details for CVE-2026-18854

Vulnerability Analysis

The vulnerability is classified under [CWE-74] as an improper neutralization of special elements in output used by a downstream component (injection). The affected component is a .asmx SOAP/ASP.NET web service, /Base/BaseService.asmx/DataService, which exposes the GetStoredClassByFilter method. This method accepts a client-supplied FilterString argument that is concatenated into a SQL query executed against the PDM backend database.

Because the endpoint does not require authentication and accepts network requests, an attacker can send crafted SOAP or HTTP POST requests containing malicious SQL fragments in FilterString. The exploit has been publicly disclosed, increasing the likelihood of opportunistic scanning and abuse.

Root Cause

The root cause is the direct inclusion of the FilterString parameter into a SQL statement without parameterized queries or input sanitization. The GetStoredClassByFilter function trusts client input when building the WHERE clause of a database query, allowing SQL syntax to escape the intended filter context.

Attack Vector

Exploitation requires only network reachability to the vulnerable /Base/BaseService.asmx/DataService endpoint. An attacker submits a POST request invoking GetStoredClassByFilter with a FilterString value containing SQL metacharacters such as single quotes, UNION keywords, or stacked queries. The injected payload executes with the database privileges configured for the PDM application service account. Depending on those privileges, attackers may enumerate schemas, extract intellectual property stored in the PDM database, tamper with product data, or pivot to database-level command execution.

No verified proof-of-concept code has been published to a code repository. Technical writeups are referenced through VulDB CVE-2026-18854 and the Feishu Document disclosure.

Detection Methods for CVE-2026-18854

Indicators of Compromise

HTTP POST requests to /Base/BaseService.asmx/DataService or /Base/BaseService.asmx containing SOAP action GetStoredClassByFilter
FilterString values containing SQL syntax such as ', --, ;, UNION SELECT, WAITFOR DELAY, xp_cmdshell, or CHAR() encoding
Anomalous database errors or long-running queries originating from the PDM application service account
Unexpected outbound connections from the PDM database server following suspicious web service calls

Detection Strategies

Deploy web application firewall rules that inspect POST bodies to BaseService.asmx for SQL injection signatures targeting the FilterString parameter
Enable SQL Server or backend database audit logging for the PDM service account to capture unusual query patterns, schema enumeration, or information_schema access
Correlate IIS or ASP.NET application logs with database query logs to identify request-to-query mappings indicative of injection

Monitoring Recommendations

Alert on any HTTP 500 responses from /Base/BaseService.asmx/DataService that coincide with SQL syntax in the request payload
Monitor for spikes in request volume or unusual source IPs interacting with the PDM web service
Track database process creation events and file writes on the SQL host to detect post-exploitation activity

How to Mitigate CVE-2026-18854

Immediate Actions Required

Restrict network access to /Base/BaseService.asmx/DataService to trusted internal management networks only, using firewall or reverse-proxy ACLs
Place a web application firewall in front of the PDM application with signatures blocking SQL injection payloads in the FilterString argument
Reduce database privileges granted to the PDM application service account to the minimum required for normal operation
Increase logging and monitoring on the PDM web service and its backing database

Patch Information

No vendor patch is available. According to the disclosure, Shandong Hoteam was contacted but did not respond. Organizations running affected versions up to 8.3.10 should assume the vulnerability remains unremediated and apply compensating controls until an official fix is released. Track updates through VulDB Vulnerability #385866.

Workarounds

Disable the GetStoredClassByFilter method or the entire BaseService.asmx endpoint if it is not required for business operations
Segment the PDM server so that only authenticated engineering workstations can reach the web service
Apply strict input validation at a reverse proxy, rejecting FilterString values containing SQL metacharacters
Rotate credentials and review database audit logs for evidence of prior exploitation before applying compensating controls

bash

# Example IIS URL Rewrite rule to block requests containing common SQLi tokens in FilterString
# Place in web.config <system.webServer><rewrite><rules>
<rule name="BlockSQLiOnBaseService" stopProcessing="true">
  <match url="^Base/BaseService\.asmx" />
  <conditions logicalGrouping="MatchAny">
    <add input="{QUERY_STRING}" pattern="(?i)(union\s+select|--|;|xp_cmdshell|waitfor\s+delay)" />
    <add input="{HTTP_METHOD}" pattern="POST" />
  </conditions>
  <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Blocked" />
</rule>