{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.logging.log4j:log4j-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0-beta9"
            },
            {
              "fixed": "2.25.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-68161"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-297"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-19T22:08:02Z",
    "nvd_published_at": "2025-12-18T21:15:57Z",
    "severity": "MODERATE"
  },
  "details": "The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the  [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName)  configuration attribute or the  [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true.\n\nThis issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions:\n\n  *  The attacker is able to intercept or redirect network traffic between the client and the log receiver.\n  *  The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender\u2019s configured trust store (or by the default Java trust store if no custom trust store is configured).\n\n\nUsers are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue.\n\nAs an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates.",
  "id": "GHSA-vc5p-v9hr-52mj",
  "modified": "2025-12-19T22:08:02Z",
  "published": "2025-12-18T21:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68161"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/logging-log4j2/pull/4002"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/logging-log4j2/commit/3b93748497e1adbbd027fda8a5e7268ec5d0d578"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/logging-log4j2"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/xr33kyxq3sl67lwb61ggvm1fzc8k7dvx"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/cyclonedx/vdr.xml"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/security.html#CVE-2025-68161"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/12/18/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Log4j does not verify the TLS hostname in its Socket Appender"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.logging.log4j:log4j-layout-template-json"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.14.0"
            },
            {
              "fixed": "2.25.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.logging.log4j:log4j-layout-template-json"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0-alpha1"
            },
            {
              "last_affected": "3.0.0-beta3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34481"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T21:16:54Z",
    "nvd_published_at": "2026-04-10T16:16:31Z",
    "severity": "MODERATE"
  },
  "details": "Apache Log4j\u0027s [`JsonTemplateLayout`](https://logging.apache.org/log4j/2.x/manual/json-template-layout.html), in versions up to and including 2.25.3, produces invalid JSON output when log events contain non-finite floating-point values (`NaN`, `Infinity`, or `-Infinity`), which are prohibited by RFC 8259. This may cause downstream log processing systems to reject or fail to index affected records.\n\nAn attacker can exploit this issue only if both of the following conditions are met:\n\n  *  The application uses `JsonTemplateLayout`.\n  *  The application logs a `MapMessage` containing an attacker-controlled floating-point value.\n\nUsers are advised to upgrade to Apache Log4j JSON Template Layout 2.25.4, which corrects this issue.",
  "id": "GHSA-w35j-pv5h-q9q9",
  "modified": "2026-04-13T23:59:41Z",
  "published": "2026-04-10T18:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34481"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/logging-log4j2/pull/4080"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/logging-log4j2"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/n34zdv00gbkdbzt2rx9rf5mqz6lhopcv"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/cyclonedx/vdr.xml"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/log4j/2.x/manual/json-template-layout.html"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/security.html#CVE-2026-34481"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/04/10/10"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Log4j JSON Template Layout: Improper serialization of non-finite floating-point values in JsonTemplateLayout"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.14.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-transport-native-epoll"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Final"
            },
            {
              "fixed": "4.2.15.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.14.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-transport-native-kqueue"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Final"
            },
            {
              "fixed": "4.2.15.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.134.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-transport-native-kqueue"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.135.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.134.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-transport-native-epoll"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.135.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45536"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-772"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-08T23:01:33Z",
    "nvd_published_at": "2026-06-12T15:16:27Z",
    "severity": "MODERATE"
  },
  "details": "netty_unix_socket_recvFd sets msg_control to `char control[CMSG_SPACE(sizeof(int))]` (line 940) \u2014 24 bytes on 64-bit Linux. A peer-sent SCM_RIGHTS cmsg carrying two ints has cmsg_len = CMSG_LEN(8) = 24, which fits exactly with no MSG_CTRUNC, so the kernel installs both fds in the receiving process. The subsequent check `cmsg-\u003ecmsg_len == CMSG_LEN(sizeof(int))` (line 972, expected 20) fails, the branch that would read the fd is skipped, and neither installed fd is closed. The for(;;) loop calls recvmsg again (non-blocking \u2192 EAGAIN \u2192 Java maps to 0 \u2192 read loop exits normally), leaving two leaked fds per message. There is no MSG_CTRUNC handling. Reachable via Epoll/KQueue DomainSocketChannel when the application opts into DomainSocketReadMode.FILE_DESCRIPTORS (non-default).",
  "id": "GHSA-w573-9ffj-6ff9",
  "modified": "2026-06-12T19:29:26Z",
  "published": "2026-06-08T23:01:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-w573-9ffj-6ff9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45536"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty: Unix-socket fd receive leaks descriptors when peer sends two at once"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.14.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-handler"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Final"
            },
            {
              "fixed": "4.2.15.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.134.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-handler"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.135.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45416"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-08T23:01:04Z",
    "nvd_published_at": "2026-06-12T15:16:26Z",
    "severity": "HIGH"
  },
  "details": "SslClientHelloHandler.decode() reads the 24-bit TLS handshake length and, when the ClientHello does not fit in the first record, eagerly allocates `ctx.alloc().buffer(handshakeLength)` (line 161). The guard at line 140 is `handshakeLength \u003e maxClientHelloLength \u0026\u0026 maxClientHelloLength != 0`, and the commonly-used SniHandler/AbstractSniHandler constructors (SniHandler(Mapping), SniHandler(AsyncMapping), AbstractSniHandler()) pass maxClientHelloLength=0 and handshakeTimeoutMillis=0, so the length guard is disabled and no timeout is scheduled. A 16 MiB request exceeds the default pooled chunk size and becomes a huge/unpooled allocation performed immediately. The buffer is retained in the handler until the channel closes.",
  "id": "GHSA-x4gw-5cx5-pgmh",
  "modified": "2026-06-12T19:29:22Z",
  "published": "2026-06-08T23:01:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-x4gw-5cx5-pgmh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45416"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty: SNI handler pre-allocates up to 16 MiB from nine attacker bytes"
}