{
  "@id": "urn:uuid:a4dd4b29-6bbe-4e36-90af-7043ba6885ab",
  "role": "Document Creator",
  "author": "https://tuxcare.com",
  "version": 2,
  "@context": "https://openvex.dev/ns/v0.2.0",
  "timestamp": "2026-11-04T07:37:20.608547+00:00",
  "statements": [
    {
      "status": "not_affected",
      "products": [
        {
          "@id": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4",
          "identifiers": {
            "purl": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4"
          }
        }
      ],
      "timestamp": "2026-11-04T07:37:08.625732+00:00",
      "status_notes": "Vulnerability CVE-2014-3488 does not affect version 4.1.42.Final-tuxcare.4 of io.netty:netty-handler. not_affected \u2014 Target Netty 4.1.42.Final is NOT affected by CVE-2014-3488. The vulnerability affected Netty 3.x before 3.9.2, where SSLv2Hello messages caused infinite loops due to repeated BUFFER_OVERFLOW retries with undersized buffers. Netty 4.x has built-in runtime protection: consecutive overflow detection (lines 1363-1368 of SslHandler.java) that throws IllegalStateException after two overflows with zer...",
      "vulnerability": {
        "name": "CVE-2014-3488"
      },
      "impact_statement": "not_affected \u2014 Target Netty 4.1.42.Final is NOT affected by CVE-2014-3488. The vulnerability affected Netty 3.x before 3.9.2, where SSLv2Hello messages caused infinite loops due to repeated BUFFER_OVERFLOW retries with undersized buffers. Netty 4.x has built-in runtime protection: consecutive overflow detection (lines 1363-1368 of SslHandler.java) that throws IllegalStateException after two overflows with zer..."
    },
    {
      "status": "not_affected",
      "products": [
        {
          "@id": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4",
          "identifiers": {
            "purl": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4"
          }
        }
      ],
      "timestamp": "2026-11-04T07:37:08.625732+00:00",
      "status_notes": "Vulnerability CVE-2016-4970 does not affect version 4.1.42.Final-tuxcare.4 of io.netty:netty-handler. The target Netty 4.1.42.Final is not affected by CVE-2016-4970. The vulnerability (infinite loop in OpenSslEngine when SSL_write returns SSL_ERROR_WANT_READ with empty BIO buffer) was fixed in upstream Netty 4.1.1.Final by Scott Mitchell (Apple) in commit 9e2c400f89. The fix was already present in the upstream 4.1.42.Final release that TuxCare onboarded. The current code correctly returns to the event loop with NEED_UNWRAP status instead of looping indefinitely, preventing the denial of service condition.\n\nAdvisory cross-check (dlmn): outside the affected ranges of GitHub (>= 4.0.0.Alpha1, < 4.0.37.Final; >= 4.1.0.Beta1, < 4.1.1.Final), NVD (>= 4.0.20, < 4.0.37; >= 4.1.0, < 4.1.1), Snyk (>= 4.0.0.Alpha1, < 4.0.37.Final; >= 4.1.0.Beta1, < 4.1.1.Final).",
      "justification": "vulnerable_code_not_present",
      "vulnerability": {
        "name": "CVE-2016-4970"
      },
      "impact_statement": "The target Netty 4.1.42.Final is not affected by CVE-2016-4970. The vulnerability (infinite loop in OpenSslEngine when SSL_write returns SSL_ERROR_WANT_READ with empty BIO buffer) was fixed in upstream Netty 4.1.1.Final by Scott Mitchell (Apple) in commit 9e2c400f89. The fix was already present in the upstream 4.1.42.Final release that TuxCare onboarded. The current code correctly returns to the event loop with NEED_UNWRAP status instead of looping indefinitely, preventing the denial of service condition.\n\nAdvisory cross-check (dlmn): outside the affected ranges of GitHub (>= 4.0.0.Alpha1, < 4.0.37.Final; >= 4.1.0.Beta1, < 4.1.1.Final), NVD (>= 4.0.20, < 4.0.37; >= 4.1.0, < 4.1.1), Snyk (>= 4.0.0.Alpha1, < 4.0.37.Final; >= 4.1.0.Beta1, < 4.1.1.Final)."
    },
    {
      "status": "affected",
      "products": [
        {
          "@id": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4",
          "identifiers": {
            "purl": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4"
          }
        }
      ],
      "timestamp": "2026-11-04T07:37:08.625732+00:00",
      "status_notes": "Vulnerability CVE-2019-20445 affects version 4.1.42.Final-tuxcare.4 of io.netty:netty-handler.",
      "vulnerability": {
        "name": "CVE-2019-20445"
      },
      "action_statement": "Vulnerability CVE-2019-20445 affects version 4.1.42.Final-tuxcare.4 of io.netty:netty-handler."
    },
    {
      "status": "affected",
      "products": [
        {
          "@id": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4",
          "identifiers": {
            "purl": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4"
          }
        }
      ],
      "timestamp": "2026-11-04T07:37:08.625732+00:00",
      "status_notes": "Vulnerability CVE-2020-11612 affects version 4.1.42.Final-tuxcare.4 of io.netty:netty-handler.",
      "vulnerability": {
        "name": "CVE-2020-11612"
      },
      "action_statement": "Vulnerability CVE-2020-11612 affects version 4.1.42.Final-tuxcare.4 of io.netty:netty-handler."
    },
    {
      "status": "affected",
      "products": [
        {
          "@id": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4",
          "identifiers": {
            "purl": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4"
          }
        }
      ],
      "timestamp": "2026-11-04T07:37:08.625732+00:00",
      "status_notes": "Vulnerability CVE-2020-7238 affects version 4.1.42.Final-tuxcare.4 of io.netty:netty-handler.",
      "vulnerability": {
        "name": "CVE-2020-7238"
      },
      "action_statement": "Vulnerability CVE-2020-7238 affects version 4.1.42.Final-tuxcare.4 of io.netty:netty-handler."
    },
    {
      "status": "not_affected",
      "products": [
        {
          "@id": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4",
          "identifiers": {
            "purl": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4"
          }
        }
      ],
      "timestamp": "2026-11-04T07:37:08.625732+00:00",
      "status_notes": "Vulnerability CVE-2023-34462 does not affect version 4.1.42.Final-tuxcare.4 of io.netty:netty-handler. not_affected \u2014 Version 4.1.42.Final is not affected by CVE-2023-34462. The vulnerable code (fragmented ClientHello handling with unvalidated handshakeLength-based buffer allocation) was introduced in commit 29c471ec52 on 2019-11-29, approximately two months AFTER the 4.1.42.Final release (2019-09-25). The target version only supports ClientHello messages within a single TLS record and parses them directly fro...",
      "justification": "vulnerable_code_not_present",
      "vulnerability": {
        "name": "CVE-2023-34462"
      },
      "impact_statement": "not_affected \u2014 Version 4.1.42.Final is not affected by CVE-2023-34462. The vulnerable code (fragmented ClientHello handling with unvalidated handshakeLength-based buffer allocation) was introduced in commit 29c471ec52 on 2019-11-29, approximately two months AFTER the 4.1.42.Final release (2019-09-25). The target version only supports ClientHello messages within a single TLS record and parses them directly fro..."
    },
    {
      "status": "not_affected",
      "products": [
        {
          "@id": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4",
          "identifiers": {
            "purl": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4"
          }
        }
      ],
      "timestamp": "2026-11-04T07:37:08.625732+00:00",
      "status_notes": "Vulnerability CVE-2023-4586 is a false positive for io.netty:netty-handler 4.1.42.Final-tuxcare.4.",
      "vulnerability": {
        "name": "CVE-2023-4586"
      },
      "impact_statement": "The vulnerability has been withdrawn."
    },
    {
      "status": "fixed",
      "products": [
        {
          "@id": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4",
          "identifiers": {
            "purl": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4"
          }
        }
      ],
      "timestamp": "2026-11-04T07:37:08.625732+00:00",
      "status_notes": "Vulnerability CVE-2025-24970 is fixed in version 4.1.42.Final-tuxcare.4 of io.netty:netty-handler.",
      "vulnerability": {
        "name": "CVE-2025-24970"
      }
    },
    {
      "status": "fixed",
      "products": [
        {
          "@id": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4",
          "identifiers": {
            "purl": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4"
          }
        }
      ],
      "timestamp": "2026-11-04T07:37:08.625732+00:00",
      "status_notes": "Vulnerability CVE-2026-44249 is fixed in version 4.1.42.Final-tuxcare.4 of io.netty:netty-handler.",
      "vulnerability": {
        "name": "CVE-2026-44249"
      }
    },
    {
      "status": "not_affected",
      "products": [
        {
          "@id": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4",
          "identifiers": {
            "purl": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4"
          }
        }
      ],
      "timestamp": "2026-11-04T07:37:08.625732+00:00",
      "status_notes": "Vulnerability CVE-2026-45416 does not affect version 4.1.42.Final-tuxcare.4 of io.netty:netty-handler. Target version 4.1.42.Final (released Sept 2019) is NOT AFFECTED by CVE-2026-45416. The vulnerability requires SslClientHelloHandler.decode() which performs eager allocation based on the 24-bit handshake length field when ClientHello spans multiple TLS records. This class was introduced in February 2020 (commit 8304069a30, PR #9827), approximately 4.5 months AFTER 4.1.42.Final was released. Version 4.1.42.Final uses a completely different architecture where AbstractSniHandler extends ByteToMessageDecoder directly and processes ClientHello in-place from the cumulative input buffer, reading only the 16-bit TLS record length (max ~64KB per record) without any eager allocation based on the 24-bit handshake length. The specific attack chain described in the CVE (reading handshakeLength via getUnsignedMedium, then ctx.alloc().buffer(handshakeLength)) does not exist in this version. Rule 5 Type A2 applies: INPUT is received, but no path from input-receiving code reaches the GOAL (uncontrolled memory allocation based on attacker-supplied handshake length).",
      "justification": "vulnerable_code_not_present",
      "vulnerability": {
        "name": "CVE-2026-45416"
      },
      "impact_statement": "Target version 4.1.42.Final (released Sept 2019) is NOT AFFECTED by CVE-2026-45416. The vulnerability requires SslClientHelloHandler.decode() which performs eager allocation based on the 24-bit handshake length field when ClientHello spans multiple TLS records. This class was introduced in February 2020 (commit 8304069a30, PR #9827), approximately 4.5 months AFTER 4.1.42.Final was released. Version 4.1.42.Final uses a completely different architecture where AbstractSniHandler extends ByteToMessageDecoder directly and processes ClientHello in-place from the cumulative input buffer, reading only the 16-bit TLS record length (max ~64KB per record) without any eager allocation based on the 24-bit handshake length. The specific attack chain described in the CVE (reading handshakeLength via getUnsignedMedium, then ctx.alloc().buffer(handshakeLength)) does not exist in this version. Rule 5 Type A2 applies: INPUT is received, but no path from input-receiving code reaches the GOAL (uncontrolled memory allocation based on attacker-supplied handshake length)."
    },
    {
      "status": "fixed",
      "products": [
        {
          "@id": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4",
          "identifiers": {
            "purl": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4"
          }
        }
      ],
      "timestamp": "2026-11-04T07:37:20.608547+00:00",
      "status_notes": "Vulnerability CVE-2026-50010 is fixed in version 4.1.42.Final-tuxcare.4 of io.netty:netty-handler.",
      "vulnerability": {
        "name": "CVE-2026-50010"
      }
    },
    {
      "status": "affected",
      "products": [
        {
          "@id": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4",
          "identifiers": {
            "purl": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4"
          }
        }
      ],
      "timestamp": "2026-11-04T07:37:08.625732+00:00",
      "status_notes": "Vulnerability CVE-2026-75595 affects version 4.1.42.Final-tuxcare.4 of io.netty:netty-handler.",
      "vulnerability": {
        "name": "CVE-2026-75595"
      },
      "action_statement": "Vulnerability CVE-2026-75595 affects version 4.1.42.Final-tuxcare.4 of io.netty:netty-handler."
    },
    {
      "status": "not_affected",
      "products": [
        {
          "@id": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4",
          "identifiers": {
            "purl": "pkg:maven/io.netty/netty-handler@4.1.42.Final-tuxcare.4"
          }
        }
      ],
      "timestamp": "2026-11-04T07:37:08.625732+00:00",
      "status_notes": "Vulnerability CVE-2026-75596 does not affect version 4.1.42.Final-tuxcare.4 of io.netty:netty-handler. Netty 4.1.42.Final is not affected by CVE-2026-75596. The vulnerable component io.netty.handler.ssl.SslClientHelloHandler does not exist in this version\u2014it was introduced 4 months after the 4.1.42.Final release (Sept 2019) in commit 8304069a30 (Feb 2020). The CVE describes quadratic CPU complexity from repeated buffer clear+re-copy operations when aggregating fragmented TLS ClientHello messages. This specific vulnerability pattern (handshakeBuffer.clear() followed by unconditional writeBytes re-copying all accumulated data) is unique to SslClientHelloHandler and does not exist in the alternative SNI implementation (AbstractSniHandler) present in 4.1.42.Final. AbstractSniHandler uses ByteToMessageDecoder's linear cumulation and parses ClientHello in-place without buffer re-copying, avoiding the quadratic complexity entirely.",
      "justification": "vulnerable_code_not_present",
      "vulnerability": {
        "name": "CVE-2026-75596"
      },
      "impact_statement": "Netty 4.1.42.Final is not affected by CVE-2026-75596. The vulnerable component io.netty.handler.ssl.SslClientHelloHandler does not exist in this version\u2014it was introduced 4 months after the 4.1.42.Final release (Sept 2019) in commit 8304069a30 (Feb 2020). The CVE describes quadratic CPU complexity from repeated buffer clear+re-copy operations when aggregating fragmented TLS ClientHello messages. This specific vulnerability pattern (handshakeBuffer.clear() followed by unconditional writeBytes re-copying all accumulated data) is unique to SslClientHelloHandler and does not exist in the alternative SNI implementation (AbstractSniHandler) present in 4.1.42.Final. AbstractSniHandler uses ByteToMessageDecoder's linear cumulation and parses ClientHello in-place without buffer re-copying, avoiding the quadratic complexity entirely."
    }
  ]
}
