Summary
Part-DB contains an unrestricted file upload vulnerability in its attachment handler, allowing certain authenticated users to upload files with executable extensions into a web-served directory. Where the web server maps the .phar extension to PHP execution, requesting an uploaded attachment may enable arbitrary code execution with the web server's privileges.
Part-DB contains an unrestricted file upload vulnerability in its attachment handler, allowing certain authenticated users to upload files with executable extensions into a web-served directory. Where the web server maps the .phar extension to PHP execution, requesting an uploaded attachment may enable arbitrary code execution with the web server's privileges.
Affected context
The issue occurs in Part-DB deployments where:
- Authenticated users in a group permitted to create attachment types can upload part attachments
- Uploaded files are stored in a publicly accessible media directory
- The upload handler relies on an incomplete extension blocklist
- The web server is configured to process
.pharfiles as PHP
The exposure depends on the effective application permissions, storage location, and web server configuration.
The issue occurs in Part-DB deployments where:
- Authenticated users in a group permitted to create attachment types can upload part attachments
- Uploaded files are stored in a publicly accessible media directory
- The upload handler relies on an incomplete extension blocklist
- The web server is configured to process
.pharfiles as PHP
The exposure depends on the effective application permissions, storage location, and web server configuration.
Exploit preconditions
- Attack surface: Authenticated attachment upload functionality
- Required access: An account with permission to create or upload attachments, potentially through the default users group
- Trigger point: A request for an uploaded attachment under the web-served media path
- Why exploitation is possible: The handler preserves the
.pharextension, stores public attachments beneath the document root, and may allow the web server to route the file to PHP-FPM
- Attack surface: Authenticated attachment upload functionality
- Required access: An account with permission to create or upload attachments, potentially through the default users group
- Trigger point: A request for an uploaded attachment under the web-served media path
- Why exploitation is possible: The handler preserves the
.pharextension, stores public attachments beneath the document root, and may allow the web server to route the file to PHP-FPM
Why this happens
The underlying flaw is insufficient validation of user-controlled upload filenames and extensions. The attachment handler rewrites several known dangerous extensions but omits .phar, allowing a potentially executable file to remain in a web-accessible location. This maps to CWE-434: Unrestricted Upload of File with Dangerous Type, because the application does not reliably constrain uploaded content to non-executable file types or isolate it from server-side execution.
The underlying flaw is insufficient validation of user-controlled upload filenames and extensions. The attachment handler rewrites several known dangerous extensions but omits .phar, allowing a potentially executable file to remain in a web-accessible location. This maps to CWE-434: Unrestricted Upload of File with Dangerous Type, because the application does not reliably constrain uploaded content to non-executable file types or isolate it from server-side execution.
Potential impact
- An attacker could execute arbitrary PHP code with the web server account's privileges
- The application and its stored inventory data may be compromised
- Credentials, configuration data, or uploaded files could be exposed
- The server could be used for persistence, lateral movement, or further compromise
- Availability and integrity of inventory operations could be affected
- An attacker could execute arbitrary PHP code with the web server account's privileges
- The application and its stored inventory data may be compromised
- Credentials, configuration data, or uploaded files could be exposed
- The server could be used for persistence, lateral movement, or further compromise
- Availability and integrity of inventory operations could be affected
General mitigation guidance
Mitigation generally focuses on treating uploads as untrusted data and preventing uploaded content from being interpreted as server-side code.
Defensive patterns include:
- Store uploads outside the web document root whenever possible
- Serve attachments through a controlled download endpoint rather than direct execution-capable paths
- Use an allowlist of permitted file types and reject executable extensions, including alternate interpreter-associated formats
- Validate both the filename and detected file content, rather than relying only on client-provided metadata
- Configure the web server so uploaded directories cannot invoke PHP or other server-side handlers
- Apply restrictive filesystem permissions and least-privilege service accounts
- Preserve safe, non-executable names and isolate uploaded files from application code
Mitigation generally focuses on treating uploads as untrusted data and preventing uploaded content from being interpreted as server-side code.
Defensive patterns include:
- Store uploads outside the web document root whenever possible
- Serve attachments through a controlled download endpoint rather than direct execution-capable paths
- Use an allowlist of permitted file types and reject executable extensions, including alternate interpreter-associated formats
- Validate both the filename and detected file content, rather than relying only on client-provided metadata
- Configure the web server so uploaded directories cannot invoke PHP or other server-side handlers
- Apply restrictive filesystem permissions and least-privilege service accounts
- Preserve safe, non-executable names and isolate uploaded files from application code
How teams detect issues like this
Detection can combine application, web server, and source-code review:
- Search code and configuration for upload destinations beneath document roots
- Review extension blocklists and compare them with all server-supported executable formats
- Identify upload paths that inherit PHP-FPM, CGI, or other interpreter handlers
- Monitor for newly created executable-looking files in public media directories
- Alert on requests for uploaded files that produce dynamic execution responses
- Use static analysis and policy checks to flag unrestricted upload APIs, client-controlled extensions, and missing content validation
Detection can combine application, web server, and source-code review:
- Search code and configuration for upload destinations beneath document roots
- Review extension blocklists and compare them with all server-supported executable formats
- Identify upload paths that inherit PHP-FPM, CGI, or other interpreter handlers
- Monitor for newly created executable-looking files in public media directories
- Alert on requests for uploaded files that produce dynamic execution responses
- Use static analysis and policy checks to flag unrestricted upload APIs, client-controlled extensions, and missing content validation
