远程主机上安装的 Splunk 版本低于测试版本。因此，该应用程序受到 SVD-2024-0718 公告中提及的一个漏洞影响。

  - jackson-databind 2.15.2 及其之前所有版本允许攻击者通过使用循环依存关系的构建对象来造成拒绝服务或其他不明影响。注意：供应商认为，这不是有效的漏洞报告，因为外部攻击者无法执行构建循环数据结构并尝试将其序列化的步骤。(CVE-2023-35116)

  - 在低于 2.7 的 Apache Commons IO 中，当使用不当输入字符串（如 //../foo 或 \\..\foo）调用方法 FileNameUtils.normalize 时，结果为相同值，因此如果调用代码使用此结果构造路径值，则可能提供访问父目录中文件的权限，而非更高权限（进而造成限制的路径遍历）。(CVE-2021-29425)

  - snappy-java 是 snappy 的 Java 端口，是由 Google 开发的快速 C++ 压缩器/解压缩器。目前发现 SnappyInputStream 在解压缩区块大小过大的数据时，容易遭受拒绝服务 (DoS) 攻击。由于缺少区块长度上限检查，可能会发生无法恢复的致命错误。所有 snappy-java 版本（包括最新发布的 1.1.10.3 版本）都容易受到此问题的影响。已在提交“9f8c3cf74”中引入补丁，补丁程序将包含在 1.1.10.4 版本中。建议所有用户都进行升级。无法升级的用户只可接受来自受信任来源的压缩数据。(CVE-2023-43642)

  - snappy-java 是适用于 Java 的快速压缩器/解压缩器。由于未检查乘法，1.1.10.1 之前版本中可能会发生整数溢出，从而导致致命错误。“BitShuffle.java”文件中的“shuffle(int[] input)”函数会接收整数数组，并在上面应用 bitshuffle。其运作方法是将长度乘以 4，然后传递给本机编译的 shuffle 函数。由于未测试长度，因此与 4 相乘可导致整数溢出，并变成小于实际大小的值，甚至是零或负值。如果是负值，则会引发“java.lang.NegativeArraySizeException”异常，从而使程序崩溃。如果是零或太小的值，则之后引用打乱后数组的代码会假设该数组大小较大，这可能造成“java.lang.ArrayIndexOutOfBoundsException”等异常。
    当使用接收双精度型、浮点型、长整型和短整型数据的 `shuffle` 函数时，也存在相同的问题，各函数使用不同乘数可能会导致相同的问题。1.1.10.1 版本中包含针对此漏洞的补丁。(CVE-2023-34453)

  - snappy-java 是适用于 Java 的快速压缩器/解压缩器。由于未检查乘法，1.1.10.1 之前版本中可能会发生整数溢出，从而导致无法修复的致命错误。“Snappy.java”文件中的“compress(char[] input)”函数会接收一个字符数组并对其进行压缩。其运作方法是将长度乘以 2，然后传递给 rawCompress` 函数。由于未测试长度，因此与 2 相乘可导致整数溢出，值变成负数。然后，rawCompress 函数会使用收到的长度并将其传递给本机编译的 maxCompressedLength 函数，然后使用返回值分配字节数组。由于 maxCompressedLength 函数会将该长度视为无符号整数，因此它不在乎该值是否为负，而是会返回一个有效值，该值会由 Java 引擎转换为有符号的整数。如果结果为负，则在尝试分配数组“buf”时会引发“java.lang.NegativeArraySizeException”异常。
    另一方面，如果结果为正，“buf”数组会成功分配，但其大小可能会太小而无法用于压缩，从而造成致命的访问冲突错误。当使用接收双精度型、浮点型、长整型和短整型数据的 `compress` 函数时，也存在相同的问题，各函数使用不同乘数可能会导致相同的问题。如果使用字节数组，很可能不会发生此问题，因为从根本上就不可能创建大小为 0x80000000（或任何其他负值）的字节数组。1.1.10.1 版本包含针对此问题的补丁。(CVE-2023-34454)

  - snappy-java 是适用于 Java 的快速压缩器/解压缩器。由于使用未检查的区块长度，1.1.10.1 之前版本中可能会发生不可恢复的致命错误。fileSnappyInputStream.java 中的 hasNextChunk 函数代码会检查给定的流是否要读取更多区块。为此，它会尝试读取 4 个字节。若无法读取这 4 个字节，则函数返回 false。
    在其他情况下，如果有 4 个字节可用，代码会将其视为下一个区块的长度。如果“compressed”变量为 null，则系统会用输入数据指定的大小分配一个字节数组。
    由于代码未测试“chunkSize”变量的合法性，因此它可以传递负数（如 0xFFFFFFFF 为 -1），这将导致代码引发“java.lang.NegativeArraySizeException”异常。如果传递的正值过大（例如 0x7FFFFFFF），情况会更糟糕，可以引发致命的“java.lang.OutOfMemoryError”错误。1.1.10.1 版本包含针对此问题的补丁。(CVE-2023-34455)

  - 对不受信任或损坏的数据进行反序列化时，读取器可能会消耗超出允许限制的内存，从而导致系统内存不足。此问题影响使用 Apache Avro Java SDK 的 Java 应用程序（版本不高于 1.11.2）。用户应更新到 apache-avro 版本 1.11.3 来解决此问题。(CVE-2023-39410)

  - Apache Calcite Avatica JDBC 驱动程序基于通过“httpclient_impl”连接属性提供的类名称创建 HTTP 客户端实例；但是，驱动程序在实例化该类之前未验证是否实现预期接口，这样可导致通过任意类加载的代码执行，并在极少数情况下导致远程代码执行。若要利用此漏洞：1) 攻击者需要具有控制 JDBC 连接参数的权限；2) 并且类路径中应该有易受攻击的类（具有 URL 参数和可执行代码能力的构造函数）。从 Apache Calcite Avatica 1.22.0 开始，程序将在类调用构造函数之前验证其是否实现了预期接口。(CVE-2022-36364)

  - Guava 的所有版本中都存在一个临时目录创建漏洞，对计算机具有访问权限的攻击者可借此访问由 Guava API com.google.common.io.Files.createTempDir() 创建的临时目录中的数据。默认情况下，在类 unix 系统上创建的目录为全局可读（可由具有系统访问权限的攻击者读取）。有问题的方法在版本 30.0 及更高版本中已被标记为 @Deprecated，不应使用。对于 Android 开发人员，我们建议选择由 Android 提供的临时目录 API，例如 context.getCacheDir()。对于其他 Java 开发人员，建议迁移至 Java 7 API java.nio.file.Files.createTempDirectory()，该方法明确配置了权限为 700，或者配置 Java 运行时的 java.io.tmpdir 系统属性，以指向权限适当配置的位置。(CVE-2020-8908)

  - 使用 Java 的默认临时目录在 Unix 系统和 Android Ice Cream Sandwich 上的 Google Guava 版本 1.0 至 31.1 中的“FileBackedOutputStream”中创建文件，允许计算机上有权访问默认 Java 临时目录的其他用户和应用程序能够访问由类创建的文件。即使版本 32.0.0 中修复了安全漏洞，我们仍建议使用版本 32.0.1 ，因为版本 32.0.0 会破坏 Windows 下的某些功能。(CVE-2023-2976)

  - Google Guava 11.0 至 24.1.1 之前的 24.x 版中存在无限内存分配漏洞，远程攻击者可借此对依赖此库的服务器进行拒绝服务攻击，并反序列化攻击者提供的数据，造成此漏洞的原因是 AtomicDoubleArray 类（使用 Java 序列化进行序列化时）和 CompoundOrdering 类（使用 GWT 序列化时）在未适当检查客户端已发送内容以及数据大小是否合理的情况下执行预先分配。(CVE-2018-10237)

  - aiohttp 是用于 asyncio 和 Python 的异步 HTTP 客户端/服务器框架。aiohttp v3.8.4 及更早版本随附 llhttp v6.0.6 一起提供。aiohttp 会将有漏洞的代码（如果可用）用于其 HTTP 请求解析器，这是从 wheel 安装时的默认情况。此漏洞仅影响将 aiohttp 用作 HTTP 服务器（即“aiohttp.Application”）的用户，如果将 aiohttp 用作 HTTP 客户端库（即“aiohttp.ClientSession”），则不会受到此漏洞的影响。发送构建的 HTTP 请求会造成服务器错误解释其中一个 HTTP 标头值，进而导致 HTTP 请求走私问题。
    此问题已在 3.8.5 版中解决。建议所有用户都进行升级。无法升级的用户可重新安装 aiohttp，并使用 `AIOHTTP_NO_EXTENSIONS=1` 作为环境变量，以禁用 llhttp HTTP 请求解析器实现。纯 Python 实现不容易受影响。(CVE-2023-37276)

  - aiohttp 是用于 asyncio 和 Python 的异步 HTTP 客户端/服务器框架。AIOHTTP 中的 HTTP 解析器存在大量标头解析问题，这些问题可导致请求走私。仅在启用 AIOHTTP_NO_EXTENSIONS（或不使用预构建的 wheel）的情况下才使用此解析器。这些错误已在提交“d5c12ba89”中得到解决，该提交包含在 3.8.6 发行版本中。建议所有用户都进行升级。目前尚无针对这些问题的解决方案。(CVE-2023-47627)

  - urllib3 是一个用户友好型的 Python HTTP 客户端库。urllib3 不会特殊对待“Cookie”HTTP 标头，也不会提供任何通过 HTTP 管理 cookie 的帮助程序，这是用户的责任。
    但是，如果用户没有明确禁用重定向，则该用户可能会指定“Cookie”标头，并在不知不觉中通过 HTTP 重定向将信息泄漏到不同的源。此问题已在 urllib3 版本 1.26.17 或 2.0.5 中修复。(CVE-2023-43804)

  - urllib3 是一个用户友好型 Python HTTP 客户端库。先前，当请求方法从可以接受请求正文（如 `POST`）更改为 HTTP RFC 要求的 `GET` 后，urllib3 便不会在 HTTP 重定向响应使用状态 301、302 或 303 时删除 HTTP 请求正文。
    尽管重定向部分中没有指定此行为，但可以将不同部分的信息拼凑在一起来推断，而且我们已经在其他主要 HTTP 客户端实现（如 curl 和 Web 浏览器）中观察到该行为。由于该漏洞需在先前受信任的服务遭到损坏后才能对机密性产生影响，因此我们认为该漏洞的可利用性较低。此外，多数用户也不会将敏感数据放入 HTTP 请求正文中，如果是这种情况，则该漏洞无法利用。必须满足以下两个条件才会受到此漏洞的影响：1. 使用 urllib3 并在 HTTP 请求正文中提交敏感信息（例如表单数据或 JSON），而且 2. 源服务会遭到损坏，并会开始使用 301、302 或 303 重定向到恶意对等机，或是出现重定向到的服务遭到损坏的情况。
    此问题已在 1.26.18 和 2.0.7 版本中解决，建议用户通过更新来解决此问题。无法更新的用户应禁用服务重定向（不希望通过 `redirects=False` 重定向进行响应），并使用 `redirects=False` 禁用自动重定向，亦可通过剥离 HTTP 请求正文来手动处理 301、302 和 303 重定向。(CVE-2023-45803)

  - Certifi 包含一系列精心制作的根证书，用于在验证 TLS 主机身份的同时验证 SSL 证书的可信度。版本 2023.07.22 之前的 Certifi 可识别 e-Tugra 根证书。 e-Tugra 的根证书因系统安全问题报告而接受调查。Certifi 2023.07.22 将 e-Tugra 根证书从根存储区中删除 。(CVE-2023-37920)

  - 利用版本低于 v23.3 的 pip 从 Mercurial VCS URL（如 pip install hg+...）安装程序包时，指定的 Mercurial 版本可用于向 hg 克隆调用（如 --config）注入任意配置选项。控制 Mercurial 配置可以修改存储库的安装方式和安装位置。此漏洞不会影响未使用 Mercurial 安装的用户。(CVE-2023-5752)

  - 低于 65.5.1 的 Python Packaging Authority (PyPA) setuptools 允许远程攻击者通过构建的程序包或自定义 PackageIndex 页面中的 HTML 造成拒绝服务。package_index.py 中存在正则表达式拒绝服务 (ReDoS)。 (CVE-2022-40897)

  - 在 pygments 2.15.0 及其之前所有版本的 pygments/lexers/smithy.py 中发现 ReDoS 问题，通过 SmithyLexer 可以触发该问题。
    (CVE-2022-40896)

  - 在 Python Packaging Authority (PyPA) Wheel 0.37.1 及更早版本中发现的问题允许远程攻击者通过对 wheel cli 进行控制的输入造成拒绝服务。(CVE-2022-40898)

  - Requests 是一个 HTTP 库。自 Requests 2.3.0 起，当重定向到 HTTPS 端点时，Requests 会一直向目标服务器泄露 Proxy-Authorization 标头。这是我们使用 `rebuild_proxies` 向请求重新附加 `Proxy-Authorization` 标头的结果。对于通过隧道发送的 HTTP 连接，代理将识别请求本身的标头并将其删除，然后再转发到目标服务器。但是，当通过 HTTPS 发送时，由于代理无法查看隧道请求，因而必须在 CONNECT 请求中发送 `Proxy-Authorization` 标头。这会导致 Requests 意外将代理凭据转发到目标服务器，从而允许恶意攻击者泄露敏感信息。已在版本 2.31.0 中修补此问题。
    (CVE-2023-32681)

  - 在 Python Charmers Future 0.18.2 及更早版本中发现一个问题，远程攻击者可通过来自恶意 Web 服务器的构建的 Set-Cookie 标头造成拒绝服务。(CVE-2022-40899)

  - python-idna：潜在的 DoS 问题，通过 idna.encode() 的特制输入造成资源消耗，进而触发该问题 (CVE-2024-3651)

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

远程 Redhat Enterprise Linux 8 主机上安装的一个程序包受到 RHSA-2024: 0116 公告提及的多个漏洞影响。

  - urllib3 是一个用户友好型的 Python HTTP 客户端库。urllib3 不会特殊对待“Cookie” HTTP 标头，也不会提供任何通过 HTTP 管理 cookie 的帮助程序，这是用户的责任。
    但是，如果用户没有明确禁用重定向，则该用户可能会指定“Cookie”标头，并在不知不觉中通过 HTTP 重定向将信息泄漏到不同的源。此问题已在 urllib3 版本 1.26.17 或 2.0.5 中修复。(CVE-2023-43804)

  - urllib3 是一个用户友好型 Python HTTP 客户端库。先前，当请求方法从可以接受请求正文（如 `POST`）更改为 HTTP RFC 要求的 `GET` 后，urllib3 便不会在 HTTP 重定向响应使用状态 301、302 或 303 时删除 HTTP 请求正文。
    尽管重定向部分中没有指定此行为，但可以将不同部分的信息拼凑在一起来推断，而且我们已经在其他主要 HTTP 客户端实现（如 curl 和 Web 浏览器）中观察到该行为。由于该漏洞需在先前受信任的服务遭到损坏后才能对机密性产生影响，因此我们认为该漏洞的可利用性较低。此外，多数用户也不会将敏感数据放入 HTTP 请求正文中，如果是这种情况，则该漏洞无法利用。必须满足以下两个条件才会受到此漏洞的影响：1. 使用 urllib3 并在 HTTP 请求正文中提交敏感信息（例如表单数据或 JSON），而且 2. 源服务会遭到损坏，并会开始使用 301、302 或 303 重定向到恶意对等机，或是出现重定向到的服务遭到损坏的情况。
    此问题已在 1.26.18 和 2.0.7 版本中解决，建议用户通过更新来解决此问题。无法更新的用户应禁用服务重定向（不希望通过 `redirects=False` 重定向进行响应），并使用 `redirects=False` 禁用自动重定向，亦可通过剥离 HTTP 请求正文来手动处理 301、302 和 303 重定向。(CVE-2023-45803)

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

远程 Oracle Linux 8 主机上安装的一个程序包受到 ELSA-2024-0116 公告中提及的多个漏洞影响。

  - urllib3 是一个用户友好型的 Python HTTP 客户端库。urllib3 不会特殊对待 `Cookie` HTTP 标头，也不会提供任何通过 HTTP 管理 cookie 的帮助程序，这是用户的责任。
    但是，如果用户没有明确禁用重定向，则该用户可能会指定“Cookie”标头，并在不知不觉中通过 HTTP 重定向将信息泄漏到不同的源。此问题已在 urllib3 版本 1.26.17 或 2.0.5 中修复。(CVE-2023-43804)

  - urllib3 是一个用户友好型 Python HTTP 客户端库。先前，当请求方法从可以接受请求正文（如 `POST`）更改为 HTTP RFC 要求的 `GET` 后，urllib3 便不会在 HTTP 重定向响应使用状态 301、302 或 303 时删除 HTTP 请求正文。
    尽管重定向部分中没有指定此行为，但可以将不同部分的信息拼凑在一起来推断，而且我们已经在其他主要 HTTP 客户端实现（如 curl 和 Web 浏览器）中观察到该行为。由于该漏洞需在先前受信任的服务遭到损坏后才能对机密性产生影响，因此我们认为该漏洞的可利用性较低。此外，多数用户也不会将敏感数据放入 HTTP 请求正文中，如果是这种情况，则该漏洞无法利用。必须满足以下两个条件才会受到此漏洞的影响：1. 使用 urllib3 并在 HTTP 请求正文中提交敏感信息（例如表单数据或 JSON），而且 2. 源服务会遭到损坏，并会开始使用 301、302 或 303 重定向到恶意对等机，或是出现重定向到的服务遭到损坏的情况。
    此问题已在 1.26.18 和 2.0.7 版本中解决，建议用户通过更新来解决此问题。无法更新的用户应禁用服务重定向（不希望通过 `redirects=False` 重定向进行响应），并使用 `redirects=False` 禁用自动重定向，亦可通过剥离 HTTP 请求正文来手动处理 301、302 和 303 重定向。(CVE-2023-45803)

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

远程 Redhat Enterprise Linux 9 主机上安装的一个程序包受到 RHSA-2024: 0464 公告中提及的一个漏洞的影响。

  - urllib3 是一个用户友好型的 Python HTTP 客户端库。urllib3 不会特殊对待“Cookie”HTTP 标头，也不会提供任何通过 HTTP 管理 cookie 的帮助程序，这是用户的责任。
    但是，如果用户没有明确禁用重定向，则该用户可能会指定“Cookie”标头，并在不知不觉中通过 HTTP 重定向将信息泄漏到不同的源。此问题已在 urllib3 版本 1.26.17 或 2.0.5 中修复。(CVE-2023-43804)

  - urllib3 是一个用户友好型 Python HTTP 客户端库。先前，当请求方法从可以接受请求正文（如 `POST`）更改为 HTTP RFC 要求的 `GET` 后，urllib3 便不会在 HTTP 重定向响应使用状态 301、302 或 303 时删除 HTTP 请求正文。
    尽管重定向部分中没有指定此行为，但可以将不同部分的信息拼凑在一起来推断，而且我们已经在其他主要 HTTP 客户端实现（如 curl 和 Web 浏览器）中观察到该行为。由于该漏洞需在先前受信任的服务遭到损坏后才能对机密性产生影响，因此我们认为该漏洞的可利用性较低。此外，多数用户也不会将敏感数据放入 HTTP 请求正文中，如果是这种情况，则该漏洞无法利用。必须满足以下两个条件才会受到此漏洞的影响：1. 使用 urllib3 并在 HTTP 请求正文中提交敏感信息（例如表单数据或 JSON），而且 2. 源服务会遭到损坏，并会开始使用 301、302 或 303 重定向到恶意对等机，或是出现重定向到的服务遭到损坏的情况。
    此问题已在 1.26.18 和 2.0.7 版本中解决，建议用户通过更新来解决此问题。无法更新的用户应禁用服务重定向（不希望通过 `redirects=False` 重定向进行响应），并使用 `redirects=False` 禁用自动重定向，亦可通过剥离 HTTP 请求正文来手动处理 301、302 和 303 重定向。(CVE-2023-45803)

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

远程 Redhat Enterprise Linux 8 主机上安装的一个程序包受到 RHSA-2024: 0588 公告中提及的漏洞的影响。

  - urllib3 是一个用户友好型的 Python HTTP 客户端库。urllib3 不会特殊对待“Cookie”HTTP 标头，也不会提供任何通过 HTTP 管理 cookie 的帮助程序，这是用户的责任。
    但是，如果用户没有明确禁用重定向，则该用户可能会指定“Cookie”标头，并在不知不觉中通过 HTTP 重定向将信息泄漏到不同的源。此问题已在 urllib3 版本 1.26.17 或 2.0.5 中修复。(CVE-2023-43804)

  - urllib3 是一个用户友好型 Python HTTP 客户端库。先前，当请求方法从可以接受请求正文（如 `POST`）更改为 HTTP RFC 要求的 `GET` 后，urllib3 便不会在 HTTP 重定向响应使用状态 301、302 或 303 时删除 HTTP 请求正文。
    尽管重定向部分中没有指定此行为，但可以将不同部分的信息拼凑在一起来推断，而且我们已经在其他主要 HTTP 客户端实现（如 curl 和 Web 浏览器）中观察到该行为。由于该漏洞需在先前受信任的服务遭到损坏后才能对机密性产生影响，因此我们认为该漏洞的可利用性较低。此外，多数用户也不会将敏感数据放入 HTTP 请求正文中，如果是这种情况，则该漏洞无法利用。必须满足以下两个条件才会受到此漏洞的影响：1. 使用 urllib3 并在 HTTP 请求正文中提交敏感信息（例如表单数据或 JSON），而且 2. 源服务会遭到损坏，并会开始使用 301、302 或 303 重定向到恶意对等机，或是出现重定向到的服务遭到损坏的情况。
    此问题已在 1.26.18 和 2.0.7 版本中解决，建议用户通过更新来解决此问题。无法更新的用户应禁用服务重定向（不希望通过 `redirects=False` 重定向进行响应），并使用 `redirects=False` 禁用自动重定向，亦可通过剥离 HTTP 请求正文来手动处理 301、302 和 303 重定向。(CVE-2023-45803)

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

远程 Redhat Enterprise Linux 8 主机上安装的多个程序包受到 RHSA-2023:7851 公告中提及的多个漏洞影响。

  - foreman：包含机密内容的全局可读文件 (CVE-2023-4886)

  - actionpack：可能通过用户向 redirect_to 提供值来发动 XSS (CVE-2023-28362)

  - GitPython：盲目包含本地文件 (CVE-2023-41040)

  - python-urllib3：跨源重定向期间未剥离 Cookie 请求标头 (CVE-2023-43804)

  - urllib3：从 303 状态变更请求方法重定向为 GET 后，未剥离请求正文 (CVE-2023-45803)

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

远程 Redhat Enterprise Linux 8/9 主机上安装的多个程序包受到 RHSA-2023:6158 公告中提及的多个漏洞影响。

    Red Hat Ansible Automation Platform 为大规模构建、部署和管理 IT 自动化提供了一个企业框架。IT 管理人员可以为如何将自动化应用于各个团队提供全面的指导原则，而自动化开发人员仍然可以自由地利用现有知识编写任务，而不会导致开销增加。Ansible Automation Platform 让整个组织的用户都能够通过简单、强大的无代理语言，共享、审查和管理自动化内容。

    安全修复：

    * automation-controller：Django：django.utils.text.Truncator 中可能存在拒绝服务漏洞 (CVE-2023-43665)

    * python3-urllib3/python39-urllib3：跨源重定向期间未剥离 Cookie 请求标头 (CVE-2023-43804)

    有关上述安全问题的更多详细信息，包括其影响、CVSS 得分、致谢，以及其他相关信息，请参阅列于“参考”部分的 CVE 页面。

    针对自动化控制器的更新和修复：
    * automation-controller 已更新到 4.4.7
    * 清理了 SOS 报告密码 (AAP-17544)
    * 使用 infra.controller_configuration 集合（该集合使用 ansible.controller 集合）更新其 Ansible Automation Platform 环境的客户不再会收到 HTTP 499 响应 (AAP-17422)

    更多变更：
    * python3-urllib3/python39-urllib3 已更新到 1.26.18

Tenable 已直接从 Red Hat Enterprise Linux 安全公告中提取上述描述块。

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

远程 Redhat Enterprise Linux 9 主机上安装的程序包受到 RHSA-2024:2159 公告中提及的一个漏洞影响。

  - python-urllib3：跨源重定向期间未剥离 Cookie 请求标头 (CVE-2023-43804)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
201209	Splunk Enterprise 9.0.0 < 9.0.9、9.1.0 < 9.1.4、9.2.0 < 9.2.1 (SVD-2024-0718)	Nessus	CGI abuses	2024/7/1	2024/7/2	critical
187881	RHEL 8：python-urllib3 (RHSA-2024: 0116)	Nessus	Red Hat Local Security Checks	2024/1/10	2025/3/6	critical
187930	Oracle Linux 8：python-urllib3 (ELSA-2024-0116)	Nessus	Oracle Linux Local Security Checks	2024/1/10	2024/11/2	critical
189561	RHEL 9：python-urllib3 (RHSA-2024: 0464)	Nessus	Red Hat Local Security Checks	2024/1/25	2025/3/6	critical
189814	RHEL 8：python-urllib3 (RHSA-2024: 0588)	Nessus	Red Hat Local Security Checks	2024/1/30	2024/11/7	critical
194386	RHEL 8：Satellite 6.14.1 异步安全更新（重要）(RHSA-2023:7851)	Nessus	Red Hat Local Security Checks	2024/4/28	2024/11/7	critical
194399	RHEL 8/9：Red Hat Ansible Automation Platform 2.4 产品安全和缺陷修复更新（中危）(RHSA-2023:6158)	Nessus	Red Hat Local Security Checks	2024/4/28	2024/11/7	critical
194774	RHEL 9：python3.11-urllib3 (RHSA-2024:2159)	Nessus	Red Hat Local Security Checks	2024/4/30	2024/11/7	critical

检测

插件搜索

critical

critical

critical

critical

critical

critical

critical

critical