Description

Dolibarr 9.0.0 through 23.0.4 saves inbound email attachments under the name supplied in the message's MIME headers without reducing it to a safe basename. The global saveAttachment() in htdocs/emailcollector/lib/emailcollector.lib.php builds $filepath = $path . $filename . '.' . $ext and hands it to file_put_contents(), and the private saveAttachment() in htdocs/emailcollector/class/emailcollector.class.php writes to $destdir.'/'.$filename; the name reaches both from the attachment's own getName() or getFilename() value by way of the record-join, create-ticket and create-project operations. A traversal sequence in the filename therefore survives intact, so any sender who can email a mailbox that an EmailCollector monitors, which is the module's ordinary use for a support or ticket inbox, can place attacker-controlled content outside the per-object attachment directory without holding a Dolibarr account. Under the hardened layout Dolibarr's SECURITY.md requires, with htdocs read-only, the write is confined to the documents tree and corrupts or forges other objects' documents; where htdocs is writable the same primitive reaches a web-executable path. Version 24.0.0 applies dol_sanitizePathName() and dol_sanitizeFileName() before the write.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.2",
  "pubDate": "2026-08-27T20:18:55.480Z",
  "pubdate": "2026-08-27T20:18:55.480Z",
  "executiveSummary": "Dolibarr versions 9.0.0 through 23.0.4 are susceptible to a Path Traversal vulnerability within the EmailCollector module. The vulnerability arises from improper sanitization of attachment filenames extracted from inbound MIME email headers. An unauthenticated attacker can exploit this flaw by sending a specially crafted email to a monitored mailbox, allowing them to write arbitrary files to the server's filesystem.\nThe impact depends heavily on server configuration. In environments where the 'htdocs' directory is writable, an attacker may achieve Remote Code Execution (RCE) by uploading web-executable files. In hardened environments where 'htdocs' is read-only, the vulnerability allows for the corruption or forgery of arbitrary documents within the 'documents' directory tree. This represents a significant security risk, enabling unauthorized data manipulation and potential system compromise without requiring valid Dolibarr user credentials.",
  "technicalDetails": "The vulnerability resides in the EmailCollector module, specifically within the saveAttachment() functions located in htdocs/emailcollector/lib/emailcollector.lib.php and htdocs/emailcollector/class/emailcollector.class.php. The application extracts the filename directly from the MIME headers of inbound email attachments using getName() or getFilename() methods without applying necessary validation or sanitization routines.\nThe root cause is the insecure construction of file paths using untrusted input. In the global saveAttachment() function, the path is formed as $filepath = $path . $filename . '.' . $ext, while the private function constructs the path using $destdir.'/'.$filename. Because the application fails to invoke 'dol_sanitizePathName()' or 'dol_sanitizeFileName()' prior to these operations, directory traversal sequences (e.g., '../') are preserved in the filename string passed to 'file_put_contents()'.\nAn attacker can exploit this by crafting a MIME-encoded email containing an attachment with a malicious filename string, such as '../../../../var/www/html/shell.php'. When the EmailCollector module processes the incoming message as part of ticket, project, or record-join operations, the application resolves the traversal sequence and writes the attachment content to the attacker-specified location on the filesystem.\nThe exploit requires minimal preconditions: the target must have the EmailCollector module enabled and actively monitoring a mailbox. No authentication or privileged access to the Dolibarr instance is required, as the vector is external email delivery. If the web server process has sufficient permissions and the web root is writable, the attacker can upload arbitrary PHP scripts to executable directories, resulting in full system compromise. If the server is hardened to make 'htdocs' read-only, the attacker is limited to the 'documents' tree, which can still lead to unauthorized document replacement or system-wide file integrity compromise.\nThis vulnerability persists across versions 9.0.0 through 23.0.4 and is remediated in version 24.0.0, which introduces mandatory sanitization using 'dol_sanitizePathName()' and 'dol_sanitizeFileName()' to strip dangerous characters and traversal sequences from attachment filenames before disk write operations."
}