No announcement yet.

Curl & Libcurl Package updates

  • Filter
  • Time
  • Show
Clear All
new posts

  • Curl & Libcurl Package updates

    Hi Team,

    We have started to recieve a large number of reports from PCI scans in relation to the below packages which are provided as part of the Imunify360 Installation from your repository.


    The vulnerability appears to be in relation to the below.


    This flaw makes curl overflow a heap based buffer in the SOCKS5 proxy handshake.

    When curl is asked to pass along the hostname to the SOCKS5 proxy to allow that to resolve the address instead of it getting done by curl itself, the maximum length that hostname can be is 255 bytes.

    Upon investigation it appears this is likely related to the below CVE

    The servers in question are largely running CentOS7 and not Cloud Linux so may not be vulnerable based on the Redhat post.

    Could you please review and confirm if they are vulnerable and is so will a patch be be in development

    Thanks in advance.

  • #2

    We have got a confirmation from our developers that CentOS7 servers are not affected.


    • #3
      Thank you for responding and confirming. I now have another.

      We've stated getting reports for the below which is provided by the same package provided as part of Imunify360.

      The remote libcurl install is affected by a cookie injection vulnerability.
      libcurl 7.9.1 < 8.4.0 Cookie Injection

      The version of libcurl installed on the remote host is affected by a cookie injection vulnerability. This flaw allows an attacker to insert cookies at will into a running program using libcurl, if the specific series of conditions are met.

      libcurl performs transfers. In its API, an application creates 'easy handles' that are the individual handles for single transfers.

      libcurl provides a function call that duplicates an easy handle called curl_easy_duphandle.

      If a transfer has cookies enabled when the handle is duplicated, the cookie-enable state is also cloned - but without cloning the actual cookies. If the source handle did not read any cookies from a specific file on disk, the cloned version of the handle would instead store the file name as none (using the four ASCII letters, no quotes).

      Subsequent use of the cloned handle that does not explicitly set a source to load cookies from would then inadvertently load cookies from a file named none - if such a file exists and is readable in the current directory of the program using libcurl. And if using the correct file format of course.​

      Path : /opt/alt/curl/usr/lib64/
      Installed version : 7.64.0
      Fixed version : 8.4.0

      This issue does appear to have been marked as outside of support scope by Redhat at Could you please confirm if this is going to be reviewed within your provided package or not addressed?

      Thanks in advance.


      • #4
        Will clarify the information and get back to you.