SECURITYHIGHCVE-2026-105158

CVE-2026-105158: RainyGao DocSys SQL Injection via Database Management Component

Unauthenticated SQL injection in DocSys's createDBForMysql function lets remote attackers manipulate backend database operations.

Dylan H.

Security Team

October 5, 2026
4 min read
CVE-2026-105158: RainyGao DocSys SQL Injection via Database Management Component

Affected Products

  • RainyGao DocSys 2.02.0 through 2.02.85

Overview

A SQL injection vulnerability has been publicly disclosed in RainyGao DocSys, an open-source document management system, affecting versions up to 2.02.85. Tracked as CVE-2026-105158, the flaw resides in the BaseController.createDBForMysql function within the BaseController.java file of the product's Database Management component. An attacker can manipulate the url parameter to inject arbitrary SQL, and the attack can be carried out remotely without authentication.

Exploit code for this vulnerability is already public, raising the urgency for any organization running an affected DocSys deployment.


Technical Details

FieldValue
CVE IDCVE-2026-105158
SeverityHigh (CVSS 3.1: 7.3)
CWECWE-89 — SQL Injection
Attack VectorNetwork
AuthenticationNone Required
Privileges RequiredNone
User InteractionNone
ImpactConfidentiality, Integrity, and Availability (Low/Low/Low per CVSS 3.1 vector)
Affected Versions2.02.0 through 2.02.85
Related Endpoint/Manage/resetDatabase.do

How It Works

The vulnerability lives in DocSys's database reset/configuration workflow. The createDBForMysql function builds a MySQL connection or configuration string using a url argument that is not sanitized before being used in a SQL context. Because the related /Manage/resetDatabase.do endpoint does not require authentication, a remote attacker can submit a crafted url value and have it manipulate backend SQL statements directly.

A companion flaw, CVE-2026-105157, also affects DocSys: a path traversal vulnerability in DocController.doGetTmp (/Doc/doGetTmpFile.do) via the path/fileName argument, allowing retrieval of arbitrary files from the server filesystem. Organizations running DocSys should treat both issues as part of the same risk window.


Impact Assessment

Who Is At Risk

Any organization running a public-facing or internally exposed RainyGao DocSys instance between versions 2.02.0 and 2.02.85 is vulnerable, particularly deployments where:

  • The /Manage/resetDatabase.do endpoint is reachable without network-layer restrictions
  • DocSys is used to store or manage sensitive documents, records, or file repositories
  • The underlying MySQL database account used by DocSys has broad privileges

Potential Attack Chains

  1. Unauthenticated Access — Attacker reaches the unauthenticated database-management endpoint
  2. SQL Injection — Attacker manipulates the url parameter to alter backend SQL operations
  3. Data Exposure or Corruption — Depending on the privileges of the DocSys database account, this can expose, modify, or disrupt stored document metadata and records
  4. Chained Exploitation — Combined with the related path traversal flaw (CVE-2026-105157), an attacker could potentially pair data manipulation with arbitrary file retrieval for broader compromise

Vendor Response

According to vulnerability trackers, the DocSys project was notified of the issue via a GitHub/Gitee issue report early on but has not responded. No official patch has been confirmed as of publication. Organizations should not assume a fix is imminent and should prioritize compensating controls.


Mitigation

Immediate Actions

  • Restrict network access to DocSys administrative and database-management endpoints (including /Manage/resetDatabase.do) to trusted internal networks only
  • Disable or remove the database reset/management functionality if it is not actively required in production
  • Apply a Web Application Firewall (WAF) rule to detect and block SQL injection patterns targeting the url parameter
  • Monitor the upstream Gitee repository for a vendor patch and apply it as soon as one is released

Detection Opportunities

  • Review web server and application logs for requests to /Manage/resetDatabase.do containing SQL metacharacters or unexpected url values
  • Monitor database logs for anomalous or malformed queries originating from the DocSys service account
  • Watch for unusual outbound connections or configuration changes following suspicious requests to the management endpoint

Defence-in-Depth

  • Run the DocSys database account with the minimum privileges necessary rather than broad administrative rights
  • Place DocSys behind network segmentation so management interfaces are never directly internet-reachable
  • Maintain regular, tested backups of DocSys databases given the risk of data integrity impact
  • Evaluate whether DocSys remains an actively maintained, appropriately supported platform for sensitive document storage given the lack of vendor response

References