<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 29 Sep 2026 20:05:40 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-81730</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-81730</link>
      <description>&lt;p&gt;Dolibarr 9.0.0 through 23.0.4 saves inbound email attachments under the name supplied in the message&amp;#39;s MIME headers without reducing it to a safe basename. The global saveAttachment() in htdocs/emailcollector/lib/emailcollector.lib.php builds $filepath = $path . $filename . &amp;#39;.&amp;#39; . $ext and hands it to file_put_contents(), and the private saveAttachment() in htdocs/emailcollector/class/emailcollector.class.php writes to $destdir.&amp;#39;/&amp;#39;.$filename; the name reaches both from the attachment&amp;#39;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&amp;#39;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&amp;#39;s SECURITY.md requires, with htdocs read-only, the write is confined to the documents tree and corrupts or forges other objects&amp;#39; 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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Dolibarr 9.0.0 through 23.0.4 saves inbound email attachments under the name supplied in the message&amp;#39;s MIME headers without reducing it to a safe basename. The global saveAttachment() in htdocs/emailcollector/lib/emailcollector.lib.php builds $filepath = $path . $filename . &amp;#39;.&amp;#39; . $ext and hands it to file_put_contents(), and the private saveAttachment() in htdocs/emailcollector/class/emailcollector.class.php writes to $destdir.&amp;#39;/&amp;#39;.$filename; the name reaches both from the attachment&amp;#39;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&amp;#39;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&amp;#39;s SECURITY.md requires, with htdocs read-only, the write is confined to the documents tree and corrupts or forges other objects&amp;#39; 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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-81730</guid>
    </item>
    <item>
      <title>GHSA-jgch-2jr2-87vj</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-jgch-2jr2-87vj</link>
      <description>&lt;p&gt;Dolibarr 9.0.0 through 23.0.4 saves inbound email attachments under the name supplied in the message&amp;#39;s MIME headers without reducing it to a safe basename. The global saveAttachment() in htdocs/emailcollector/lib/emailcollector.lib.php builds $filepath = $path . $filename . &amp;#39;.&amp;#39; . $ext and hands it to file_put_contents(), and the private saveAttachment() in htdocs/emailcollector/class/emailcollector.class.php writes to $destdir.&amp;#39;/&amp;#39;.$filename; the name reaches both from the attachment&amp;#39;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&amp;#39;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&amp;#39;s SECURITY.md requires, with htdocs read-only, the write is confined to the documents tree and corrupts or forges other objects&amp;#39; 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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Dolibarr 9.0.0 through 23.0.4 saves inbound email attachments under the name supplied in the message&amp;#39;s MIME headers without reducing it to a safe basename. The global saveAttachment() in htdocs/emailcollector/lib/emailcollector.lib.php builds $filepath = $path . $filename . &amp;#39;.&amp;#39; . $ext and hands it to file_put_contents(), and the private saveAttachment() in htdocs/emailcollector/class/emailcollector.class.php writes to $destdir.&amp;#39;/&amp;#39;.$filename; the name reaches both from the attachment&amp;#39;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&amp;#39;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&amp;#39;s SECURITY.md requires, with htdocs read-only, the write is confined to the documents tree and corrupts or forges other objects&amp;#39; 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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-jgch-2jr2-87vj</guid>
    </item>
  </channel>
</rss>
