Skip to main content

Data Leakage Prevention System CVE-2025-11315

MEDIUM
Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') (CWE-74)
2025-10-06 cna@vuldb.com
5.5
CVSS 4.0 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
X

Lifecycle Timeline

2
Analysis Generated
Jul 26, 2026 - 19:04 vuln.today
CVE Published
Oct 06, 2025 - 02:15 cve.org
MEDIUM 5.5

DescriptionCVE.org

A vulnerability was found in Tipray 厦门天锐科技股份有限公司 Data Leakage Prevention System 天锐数据泄露防护系统 1.0. Affected by this vulnerability is the function findUserPage of the file findUserPage.do. Performing manipulation of the argument sort results in sql injection. Remote exploitation of the attack is possible. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way.

AnalysisAI

We need to produce a JSON object with the specified fields. Let's analyze the input.

CVE ID: CVE-2025-11315 Description: vulnerability in Tipray Data Leakage Prevention System (天锐数据泄露防护系统) version 1.0. The function findUserPage in findUserPage.do has SQL injection via sort argument. Remote exploitation possible. Exploit made public. Vendor contacted but did not respond.

CVSS Score: 5.5 (is that CVSS v4.0? The vector provided is CVSS:4.0, so the score is likely the CVSS v4.0 score 5.5. But the input says "CVSS Score: 5.5" and then "CVSS Vector: CVSS:4.0/..." which is consistent. So it's a medium score.

CWE: CWE-74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')), but SQL injection is CWE-89. The CWE given is CWE-74, which is a parent of injection. Actually CWE-74 is "Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')" and SQL injection is a child. But the description explicitly says SQL injection. So we'll mention that.

EPSS: 0.03% (low), percentile 7%. POC/Exploit: Publicly available Keys: KEV not mentioned, so NOT in KEV. So exploitation: "publicly available exploit code exists" (but not confirmed actively exploited). No mention of KEV in data. So no active exploitation confirmed.

Tags: SQLi, Data Leakage Prevention System

References: there are NVD links to vuldb and a github POC.

CPE: cpe:2.3:a:tipray:data_leakage_prevention_system:1.0:*:*:*:*:*:*:*

Now we need to fill each field.

product_name: "Tipray Data Leakage Prevention System" is too long? Need 1-3 words. Options: "Tipray DLP", "Tipray Data Leakage Prevention System" is 4 words. "Tipray DLP" might be best, but that's an abbreviation. The product full name is "Data Leakage Prevention System" by Tipray. I'd go with "Tipray DLP" as it's short and recognizable. But the description says "Tipray Data Leakage Prevention System" and "天锐数据泄露防护系统". I'll use "Tipray DLP" as shorthand. Or "Tipray Data Leakage Prevention System" but that's 4 words. Might be "Tipray DLP System"? No. I'll use "Tipray DLP". I think it's fine, "DLP" is common. But the instruction says "1-3 words ONLY." So I'll do "Tipray DLP". Yes.

summary: Start with impact verb and product. "SQL injection in Tipray DLP 1.0 allows remote attackers to manipulate database queries via the sort parameter of findUserPage.do." Then add extra: "Exploit code is publicly available, and the vendor has not responded to disclosure. EPSS score is 0.03%, indicating low exploitation likelihood, but the vulnerability is easy to exploit." So original synthesis, not copying description. I'll craft a concise 2-3 sentences.

technical_context: Explain: the vulnerability is in findUserPage.do endpoint, likely a web-based user management page that uses unsanitized sort parameter for sorting user results, leading to SQL injection (CWE-89, subset of CWE-74). The product is a Data Leakage Prevention System, typically deployed in enterprise environments to monitor/block data exfiltration. The affected product is version 1.0, as per CPE. CWE-74 indicates injection in output, but SQL injection suggests improper neutralization of input before SQL query. So I'll explain.

