Part-DB: Authenticated Remote Code Execution via .phar attachment upload from public/media

An authenticated standard-group user uploads a .phar file as a part attachment and executes it as PHP through the public web directory public/media.

Advisory ID: TP-2026-019
Product: Part-DB (open-source electronics parts and inventory management application)
Vulnerability type: Unrestricted upload of file with dangerous type (CWE-434)
CVE: CVE-2026-54630
CVSS 3.1: 9.6 (Critical) · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
Affected versions: <= 2.12.0
Fixed in: 2.12.1
Vendor advisory: GHSA-w5m7-3xf7-6g7g
Reported: 6 June 2026

Summary

Part-DB is an open-source application for managing electronics parts and inventory. The part-attachment upload handler stores uploaded files under the web-served media directory using the client-supplied file extension, and its extension blocklist does not include phar. Public attachments (the default) are written into public/media/, the Apache document root, and the shipped Apache configuration routes .phar to PHP-FPM, so the stored file is executed as PHP on request. Because a non-admin user in the default group can create an attachment type with no filter and attach files to parts, any authenticated standard user executes arbitrary server-side code by uploading and then fetching a .phar file. turingpoint verified the flow and reported it responsibly; the vendor fixed it in 2.12.1.

Root cause

The part-attachment upload handler takes the client-supplied file extension and writes the file into the web-served media directory. AttachmentSubmitHandler::renameBlacklistedExtensions() rewrites dangerous extensions (php, phtml, sh, cgi, py, js, html, htaccess, and others) to .txt, but phar is absent from the list, so a .phar file keeps its extension. Public attachments (the default) are written into public/media/, which is the Apache document root, and the shipped Apache configuration routes .phar to PHP-FPM, so the file is executed as PHP on request. The per-attachment-type extension filter is empty by default and does not block this path, and a non-admin user in the default group may create an attachment type with no filter and attach files to parts. As a result, any authenticated standard user uploads a .phar file, fetches it under /media/, and reaches server-side code execution.

Proof of Concept

As any user in the default users group:

# 1. create an attachment type with an empty extension filter
# 2. attach shell.phar (PHP payload) as a public attachment to a part:
POST /<...>/attachment    (multipart/form-data, file=shell.phar)

# 3. fetch the file under the web root -> Apache routes .phar to PHP-FPM:
GET /media/<path>/shell.phar

renameBlacklistedExtensions() rewrites php/phtml/sh/... to .txt but leaves phar untouched; public attachments live in public/media/ (the Apache document root), and the shipped Apache configuration maps .phar to PHP-FPM, so the file executes as PHP on request.

Impact

  • Arbitrary server-side PHP code execution by any authenticated user in the default group.
  • Full compromise of the Part-DB instance and its data (inventory, credentials, configuration).
  • Potential foothold into the surrounding system or network through the executed code.

References

Is Something Like This in Your Software?

Our team found this vulnerability in the course of its work. Have your applications tested by the same specialists, with a penetration test from turingpoint.

Request a Pentest