CVE-2026-54630: Part-DB: Authenticated RCE via .phar attachment upload served from public/media
Part-DB is an open source inventory management system for electronic components. Prior to version 2.12.1, 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. AttachmentSubmitHandler::renameBlacklistedExtensions() rewrites dangerous extensions (php, phtml, sh, cgi, py, js, html, htaccess, ...) 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. The shipped Apache configuration routes .phar to PHP-FPM, so the stored file is executed as PHP on request. The per-attachment-type extension filter is empty by default and is not consulted by the upload handler in a way that blocks this, and a non-admin user in the default users group can create an attachment type with no filter and attach files to parts. Any authenticated user in the default users group uploads a .phar attachment to a part and fetches it under /media/, executing arbitrary PHP as the www-data web user. Ability to exploit depends on the webserver config, docker image contained the vulnerability by default. This issue has been patched in version 2.12.1.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Part-DBto a version that resolves this vulnerability.Fixed in 2.12.1
Event History
Frequently Asked Questions
Which deployments are exposed to code execution from an uploaded attachment?
Part-DB versions before 2.12.1 are affected when uploaded attachments are stored in the web-served media directory and the web server executes .phar files as PHP. The shipped Apache configuration routes .phar requests to PHP-FPM, and public attachments are the default.
What level of access does an attacker need?
An attacker needs an authenticated account in the default users group; administrator access is not required. Such a user can create an attachment type with no filter, upload a .phar attachment to a part, and request it through /media/.
Do the default attachment extension controls prevent exploitation?
No. The upload handler's blocklist rewrites several dangerous extensions but does not include phar, while the per-attachment-type extension filter is empty by default and does not block the upload in this path.
Under which account does the uploaded code run?
The uploaded .phar is executed as PHP under the www-data web user when it is requested from the media path.