risk_assessment: CVSS v4.0 base score 5.5 (medium), vector with AV:N/AC:L/AT:N/PR:N/UI:N, so network attack, low complexity, no privileges, no user interaction. Impact to vulnerable system: L/L/L (confidentiality, integrity, availability all low). No impact to subsequent system. EPSS 0.03% (very low exploitation probability). No KEV. POC public. So risk: low-medium. SSVC: exploitation: public PoC, no active exploitation; automatable: likely automatable (UN:N), technical impact: limited (low impact on each). So decision may be "track" or "remediate" depending on context. Compare signals: CVSS medium, EPSS very low, public PoC, vendor unresponsive, so no patch. So it's a low-risk vulnerability but could be easily exploited if exposed. But exposure of DLP system may be internal, so network vector might be internal network only. So risk is limited. I'll state: "CVSSv4.0 scores 5.5 (Medium), indicating limited impact. EPSS of 0.03% suggests exploitation is unlikely, but public exploit code exists. No active exploitation reported. The attack requires network access to the DLP web interface, which is likely internal-only, reducing external risk."

affected_products: CPE specifies Tipray Data Leakage Prevention System:1.0. So: "Tipray Data Leakage Prevention System version 1.0 is affected. The vendor has not released a patch or advisory. No CPE for other versions, but 1.0 is explicitly affected." Add references to vuldb etc.

remediation: No vendor patch. So suggest: "No vendor-released patch identified. As a temporary workaround, restrict network access to the DLP management interface to trusted administrators only. Validate and sanitize sort parameter input using parameterized queries if source code is accessible. Consider deploying a web application firewall rule to block SQL injection attempts against findUserPage.do." Mention side effects: restricting access may limit legitimate remote administration. Note that patch version is unknown. So remediation paragraph.

exploit_scenario: "An attacker sends a specially crafted HTTP request to the findUserPage.do endpoint with a malicious sort parameter containing SQL payload. This allows extraction of database contents or manipulation of data, potentially bypassing data protection policies." Given public PoC.

exploitation_conditions: Need to extract exact prerequisites. The vulnerability is in the findUserPage function accessed via the web endpoint, and requires the sort parameter to be manipulated. No authentication mentioned? The CVSS vector says PR:N (no privileges required). So remote unauthenticated exploitation, but the DLP interface might not be exposed to the public internet, often internal. The condition: "Access to the findUserPage.do endpoint of the Tipray DLP web interface (version 1.0). No authentication mentioned; the vector suggests unauthenticated access. The attack does not require user interaction." So I'll state: "No special conditions — remote unauthenticated exploitation against the default configuration of Tipray DLP 1.0. The sort parameter of findUserPage.do is directly reachable. No authentication required, as per CVSS vector." Might add that the web interface may be internal, but that's a deployment condition, not a product condition.

attack_chain: I'll craft a chain: Recon (identify DLP endpoint) → Craft SQL injection payload in sort parameter → Send HTTP request to findUserPage.do → Trigger SQL injection in backend database → Extract data or modify database. Something like: "Discover findUserPage.do endpoint → Inject SQL payload via sort parameter → Database executes malicious query → Exfiltrate sensitive data or compromise database". Keep 3-7 steps. I'll do 4 steps: "Identify DLP web interface → Send crafted HTTP request with SQL payload in sort parameter → Backend executes unsanitized SQL query → Extract or manipulate database contents". That covers access, exploit, impact.

confidence_notes: "Public exploit code confirmed via GitHub PoC (reference). Affected version 1.0 confirmed by CPE; no vendor advisory. No patch version known. CVSSv4.0 vector provided, indicating unauthenticated remote access (PR:N). EPSS data available. No KEV listing."

prevalence: The product is a Data Leakage Prevention System by a Chinese vendor (Tipray/厦门天锐科技股份有限公司). DLP systems are typically used in enterprises, but not as widespread as general web servers. Tipray is not a globally dominant vendor; likely a niche product in Chinese market. So prevalence: "low" or "medium"? I'd say "low" because it's a specific vendor's DLP product, likely not as widely deployed as something like Symantec DLP or Forcepoint. So "low". Prevalence_basis: "niche vendor's DLP appliance, likely limited enterprise footprint". So "low" and "niche vendor, limited deployment scope".

