According to its its self-reported version number, the version of Jenkins running on the remote web server is Jenkins LTS prior to 2.375.4 or Jenkins weekly prior to 2.394. It is, therefore, affected by multiple vulnerabilities:

  - Apache Commons FileUpload before 1.5 does not limit the number of request parts to be processed resulting     in the possibility of an attacker triggering a DoS with a malicious upload or series of uploads. Note     that, like all of the file upload limits, the new configuration option (FileUploadBase#setFileCountMax) is     not enabled by default and must be explicitly configured. (CVE-2023-24998)

  - High Jenkins 2.270 through 2.393 (both inclusive), LTS 2.277.1 through 2.375.3 (both inclusive) does not     escape the Jenkins version a plugin depends on when rendering the error message stating its     incompatibility with the current version of Jenkins in the plugin manager. This results in a stored cross-     site scripting (XSS) vulnerability exploitable by attackers able to provide plugins to the configured     update sites and have this message shown by Jenkins instances. Exploitation does not require the     manipulated plugin to be installed. Jenkins 2.394, LTS 2.375.4, and LTS 2.387.1 escapes the Jenkins     version a plugin depends on when rendering the error message stating its incompatibility with the current     version of Jenkins. Due to how Jenkins community update sites serve plugin metadata based on the reported     Jenkins core version, it is unlikely that a reasonably up to date Jenkins instance shows the vulnerable     error message in the plugin manager at all. At least one of the following conditions needs to be met: The     Jenkins version used is older than about 13 months (before 2.333 or LTS 2.319.2 as of publication of this     advisory), as all more recent releases of Jenkins receive update site metadata that only includes     compatible versions of plugins. Jenkins has been downgraded from a newer version, and no updated update     site metadata has been requested since, so Jenkins will still display available plugins compatible with     the previously newer version of Jenkins. Custom update site URLs (i.e., not     https://updates.jenkins.io/update-center.json) are configured, and those update sites behave differently.
    We expect that most of these will host a fairly small set of vetted plugins (e.g., an organization's     approved or internal plugins), preventing exploitation through their restrictive inclusion process.
    Jenkins community update sites no longer publish plugin releases with invalid Jenkins core dependencies     since 2023-02-15. This prevents exploitation through those update sites even on versions of Jenkins older     than 13 months. Additionally, the Jenkins security team has confirmed that no plugin release with a core     dependency manipulated to exploit this vulnerability has ever been published by the Jenkins project.
    (CVE-2023-27898)

  - High Jenkins creates a temporary file when a plugin is uploaded from an administrator's computer. Jenkins     2.393 and earlier, LTS 2.375.3 and earlier creates this temporary file in the system temporary directory     with the default permissions for newly created files. If these permissions are overly permissive, they may     allow attackers with access to the Jenkins controller file system to read and write the file before it is     installed in Jenkins, potentially resulting in arbitrary code execution. This vulnerability only affects     operating systems using a shared temporary directory for all users (typically Linux). Additionally, the     default permissions for newly created files generally only allows attackers to read the temporary file.
    Jenkins 2.394, LTS 2.375.4, and LTS 2.387.1 creates the temporary file with more restrictive permissions.
    As a workaround, you can set a different path as your default temporary directory using the Java system     property java.io.tmpdir, if you're concerned about this issue but unable to immediately update Jenkins.
    (CVE-2023-27899)

  - Medium Jenkins 2.393 and earlier, LTS 2.375.3 and earlier is affected by the Apache Commons FileUpload     library's vulnerability CVE-2023-24998. This library is used to process uploaded files via the Stapler web     framework (usually through StaplerRequest#getFile) and MultipartFormDataParser in Jenkins. This allows     attackers to cause a denial of service (DoS) by sending crafted requests to HTTP endpoints processing file     uploads. Jenkins 2.394, LTS 2.375.4, and LTS 2.387.1 limits the number of request parts to be processed to     1000. Specific endpoints receiving only simple form submissions have a lower limit. While the Apache     Commons FileUpload dependency has been updated previously in the 2.392 weekly release, the Jenkins-     specific changes in 2.394 are necessary for Jenkins to be protected. Some Jenkins forms can be very     complex, and these limits apply to all fields and not just fields representing uploaded files. As a     result, legitimate submissions of complex forms that include (possible) file uploads may be affected by     these limits. If that happens, these limits can be changed by setting the Java system properties     hudson.util.MultipartFormDataParser.FILEUPLOAD_MAX_FILES and     org.kohsuke.stapler.RequestImpl.FILEUPLOAD_MAX_FILES to a bigger value, or to -1 to completely disable     them. These releases of Jenkins also introduce additional Java system properties that can be set to     restrict request sizes: hudson.util.MultipartFormDataParser.FILEUPLOAD_MAX_FILE_SIZE and     org.kohsuke.stapler.RequestImpl.FILEUPLOAD_MAX_FILE_SIZE allow limiting the size (in bytes) of individual     fields that can be processed in one multipart/form-data request.
    hudson.util.MultipartFormDataParser.FILEUPLOAD_MAX_SIZE and     org.kohsuke.stapler.RequestImpl.FILEUPLOAD_MAX_SIZE allow limiting the total request size (in bytes) that     can be processed in one multipart/form-data request. By default, Jenkins does not set these size limits.
    Setting these system properties can offer additional protection, but comes at a greater risk of impacting     legitimate use (e.g., when uploading huge file parameters). (CVE-2023-27900, CVE-2023-27901)

  - Medium Jenkins uses temporary directories adjacent to workspace directories, usually with the @tmp name     suffix, to store temporary files related to the build. In pipelines, these temporary directories are     adjacent to the current working directory when operating in a subdirectory of the automatically allocated     workspace. Jenkins-controlled processes, like SCMs, may store credentials in these directories. Jenkins     2.393 and earlier, LTS 2.375.3 and earlier shows these temporary directories when viewing job workspaces,     which allows attackers with Item/Workspace permission to access their contents. Jenkins 2.394, LTS     2.375.4, and LTS 2.387.1 does not list these temporary directories in job workspaces. As a workaround, do     not grant Item/Workspace permission to users who lack Item/Configure permission, if you're concerned about     this issue but unable to immediately update Jenkins. The Java system property     hudson.model.DirectoryBrowserSupport.allowTmpEscape can be set to true to restore the previous behavior.
    (CVE-2023-27902)

  - Low When triggering a build from the Jenkins CLI, Jenkins creates a temporary file on the controller if a     file parameter is provided through the CLI's standard input. Jenkins 2.393 and earlier, LTS 2.375.3 and     earlier creates this temporary file in the default temporary directory with the default permissions for     newly created files. If these permissions are overly permissive, they may allow attackers with access to     the Jenkins controller file system to read and write the file before it is used in the build. This     vulnerability only affects operating systems using a shared temporary directory for all users (typically     Linux). Additionally, the default permissions for newly created files generally only allows attackers to     read the temporary file. Jenkins 2.394, LTS 2.375.4, and LTS 2.387.1 creates the temporary file with more     restrictive permissions. As a workaround, you can set a different path as your default temporary directory     using the Java system property java.io.tmpdir, if you're concerned about this issue but unable to     immediately update Jenkins. (CVE-2023-27903)

  - Low Jenkins 2.393 and earlier, LTS 2.375.3 and earlier prints an error stack trace on agent-related pages     when agent connections are broken. This stack trace may contain information about Jenkins configuration     that is otherwise inaccessible to attackers. Jenkins 2.394, LTS 2.375.4, and LTS 2.387.1 does not display     error stack traces when agent connections are broken. (CVE-2023-27904)

  - Medium update-center2 is the tool used to generate the Jenkins update sites hosted on updates.jenkins.io.
    While it is designed for use by the Jenkins project for this purpose, others may be using it to operate     their own self-hosted update sites. update-center2 3.13 and 3.14 renders the required Jenkins core version     on plugin download index pages (pages like this). This version is taken from plugin metadata without being     sanitized. This results in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able     to provide a plugin for hosting. The following preconditions must both be satisfied for this to be     exploitable in a self-hosted update-center2: The generation of download pages needs to be enabled (i.e.,     the --download-links-directory argument needs to be set). A custom download page template must be used     (--index-template-url argument), and the template used must not prevent JavaScript execution through     Content-Security-Policy. The default template prevents exploitation by declaring a restrictive Content-     Security-Policy. update-center2 3.15 filters out plugin releases with invalid Jenkins core dependencies.
    Administrators hosting their own update sites using update-center2 or a fork thereof are advised to update     it, or integrate the commit 091ef999. This change has been deployed to Jenkins community update sites on     2023-02-15. The Jenkins project has distributed a single plugin release, that exploited this vulnerability     in a harmless way to demonstrate the issue, for two hours on 2023-01-16. No other plugin releases that     exploit this vulnerability have been published. (CVE-2023-27905)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

根據其自我報告的版本號碼，遠端 Web 伺服器上執行的 Jenkins 是 Jenkins LTS 2.375.4 之前版本或 Jenkins 每週版的 2.394 之前版本。因此會受到多個弱點影響：

  - 1.5 版之前的 Apache Commons FileUpload 未限制要處理的要求部分數量，導致攻擊者可能透過惡意上傳或一系列上傳觸發 DoS。請注意，與所有檔案上傳限制一樣，新組態選項 (FileUploadBase#setFileCountMax) 預設為不啟用，且必須明確設定。(CVE-2023-24998)

  - 高。對於 Jenkins 2.270 至 2.393 版 (包括頭尾兩版)、LTS 2.277.1 至 2.375.3 版 (包括頭尾兩版)，當出現錯誤訊息說明它與外掛程式管理器中當前版本的 Jenkins 不兼容時，不會逸出外掛程式依賴的 Jenkins 版本。這會導致攻擊者可惡意利用已儲存的跨網站指令碼 (XSS) 弱點，這些弱點能夠為已設定的更新網站提供外掛程式，並讓 Jenkins 執行個體顯示此訊息。惡意利用不需要安裝受操控的外掛程式。對於 Jenkins 2.394 版、LTS 2.375.4 版及 LTS 2.387.1 版，當出現錯誤訊息說明它與當前版本的 Jenkins 不兼容時，不會逸出外掛程式依賴的 Jenkins 版本。由於 Jenkins 社群根據報告的 Jenkins 核心版本更新網站伺服器外掛程式中繼資料的方式，因此合理更新至最新版本的 Jenkins 執行個體不太可能在外掛程式管理器中顯示有弱點的錯誤訊息。至少須符合下列條件之一：所用的 Jenkins 版本比 13 個月之前的版本更舊 (以本公告發佈時間為標準，舊與 2.333 版或舊於 LTS 2.319.2 版)，因為所有最新的 Jenkins 版本都會收到僅包含相容外掛程式版本的更新網站中繼資料。Jenkins 已從較新版本降級，此後未要求任何更新的更新網站中繼資料，因此 Jenkins 仍會顯示與先前較新版本 Jenkins 相容的可用外掛程式。已設定自訂更新網站 URL (即非 https://updates.jenkins.io/update-center.json)，且這些更新網站的行為有所不同。
    我們預期其中大部分會託管相當少量的經過審查的外掛程式 (例如，經組織核准的或內部的外掛程式)，以防止攻擊者透過其限制性的包含程序進行惡意利用。
    自 2023 年 2 月 15 日的版本起，Jenkins 社群更新網站不再發布具有無效 Jenkins 核心相依性的外掛程式版本。即使在 13 個月之前發佈的 Jenkins 版本上，這也可防止攻擊者透過這些更新網站進行惡意利用。此外，Jenkins 安全性團隊已確認，Jenkins 專案尚未發布任何核心相依性遭到操控以惡意利用此弱點的外掛程式版本。
    (CVE-2023-27898)

  - 當外掛程式從系統管理員的電腦上傳時，High Jenkins 會建立一個暫存檔案。Jenkins 2.393 和更舊版本、LTS 2.375.3 和更舊版本使用新建立檔案的預設權限在系統暫存目錄中建立此暫存檔。如果這些權限過於寬鬆，可讓具有 Jenkins 控制器檔案系統存取權的攻擊者在將檔案安裝到 Jenkins 之前讀取和寫入檔案，進而可能導致任意程式碼執行。此弱點只會影響針對所有使用者使用共用暫存目錄的作業系統 (通常是 Linux)。此外，新建立檔案的預設權限通常只允許攻擊者讀取暫存檔。
    Jenkins 2.394 版、LTS 2.375.4 版和 LTS 2.387.1 版使用更多限制性權限建立暫存檔。
    作為因應措施，如果您擔心此問題，但無法立即更新 Jenkins，則可以使用 Java 系統屬性 java.io.tmpdir 將不同的路徑設定為您的預設暫存目錄。
    (CVE-2023-27899)

  - 中等。Jenkins 2.393 和更舊版本、LTS 2.375.3 和更舊版本受到 Apache Commons FileUpload 程式庫弱點 CVE-2023-24998的影響。此程式庫用於處理透過 Stapler Web 架構 (通常是透過 StaplerRequest#getFile) 和 Jenkins 中的 MultipartFormDataParser 上傳的檔案。攻擊者可藉此將特製要求傳送至處理檔案上傳的 HTTP 端點，進而造成拒絕服務 (DoS)。Jenkins 2.394 版、LTS 2.375.4 版和 LTS 2.387.1 版將要處理的要求部分數量限制為 1000。只接收簡單表單提交的特定端點有一個下限。雖然 Apache Commons FileUpload 相依性之前已在 2.392 週版中更新，但 2.394 中的 Jenkins 特定變更是保護 Jenkins 所必需的。某些 Jenkins 表單可能非常複雜，這些限制適用於所有欄位，而不僅僅是代表上傳檔案的欄位。因此，包含 (可能) 檔案上傳的複雜表單的合法提交可能會受到這些限制影響。如果發生這種情況，可藉由將 Java 系統屬性 hudson.util.MultipartFormDataParser.FILEUPLOAD_MAX_FILES 和 org.kohsuke.stapler.RequestImpl.FILEUPLOAD_MAX_FILES 設定為更大的值來變更這些限制，或設定為 -1 以完全停用。這些 Jenkins 版本也引入了額外的 Java 系統屬性，可用來限制要求大小：hudson.util.MultipartFormDataParser.FILEUPLOAD_MAX_FILE_SIZE 和 org.kohsuke.stapler.RequestImpl.FILEUPLOAD_MAX_FILE_SIZE 允許限制可在一個 multipart/form-data 要求中處理的個別欄位大小 (以位元組為單位)。
    hudson.util.MultipartFormDataParser.FILEUPLOAD_MAX_SIZE 和 org.kohsuke.stapler.RequestImpl.FILEUPLOAD_MAX_SIZE 允許限制可在一個 multipart/form-data 要求中處理的總申請大小 (以位元組為單位)。Jenkins 預設不會設定這些大小限制。
    設定這些系統屬性可提供額外的保護，但影響合法使用的風險更大 (例如，上傳大型檔案參數時)。(CVE-2023-27900、CVE-2023-27901)

  - 中等。Jenkins 使用與工作區目錄相鄰的暫存目錄 (通常具有 @tmp 名稱後置詞) 來儲存與版本相關的暫存檔案。在工作流程中，當在自動配置的工作區的子目錄中操作時，這些暫存目錄與目前的工作目錄相鄰。Jenkins 控制的處理程序 (如 SCM) 可能會將認證儲存在這些目錄中。Jenkins 2.393 和更舊版本、LTS 2.375.3 和更舊版本在檢視工作工作區時會顯示這些暫存目錄，這會允許具有「項目/工作區」權限的攻擊者存取其內容。Jenkins 2.394 版、LTS 2.375.4 版和 LTS 2.387.1 版未在工作工作區中列出這些暫存目錄。因應措施是，如果您擔心此問題但無法立即更新 Jenkins，請勿將「項目/工作區」權限授予缺少「項目/設定」權限的使用者。Java 系統屬性 hudson.model.DirectoryBrowserSupport.allowTmpEscape 可設為 true 以還原先前的行為。
    (CVE-2023-27902)

  - 低。從 Jenkins CLI 觸發版本時，如果檔案參數是透過 CLI 的標準輸入提供的，則 Jenkins 會在控制器上建立一個暫存檔案。Jenkins 2.393 和更舊版本、LTS 2.375.3 和更舊版本使用新建立檔案的預設權限在預設暫存目錄中建立此暫存檔。如果這些權限過於寬鬆，可讓具有 Jenkins 控制器檔案系統存取權的攻擊者在在版本中使用檔案之前讀取和寫入檔案。此弱點只會影響針對所有使用者使用共用暫存目錄的作業系統 (通常是 Linux)。此外，新建立檔案的預設權限通常只允許攻擊者讀取暫存檔。Jenkins 2.394 版、LTS 2.375.4 版和 LTS 2.387.1 版使用更多限制性權限建立暫存檔。作為因應措施，如果您擔心此問題，但無法立即更新 Jenkins，則可以使用 Java 系統屬性 java.io.tmpdir 將不同的路徑設定為您的預設暫存目錄。(CVE-2023-27903)

  - 低。當代理程式連線中斷時，Jenkins 2.393 和更舊版本、LTS 2.375.3 和更舊版本會在代理程式相關頁面上列印錯誤堆疊追踪。此堆疊追踪可能包含攻擊者無法存取的 Jenkins 組態相關資訊。代理程式連線中斷時，Jenkins 2.394 版、LTS 2.375.4 版和 LTS 2.387.1 版不會顯示錯誤堆疊追踪。(CVE-2023-27904)

  - 中等。update-center2 是用來產生在 updates.jenkins.io 上託管的 Jenkins 更新網站的工具。
    雖然 Jenkins 專案專為此而設計，但其他人可以使用它來操作自己的自我託管更新網站。update-center2 3.13 版和 3.14 版在外掛程式下載索引頁面 (類似頁面) 上呈現所需的 Jenkins 核心版本。此版本取自外掛程式的中繼資料，未經處理。這會導致攻擊者利用已儲存的跨網站指令碼 (XSS) 弱點，為託管提供外掛程式。必須同時滿足下列前置條件，此弱點才會在自我託管的 update-center2 中遭到惡意利用：需要啟用下載頁面的產生 (即，需要設定 --download-links-directory 引數)。必須使用自訂下載頁面範本 (--index-template-url 引數)，且所使用的範本不得透過 Content-Security-Policy 阻止 JavaScript 執行。預設範本透過宣告限制性內容安全性原則來防止惡意利用。update-center2 3.15 版篩選出含有無效 Jenkins 核心相依性的外掛程式版本。
    建議使用 update-center2 或其分支主控自己的更新網站的系統管理員進行更新，或整合提交 091ef999。此變更已於 2023 年 2 月 15 日部署至 Jenkins 社群更新網站。Jenkins 專案已發佈單一外掛程式版本，於 2023 年 1 月 16 日在兩小時內以無害的方式利用此弱點來示範此問題。尚未發布其他惡意利用此弱點的外掛程式版本。(CVE-2023-27905)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

根据其自我报告的版本号，远程 Web 服务器上运行的 Jenkins 版本低于 Jenkins LTS 2.375.4，或低于 Jenkins weekly 2.394。因此，该应用程序受到多个漏洞的影响：

  - 低于 1.5 版的 Apache Commons FileUpload 未限制要处理的请求部分的数量，导致攻击者可能通过恶意上传或一系列上传触发 DoS。请注意，与所有文件上传限制一样，新配置选项 (FileUploadBase#setFileCountMax) 在默认情况下不会启用，必须进行明确配置。(CVE-2023-24998)

  - 高危 - Jenkins 2.270（含）到 2.393（含），LTS 2.277.1（含）到 2.375.3（含）在插件管理器中显示说明其与 Jenkins 当前版本不兼容的错误消息时，未转义插件所依赖的 Jenkins 版本。这会导致存储型跨站脚本 (XSS) 漏洞，攻击者可向配置的更新站点提供插件，并让 Jenkins 实例显示此消息。利用漏洞无需安装受操纵的插件。Jenkins 2.394、LTS 2.375.4 和 LTS 2.387.1 在显示说明其与 Jenkins 当前版本不兼容的错误消息时，转义了插件所依赖的 Jenkins 版本。由于 Jenkins 社区更新站点根据报告的 Jenkins 核心版本提供插件元数据的方式，合理更新的 Jenkins 实例不可能在插件管理器中显示易受攻击的错误消息。至少需要满足下列条件之一：使用的 Jenkins 版本已超过 13 个月（低于 2.333 或 LTS 2.319.2），因为所有更新的 Jenkins 版本都会收到仅包含兼容插件版本的更新站点元数据。Jenkins 已从更新的版本降级，此后未请求任何更新的更新站点元数据，因此 Jenkins 仍将显示与之前更新的 Jenkins 版本兼容的可用插件。配置了自定义更新站点 URL（即，非 https://updates.jenkins.io/update-center.json），并且这些更新站点的行为有所不同。
    我们预计其中大部分将托管一小部分经过审查的插件（例如，组织批准的插件或内部插件），以防止经由其限制性包含进程利用漏洞。
    自 2023 年 2 月 15 日起，Jenkins 社区更新站点不再发布具有无效 Jenkins 核心依存关系的插件版本。即使在 13 个月之前的 Jenkins 版本上，这也可以防止通过这些更新站点利用漏洞。此外，Jenkins 安全团队已确认 Jenkins 项目从未发布过具有可用于利用此漏洞的核心依存关系的插件版本。
    (CVE-2023-27898)

  - 高危：从管理员的计算机上传插件时，Jenkins 会创建临时文件。Jenkins 2.393 和更早版本，LTS 2.375.3 和更早版本以新创建文件的默认权限在系统临时目录中创建此临时文件。如果这些权限过于宽松，可能会允许具有 Jenkins 控制器文件系统访问权限的攻击者在将文件安装到 Jenkins 中之前对其进行读取和写入，从而可能导致任意代码执行。此漏洞仅影响对所有用户使用共享临时目录的操作系统（典型代表为 Linux）。此外，新创建的文件的默认权限通常只允许攻击者读取临时文件。
    Jenkins 2.394、LTS 2.375.4 和 LTS 2.387.1 使用更多限制性权限创建临时文件。
    作为变通方案，如果您担心此问题但无法立即更新 Jenkins，则可以使用 Java 系统属性 java.io.tmpdir 将不同的路径设置为默认临时目录。
    (CVE-2023-27899)

  - 中危：Jenkins 2.393 和更早版本，LTS 2.375.3 和更早版本受到 Apache Commons FileUpload 库漏洞 CVE-2023-24998 的影响。此库用于通过 Stapler Web 框架（通常通过 StaplerRequest#getFile）和 Jenkins 中的 MultipartFormDataParser 处理上传的文件。这允许攻击者通过向处理文件上传的 HTTP 端点发送构建的请求来造成拒绝服务 (DoS)。Jenkins 2.394、 LTS 2.375.4和 LTS 2.387.1 将要处理的请求部分的数量限制为 1000。对于仅接收简单表单提交的特定端点而言，此限制更低。尽管 Apache Commons FileUpload 依存关系之前已在 2.392 每周版中得到更新，但为了保护 Jenkins，2.394 中特定于 Jenkins 的变更是必要的。一些 Jenkins 表单可能非常复杂，这些限制适用于所有字段，而不仅仅是代表已上传文件的字段。因此，合法提交（可能）包含文件上传的复杂表单会受到这些限制的影响。如果发生这种情况，可通过将 Java 系统属性 hudson.util.MultipartFormDataParser.FILEUPLOAD_MAX_FILES 和 org.kohsuke.stapler.RequestImpl.FILEUPLOAD_MAX_FILES 设置为更大的值来更改这些限制，或设置为 -1 以完全禁用它们。这些 Jenkins 版本还引入了可设置为限制请求大小的其他 Java 系统属性：hudson.util.MultipartFormDataParser.FILEUPLOAD_MAX_FILE_SIZE 和 org.kohsuke.stapler.RequestImpl.FILEUPLOAD_MAX_FILE_SIZE 可用于限制一个 multipart/form-data 请求中可处理的各个字段的大小（以字节为单位）。
    hudson.util.MultipartFormDataParser.FILEUPLOAD_MAX_SIZE 和 org.kohsuke.stapler.RequestImpl.FILEUPLOAD_MAX_SIZE 可用于限制一个 multipart/form-data 请求中可处理的总请求大小（以字节为单位）。默认情况下，Jenkins 不设置这些大小限制。
    设置这些系统属性可提供额外保护，但影响合法使用的风险也更大（例如，上传大型文件参数时）。（CVE-2023-27900、CVE-2023-27901）

  - 中危：Jenkins 使用与工作区目录相邻的临时目录（通常带有 @tmp 名称后缀）来存储与版本相关的临时文件。在管道中，当在自动分配的工作区的子目录中操作时，这些临时目录与当前工作目录相邻。Jenkins 控制的进程（如 SCM）可能在这些目录中存储凭据。Jenkins 2.393 及更早版本、LTS 2.375.3 及更早版本在查看作业工作区时会显示这些临时目录，这允许具有项目/工作区权限的攻击者访问其内容。Jenkins 2.394、 LTS 2.375.4 和 LTS 2.387.1 未在作业工作区中列出这些临时目录。作为变通方案，如果您担心此问题但无法立即更新 Jenkins，则不要向缺少项目/配置权限的用户授予项目/工作区权限。可将 Java 系统属性 hudson.model.DirectoryBrowserSupport.allowTmpEscape 设置为 true 以还原以前的行为。
    (CVE-2023-27902)

  - 低危：从 Jenkins CLI 触发构建时，如果通过 CLI 的标准输入提供了文件参数，Jenkins 会在控制器上创建一个临时文件。Jenkins 2.393 和更早版本，LTS 2.375.3 和更早版本以新创建文件的默认权限在默认临时目录中创建此临时文件。如果这些权限过于宽松，可能会允许具有 Jenkins 控制器文件系统访问权限的攻击者在文件被用于构建之前对其进行读写。此漏洞仅影响对所有用户使用共享临时目录的操作系统（典型代表为 Linux）。此外，新创建的文件的默认权限通常只允许攻击者读取临时文件。Jenkins 2.394、LTS 2.375.4 和 LTS 2.387.1 使用更多限制性权限创建临时文件。作为变通方案，如果您担心此问题但无法立即更新 Jenkins，则可以使用 Java 系统属性 java.io.tmpdir 将不同的路径设置为默认临时目录。(CVE-2023-27903)

  - 低危：当代理连接中断时，Jenkins 2.393 和更早版本、LTS 2.375.3 和更早版本在与代理相关的页面上打印错误堆栈跟踪。此堆栈跟踪可能包含攻击者无法以其他方式访问的有关 Jenkins 配置的信息。代理连接中断时，Jenkins 2.394、LTS 2.375.4 和 LTS 2.387.1 不显示错误堆栈跟踪。(CVE-2023-27904)

  - 中危：update-center2 是用于生成 updates.jenkins.io 上托管的 Jenkins 更新站点的工具。
    虽然它是专为 Jenkins 项目而设计的，但其他人可能会使用它来操作自己的自托管更新站点。 update-center2 3.13 和 3.14 会在插件下载索引页面（类似页面）显示所需的 Jenkins 核心版本。此版本取自插件元数据，未经审查。这会导致存储型跨站脚本 (XSS) 漏洞，攻击者可以借此为虚拟主机提供插件。必须同时满足以下先决条件才能在自托管的 update-center2 中利用此漏洞：需要启用下载页面的生成（即，需要设置 --download-links-directory 参数）。必须使用自定义下载页面模板（--index-template-url 参数），并且所使用的模板不得通过 Content-Security-Policy 阻止 JavaScript 执行。默认模板通过声明限制性 Content-Security-Policy 来防止遭到利用。update-center2 3.15 会过滤掉具有无效 Jenkins 核心依存关系的插件版本。
    建议使用 update-center2 或其分支托管自己的更新站点的管理员进行更新，或集成 commit 091ef999。此变更已于 2023 年 2 月 15 日部署到 Jenkins 社区更新站点。Jenkins 项目已于 2023 年 1 月 16 日发布了一个插件版本，该版本以无害的方式利用此漏洞来演示此问题，过程耗时 2 小时。尚未发布利用此漏洞的其他插件版本。(CVE-2023-27905)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

自己報告されたバージョン番号によると、リモートの Web サーバーで実行されている Jenkins のバージョンは、2.375.4より前の Jenkins LTS または 2.394より前の Jenkins weekly です。そのため、以下の複数の脆弱性の影響を受けます。

  - 1.5以前の Apache Commons FileUpload は、処理されるリクエスト部分の数を制限しません。その結果、攻撃者が悪意のあるアップロードまたは一連のアップロードで DoS を発生させる可能性があります。注意 : すべてのファイルアップロード制限と同様に、新しい設定オプション (FileUploadBase＃setFileCountMax) はデフォルトでは有効ではなく、明示的に構成する必要があります。(CVE-2023-24998)

  - High Jenkins 2.270から 2.393(両方を含む)、LTS 2.277.1から 2.375.3(両方を含む) は、プラグインマネージャーが現在のバージョンの Jenkins と互換性がないことを示すエラーメッセージをレンダリングする際に、プラグインが依存する Jenkins バージョンをエスケープしません。これにより、攻撃者が悪用可能な格納型クロスサイトスクリプティング (XSS) の脆弱性が発生し、設定された更新サイトにプラグインを提供し、このメッセージを Jenkins インスタンスに表示させる可能性があります。悪用には、操作されたプラグインをインストールする必要はありません。- High Jenkins 2.394、LTS 2.375.4、および LTS 2.387.1は、現在のバージョンの Jenkins と互換性がないことを示すエラーメッセージをレンダリングする際に、プラグインが依存する Jenkins バージョンをエスケープします。Jenkins コミュニティ更新サイトが、報告された Jenkins コアバージョンに基づいてプラグインメタデータを提供する方法により、適切で最新の Jenkins インスタンスがプラグインマネージャーで脆弱なエラーメッセージを表示することはほとんどありません。以下の条件のうち、少なくとも 1 つを満たす必要があります。使用されている Jenkins のバージョンは約 13 か月 (このアドバイザリの公開時点では LTS 2.319.2または 2.333より前) より古いものです。これは、Jenkins の最新リリースがすべて、互換性のあるバージョンのプラグインのみを含む更新サイトのメタデータを受信するためです。Jenkins は新しいバージョンからダウングレードされ、その後更新された更新サイトのメタデータがリクエストされていないため、Jenkins は以前の新しいバージョンの Jenkins と互換性のある利用可能なプラグインを表示します。カスタム更新サイト URL (つまり https://updates.jenkins.io/update-center.jsonではない) が設定され、これらの更新サイトが異なる動作をします。
    これらのほとんどは、かなり少数の検証済みプラグインのセット (たとえば、組織の承認済みプラグインまたは内部プラグイン) をホストし、制限されたインクルードプロセスによる悪用を防止すると予想されます。
    Jenkins コミュニティ更新サイトは、2023 年 2 月 15 日以降、無効な Jenkins コア依存関係のあるプラグインリリースを公開しなくなりました。これにより、13 か月以上前のバージョンの Jenkins であっても、これらの更新サイトを通じた悪用が防止されます。さらに、Jenkins セキュリティチームは、この脆弱性を悪用するためにコアの依存関係が操作されたプラグインリリースが Jenkins プロジェクトによって公開されたことはないことを確認しています。
    (CVE-2023-27898)

  - High Jenkins は、管理者のコンピューターからプラグインがアップロードされると、一時ファイルを作成します。Jenkins 2.393とそれより前、LTS 2.375.3とそれより前では、新しく作成されたファイルに対するデフォルトのアクセス許可で、この一時ファイルをシステム一時ディレクトリに作成します。これらのアクセス許可が過度に許容的である場合、Jenkins コントローラーファイルシステムへのアクセス権を持つ攻撃者が、Jenkins にインストールされる前にファイルを読み書きできるようになり、任意のコードが実行される可能性があります。この脆弱性の影響を受けるのは、全ユーザーが共有する一時ディレクトリを使用しているオペレーティングシステム (通常は Linux) のみです。さらに、新しく作成されたファイルのデフォルトのアクセス権では、通常、攻撃者は一時ファイルを読み取ることしかできません。
    Jenkins 2.394、LTS 2.375.4、および LTS 2.387.1は、より制限の厳しいアクセス許可で一時ファイルを作成します。
    この問題が心配であるものの、すぐに Jenkins を更新できない場合、回避策として Java システムプロパティ java.io.tmpdir を使用して、デフォルトの一時ディレクトリとして別のパスを設定できます。
    (CVE-2023-27899)

  - 重要度中 : Jenkins 2.393とそれ以前、LTS 2.375.3とそれ以前は、Apache Commons FileUpload ライブラリの脆弱性の影響を受けます CVE-2023-24998。このライブラリは、Stapler Web フレームワーク (通常は StaplerRequest#getFile を介して)、および Jenkins の MultipartFormDataParser を介して、アップロードされたファイルを処理するために使用されます。これにより、攻撃者は、ファイルのアップロードを処理する細工されたリクエストを HTTP エンドポイントに送信することで、サービス拒否 (DoS) を引き起こすことができます。Jenkins 2.394、LTS 2.375.4、および LTS 2.387.1は、処理されるリクエストパートの数を 1000 に制限します。シンプルなフォーム送信のみを受信する特定のエンドポイントには、下限値があります。Apache Commons FileUpload の依存関係は 2.392ウィークリーリリースで以前に更新されていますが、2.394 の Jenkins 固有の変更は、Jenkins を保護するために必要です。一部の Jenkins フォームは非常に複雑になる可能性があり、これらの制限は、アップロードされたファイルを表すフィールドだけでなく、すべてのフィールドに適用されます。その結果、ファイルのアップロードを含む (可能性のある) 複雑なフォームの正当な送信が、これらの制限の影響を受ける可能性があります。この場合、Java システムプロパティ hudson.util.MultipartFormDataParser.FILEUPLOAD_MAX_FILES、および org.kohsuke.stapler.RequestImpl.FILEUPLOAD_MAX_FILES に大きな値を設定するか、「-1」に設定して完全に無効にすることで、これらの制限を変更できます。Jenkins のこれらのリリースでは、リクエストサイズを制限するために設定できる追加の Java システムプロパティも導入されています。hudson.util.MultipartFormDataParser.FILEUPLOAD_MAX_FILE_SIZE、および org.kohsuke.stapler.RequestImpl.FILEUPLOAD_MAX_FILE_SIZE により、1 つの multipart/form-data リクエストで処理できる個々のフィールドのサイズ (バイト単位) を制限できます。
    hudson.util.MultipartFormDataParser.FILEUPLOAD_MAX_SIZE、および org.kohsuke.stapler.RequestImpl.FILEUPLOAD_MAX_SIZE により、1 つの multipart/form-data リクエストで処理できる合計のリクエストサイズ (バイト単位) を制限できます。デフォルトでは、Jenkins はこれらのサイズ制限を設定しません。
    これらのシステムプロパティを設定すると、追加の保護を提供できますが、正当な使用に影響を与えるリスクが高くなります (例 : 巨大なファイルパラメーターをアップロードするとき)。(CVE-2023-27900、CVE-2023-27901)

  - 重要度中 : Jenkins は、ワークスペースディレクトリに隣接する一時ディレクトリを使用し、通常はビルドに関連する一時ファイルを保存します。パイプラインでは、自動的に割り当てられたワークスペースのサブディレクトリで動作しているとき、これらの一時ディレクトリは既存の作業ディレクトリに隣接しています。SCM などの Jenkins が制御するプロセスは、これらのディレクトリに認証情報を保存する可能性があります。Jenkins 2.393とそれ以前、LTS 2.375.3とそれ以前では、ジョブワークスペースを表示する際にこれらの一時ディレクトリが表示されるため、Item/Workspace のアクセス許可を持つ攻撃者がコンテンツにアクセスする可能性があります。Jenkins 2.394、LTS 2.375.4、および LTS 2.387.1は、これらの一時ディレクトリをジョブワークスペースにリストしません。この問題が心配であるものの Jenkins をすぐに更新できない場合は、回避策として Item/Workspace のアクセス許可を、Item/Configure アクセス許可のないユーザーに付与しないでください。Java システムプロパティ hudson.model.DirectoryBrowserSupport.allowTmpEscape を true に設定すると、以前の動作を復元できます。
    (CVE-2023-27902)

  - 重要度低 : Jenkins CLI からビルドをトリガーするとき、CLI の標準入力を通じてファイルパラメーターが提供されると、Jenkins がコントローラーに一時ファイルを作成します。Jenkins 2.393とそれより前、LTS 2.375.3とそれより前では、新しく作成されたファイルに対するデフォルトのアクセス許可で、この一時ファイルをデフォルト一時ディレクトリに作成します。これらのアクセス許可が過度に許容的である場合、Jenkins コントローラーファイルシステムへのアクセス許可を持つ攻撃者が、ビルドで使用される前にファイルを読み書きできるようになる可能性があります。この脆弱性の影響を受けるのは、全ユーザーが共有する一時ディレクトリを使用しているオペレーティングシステム (通常は Linux) のみです。さらに、新しく作成されたファイルのデフォルトのアクセス権では、通常、攻撃者は一時ファイルを読み取ることしかできません。Jenkins 2.394、LTS 2.375.4、および LTS 2.387.1は、より制限の厳しいアクセス許可で一時ファイルを作成します。この問題が心配であるものの、すぐに Jenkins を更新できない場合、回避策として Java システムプロパティ java.io.tmpdir を使用して、デフォルトの一時ディレクトリとして別のパスを設定できます。(CVE-2023-27903)

  - Low Jenkins 2.393とそれ以前、LTS 2.375.3とそれ以前では、エージェント接続が切断されたときに、エージェント関連ページにエラースタックトレースが出力されます。このスタックトレースには、攻撃者がアクセスできない Jenkins 設定に関する情報が含まれている可能性があります。Jenkins 2.394、LTS 2.375.4、および LTS 2.387.1は、エージェント接続が切断されている場合、エラースタックトレースを表示しません。(CVE-2023-27904)

  -重要度中 : update-center2 は、updates.jenkins.io でホストされている Jenkins 更新サイトを生成するために使用されるツールです。
    これは Jenkins プロジェクトがこの目的で使用するために設計されていますが、他のユーザーがこれを使用して独自の自己ホスト型更新サイトを操作している可能性があります。update-center2 3.13および 3.14は、必要な Jenkins コアバージョンをプラグインダウンロードインデックスページ (このようなページ) にレンダリングします。このバージョンは、サニタイズされずにプラグインメタデータから取得されます。これにより、攻撃者がホスティング用のプラグインを提供でき、悪用可能な蓄積型クロスサイトスクリプティング (XSS) の脆弱性が発生します。自己ホスト型 update-center2 でこれを悪用するには、次の前提条件が両方とも満たされる必要があります。ダウンロードページの生成を有効にする必要があります (つまり、--download-links-directory 引数を設定する必要がある)。カスタムダウンロードページテンプレートを使用する必要があり (--index-template-url 引数)、使用するテンプレートが Content-Security-Policy による JavaScript の実行を妨げてはなりません。デフォルトのテンプレートは、制限的な Content-Security-Policy を宣言することで悪用を防ぎます。update-center2 3.15は、無効な Jenkins コア依存関係があるプラグインリリースを除外します。
    update-center2、またはそのフォークを使用して独自の更新サイトをホストしている管理者は、それを更新するか、コミット 091ef999 を統合することをお勧めします。この変更は、2023 年 2 月 15 日の Jenkins コミュニティ更新サイトにデプロイされました。Jenkins プロジェクトは、この問題を実証するため、この脆弱性を無害な方法で悪用する 1 つのプラグインリリースを 2023 年 1 月 16 日の 2 時間に渡り配布しました。この脆弱性を悪用する他のプラグインリリースは公開されていません。(CVE-2023-27905)

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションの自己報告されたバージョン番号にのみ依存しています。

ID	名稱	產品	系列	已發布	已更新	嚴重性
172394	Jenkins LTS < 2.375.4 / Jenkins weekly < 2.394 Multiple Vulnerabilities	Nessus	CGI abuses	2023/3/9	2024/6/4	critical
172394	Jenkins LTS < 2.375.4/Jenkins 每週版 < 2.394 多個弱點	Nessus	CGI abuses	2023/3/9	2024/6/4	critical
172394	Jenkins LTS < 2.375.4 / Jenkins weekly < 2.394 多个漏洞	Nessus	CGI abuses	2023/3/9	2024/6/4	critical
172394	Jenkins LTS < 2.375.4/ Jenkins weekly < 2.394の複数の脆弱性	Nessus	CGI abuses	2023/3/9	2024/6/4	critical

偵測

搜尋 Plugin

critical

critical

critical

critical