ghsa-pgw7-wx7w-2w33
Vulnerability from github
Published
2022-06-17 01:02
Modified
2022-07-29 18:13
Summary
ProxyAgent vulnerable to MITM
Details

Description

Undici.ProxyAgent never verifies the remote server's certificate, and always exposes all request & response data to the proxy. This unexpectedly means that proxies can MitM all HTTPS traffic, and if the proxy's URL is HTTP then it also means that nominally HTTPS requests are actually sent via plain-text HTTP between Undici and the proxy server.

Impact

This affects all use of HTTPS via HTTP proxy using Undici.ProxyAgent with Undici or Node's global fetch. In this case, it removes all HTTPS security from all requests sent using Undici's ProxyAgent, allowing trivial MitM attacks by anybody on the network path between the client and the target server (local network users, your ISP, the proxy, the target server's ISP, etc). This less seriously affects HTTPS via HTTPS proxies. When you send HTTPS via a proxy to a remote server, the proxy can freely view or modify all HTTPS traffic unexpectedly (but only the proxy).

Patches

This issue was patched in Undici v5.5.1.

Workarounds

At the time of writing, the only workaround is to not use ProxyAgent as a dispatcher for TLS Connections.

Show details on source website


{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.5.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "undici"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.8.2"
            },
            {
              "fixed": "5.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-32210"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-17T01:02:29Z",
    "nvd_published_at": "2022-07-14T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Description\n\n`Undici.ProxyAgent` never verifies the remote server\u0027s certificate, and always exposes all request \u0026 response data to the proxy. This unexpectedly means that proxies can MitM all HTTPS traffic, and if the proxy\u0027s URL is HTTP then it also means that nominally HTTPS requests are actually sent via plain-text HTTP between Undici and the proxy server.\n\n### Impact\n\nThis affects all use of HTTPS via HTTP proxy using **`Undici.ProxyAgent`**  with Undici or Node\u0027s global `fetch`. In this case, it removes all HTTPS security from all requests sent using Undici\u0027s `ProxyAgent`, allowing trivial MitM attacks by anybody on the network path between the client and the target server (local network users, your ISP, the proxy, the target server\u0027s ISP, etc).\nThis less seriously affects HTTPS via HTTPS proxies. When you send HTTPS via a proxy to a remote server, the proxy can freely view or modify all HTTPS traffic unexpectedly (but only the proxy). \n\n### Patches\n\nThis issue was patched in Undici v5.5.1.\n\n### Workarounds\n\nAt the time of writing, the only workaround is to not use `ProxyAgent` as a dispatcher for TLS Connections.",
  "id": "GHSA-pgw7-wx7w-2w33",
  "modified": "2022-07-29T18:13:25Z",
  "published": "2022-06-17T01:02:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nodejs/undici/security/advisories/GHSA-pgw7-wx7w-2w33"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32210"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1583680"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nodejs/undici"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ProxyAgent vulnerable to MITM"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading...

Loading...

Loading...

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.