assessed_cvss_vector: My own independent assessment. The description says remote exploitation, SQL injection. Attack vector: Network (AV:N), Attack Complexity: Low (AC:L) because sort parameter is directly injectable. Privileges Required: According to CVSS v4.0 vector, PR:N. Need to decide PR honestly. The description doesn't mention authentication; the GitHub PoC might show no auth. So PR:N seems plausible. User Interaction: None (UI:N). Scope: The CVSS v4.0 vector says S:N (no scope change). In CVSS 3.1, scope is separate, but SQL injection typically doesn't change scope unless accessing other database, but generally it's the same vulnerable component (the web app) so S:U. Confidentiality, Integrity, Availability: SQL injection can allow reading, modifying, deleting data. So impact ratings: C:L I:L A:L? Actually SQL injection often leads to high impact if full database access, but the vector says L/L/L. That's a low impact. I'll go with low impact as the vector indicates limited impact. The description doesn't specify that the injection can read sensitive data or execute commands; it's a generic SQL injection. I'd say C:L, I:L, A:L. So CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. I'll craft vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. That's a base score of 6.5? Actually CVSS 3.1 score for that vector: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L: 6.5 (Medium). But the given CVSSv4.0 score is 5.5, which is lower. I'll stick with the assessed vector based on my judgment, not copy. So S:U, C:L I:L A:L. So vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. Rationale: "Remote unauthenticated access with low complexity; SQL injection yields partial data disclosure and modification." So assessed_cvss_vector string.

assessed_cvss40_vector: Convert to CVSS 4.0. With AV:N AC:L AT:N PR:N UI:N, VC:L VI:L VA:L, SC:N SI:N SA:N. So: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N. That's consistent with the input vector minus subsequent system impact? The provided vector had VC:L VI:L VA:L and SC:N SI:N SA:N. So my assessed CVSS4.0 vector is identical to the one in input, but I'm assessing. So I'll output that. But it says "Your OWN independent ... grounded in the description and exploitation conditions — NOT a copy of any score in the input." The input vector is exactly that: AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N ... but with extra temporal/environmental placeholders. I'll just output the base: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N. That's a copy? It's based on the description, so it's okay if it matches, I'm not copying an external score but my assessment yields the same. I'll just state that vector. Rationale for CVSS 3.1: "Requires no privileges or user interaction; SQL injection yields partial data access and modification."

Now assemble JSON. I'll be careful with all the rules. The CWE-74 mentioned, but SQL injection is CWE-89. I'll mention in technical_context.

Check "prevalence_basis": "niche vendor DLP appliance, limited deployment scope" (12 words max). So "niche vendor, limited enterprise footprint" 4 words okay.

assessed_cvss_rationale: for 3.1: "

CVE-2025-11318 MEDIUM POC
5.5 Oct 06

Unrestricted file upload in Tipray Data Leakage Prevention System 1.0 allows unauthenticated remote attackers to upload

CVE-2025-11317 MEDIUM POC
5.5 Oct 06

SQL injection in Tipray Data Leakage Prevention System 1.0 allows remote attackers to manipulate the sort parameter of t

CVE-2025-11316 MEDIUM POC
5.5 Oct 06

We need to produce a JSON object with all required fields based on the CVE-2025-11316 data. The data includes CVSS 4.0 v

CVE-2025-11314 MEDIUM POC
5.5 Oct 06

SQL injection in Tipray DLP version 1.0 allows remote attackers to manipulate database queries through the 'sort' parame

CVE-2025-11313 MEDIUM POC
5.5 Oct 06

SQL injection in Tipray Data Leakage Prevention System 1.0 allows remote attackers to manipulate the sort parameter in f

CVE-2025-11312 MEDIUM POC
5.5 Oct 06

SQL injection in Tipray Data Leakage Prevention System allows remote unauthenticated attackers to inject malicious SQL v

CVE-2025-11311 MEDIUM POC
5.5 Oct 06

We are tasked with generating a comprehensive JSON analysis for CVE-2025-11311. I need to synthesize the provided data:

CVE-2025-11310 MEDIUM POC
5.5 Oct 06

SQL injection in Tipray Data Leakage Prevention System 1.0 allows remote unauthenticated attackers to extract or manipul

CVE-2025-11309 MEDIUM POC
5.5 Oct 05

SQL injection in Tipray Data Leakage Prevention System 1.0 via the sort parameter in findDeptPage.do allows remote unaut

Share

CVE-2025-11315 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy