<?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://db.gcve.eu</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>Thu, 22 Oct 2026 08:13:31 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-79984</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-79984</link>
      <description>&lt;p&gt;Improper Limitation of a Pathname to a Restricted Directory (&amp;#39;Path Traversal&amp;#39;) vulnerability in Apache Camel Mina SFTP component.&lt;/p&gt;
&lt;p&gt;This issue affects Apache Camel: from 4.18.0 before 4.18.5, from 4.19.0 before 4.22.1.&lt;/p&gt;
&lt;p&gt;The Camel remote-file consumers poll a directory on a remote server and build the absolute remote path of each file by concatenating the configured directory with the file name reported in the server&amp;#39;s directory listing. That concatenation (FtpUtils.absoluteFilePath and GenericFileConsumer) applied no lexical normalization and no check that the result stayed inside the directory being polled, and the resulting path became the operand for every subsequent remote operation on the file: retrieval (FtpOperations.retrieveFile / SftpOperations, reached from GenericFileConsumer where the retrieve name is taken verbatim from GenericFile.getAbsoluteFilePath), deletion when delete=true (GenericFileDeleteProcessStrategy), and renaming when move, preMove, moveFailed or readLock=rename is configured (GenericFileProcessStrategySupport and GenericFileRenameExclusiveReadLockStrategy). Neither isValidFile nor isMatched performed any containment check. A listing entry that is not a single path segment therefore resolved to a path outside the configured polling directory, causing Camel to read, delete or rename files outside it using the endpoint&amp;#39;s own credentials. A listing name is not route-controlled data. It is supplied by the remote server, and the FTP control channel c…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Improper Limitation of a Pathname to a Restricted Directory (&amp;#39;Path Traversal&amp;#39;) vulnerability in Apache Camel Mina SFTP component.&lt;/p&gt;
&lt;p&gt;This issue affects Apache Camel: from 4.18.0 before 4.18.5, from 4.19.0 before 4.22.1.&lt;/p&gt;
&lt;p&gt;The Camel remote-file consumers poll a directory on a remote server and build the absolute remote path of each file by concatenating the configured directory with the file name reported in the server&amp;#39;s directory listing. That concatenation (FtpUtils.absoluteFilePath and GenericFileConsumer) applied no lexical normalization and no check that the result stayed inside the directory being polled, and the resulting path became the operand for every subsequent remote operation on the file: retrieval (FtpOperations.retrieveFile / SftpOperations, reached from GenericFileConsumer where the retrieve name is taken verbatim from GenericFile.getAbsoluteFilePath), deletion when delete=true (GenericFileDeleteProcessStrategy), and renaming when move, preMove, moveFailed or readLock=rename is configured (GenericFileProcessStrategySupport and GenericFileRenameExclusiveReadLockStrategy). Neither isValidFile nor isMatched performed any containment check. A listing entry that is not a single path segment therefore resolved to a path outside the configured polling directory, causing Camel to read, delete or rename files outside it using the endpoint&amp;#39;s own credentials. A listing name is not route-controlled data. It is supplied by the remote server, and the FTP control channel c…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-79984</guid>
    </item>
    <item>
      <title>GHSA-3m83-xh6c-vxmh</title>
      <link>https://db.gcve.eu/vuln/ghsa-3m83-xh6c-vxmh</link>
      <description>&lt;p&gt;Improper Limitation of a Pathname to a Restricted Directory (&amp;#39;Path Traversal&amp;#39;) vulnerability in Apache Camel Mina SFTP component.&lt;/p&gt;
&lt;p&gt;This issue affects Apache Camel: from 4.18.0 before 4.18.5, from 4.19.0 before 4.22.1.&lt;/p&gt;
&lt;p&gt;The Camel remote-file consumers poll a directory on a remote server and build the absolute remote path of each file by concatenating the configured directory with the file name reported in the server&amp;#39;s directory listing. That concatenation (FtpUtils.absoluteFilePath and GenericFileConsumer) applied no lexical normalization and no check that the result stayed inside the directory being polled, and the resulting path became the operand for every subsequent remote operation on the file: retrieval (FtpOperations.retrieveFile / SftpOperations, reached from GenericFileConsumer where the retrieve name is taken verbatim from GenericFile.getAbsoluteFilePath), deletion when delete=true (GenericFileDeleteProcessStrategy), and renaming when move, preMove, moveFailed or readLock=rename is configured (GenericFileProcessStrategySupport and GenericFileRenameExclusiveReadLockStrategy). Neither isValidFile nor isMatched performed any containment check. A listing entry that is not a single path segment therefore resolved to a path outside the configured polling directory, causing Camel to read, delete or rename files outside it using the endpoint&amp;#39;s own credentials. A listing name is not route-controlled data. It is supplied by the remote server, and the FTP control channel c…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Improper Limitation of a Pathname to a Restricted Directory (&amp;#39;Path Traversal&amp;#39;) vulnerability in Apache Camel Mina SFTP component.&lt;/p&gt;
&lt;p&gt;This issue affects Apache Camel: from 4.18.0 before 4.18.5, from 4.19.0 before 4.22.1.&lt;/p&gt;
&lt;p&gt;The Camel remote-file consumers poll a directory on a remote server and build the absolute remote path of each file by concatenating the configured directory with the file name reported in the server&amp;#39;s directory listing. That concatenation (FtpUtils.absoluteFilePath and GenericFileConsumer) applied no lexical normalization and no check that the result stayed inside the directory being polled, and the resulting path became the operand for every subsequent remote operation on the file: retrieval (FtpOperations.retrieveFile / SftpOperations, reached from GenericFileConsumer where the retrieve name is taken verbatim from GenericFile.getAbsoluteFilePath), deletion when delete=true (GenericFileDeleteProcessStrategy), and renaming when move, preMove, moveFailed or readLock=rename is configured (GenericFileProcessStrategySupport and GenericFileRenameExclusiveReadLockStrategy). Neither isValidFile nor isMatched performed any containment check. A listing entry that is not a single path segment therefore resolved to a path outside the configured polling directory, causing Camel to read, delete or rename files outside it using the endpoint&amp;#39;s own credentials. A listing name is not route-controlled data. It is supplied by the remote server, and the FTP control channel c…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-3m83-xh6c-vxmh</guid>
    </item>
  </channel>
</rss>
