CVE-2021-21295
published 2021-03-09CVE-2021-21295: Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers &…
PriorityP347medium5.9CVSS 3.1
AVNACHPRNUINSUCNIHAN
EPSS
18.89%
96.9th percentile
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`.
Affected
45 ranges· showing 25
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| apache | kudu | < 1.16.0 | 1.16.0 |
| apache | zookeeper | — | — |
| debian | debian_linux | — | — |
| debian | netty | < netty 1:4.1.48-3 (bookworm) | netty 1:4.1.48-3 (bookworm) |
| debian | netty | < netty 1:4.1.48-4 (bookworm) | netty 1:4.1.48-4 (bookworm) |
| netty | netty | < 4.1.61.Final | 4.1.61.Final |
| netty | netty | < 4.1.61 | 4.1.61 |
| netty | netty | < 4.1.60 | 4.1.60 |
| netty | netty | >= 0 < 1:4.1.48-3 | 1:4.1.48-3 |
| netty | netty | >= 0 < 1:4.1.48-4 | 1:4.1.48-4 |
| netty | netty | >= 0 < 1:4.1.48-3 | 1:4.1.48-3 |
| netty | netty | >= 0 < 1:4.1.48-4 | 1:4.1.48-4 |
| netty | netty | >= 0 < 1:4.1.48-3 | 1:4.1.48-3 |
| netty | netty | >= 0 < 1:4.1.48-4 | 1:4.1.48-4 |
| netty | netty | >= 0 < 1:4.1.48-3 | 1:4.1.48-3 |
| netty | netty | >= 0 < 1:4.1.48-4 | 1:4.1.48-4 |
| netty | netty | >= 0 < 1:4.1.48-4+deb11u1build0.22.04.1 | 1:4.1.48-4+deb11u1build0.22.04.1 |
| netty | netty | >= 0 < 1:4.0.34-1ubuntu0.1~esm1 | 1:4.0.34-1ubuntu0.1~esm1 |
| netty | netty | >= 0 < 1:4.1.7-4ubuntu0.1+esm2 | 1:4.1.7-4ubuntu0.1+esm2 |
| netty | netty | >= 0 < 1:4.1.45-1ubuntu0.1~esm1 | 1:4.1.45-1ubuntu0.1~esm1 |
| oracle | banking_corporate_lending_process_management | — | — |
| oracle | banking_corporate_lending_process_management | — | — |
| oracle | banking_corporate_lending_process_management | — | — |
| oracle | banking_credit_facilities_process_management | — | — |
| oracle | banking_credit_facilities_process_management | — | — |
CVSS provenance
nvdv3.15.9MEDIUMCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
nvdv2.02.6LOWAV:N/AC:H/Au:N/C:N/I:P/A:N
osv7.5HIGH
vendor_ubuntu7.5HIGH
vendor_debian5.9MEDIUM
vendor_oracle5.9MEDIUM
vendor_redhat5.9MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Ubuntu
Netty vulnerabilities
vendor_ubuntu·2023-04-28·CVSS 7.5
CVE-2021-21295 [HIGH] Netty vulnerabilities
Title: Netty vulnerabilities
Summary: Several security issues were fixed in Netty.
It was discovered that Netty's Zlib decoders did not limit memory
allocations. A remote attacker could possibly use this issue to cause
Netty to exhaust memory via malicious input, leading to a denial of
service. This issue only affected Ubuntu 16.04 ESM and Ubuntu 20.04 ESM.
(CVE-2020-11612)
It was discovered that Netty created temporary files with excessive
permissions. A local attacker could possibly use this issue to expose
sensitive information. This issue only affected Ubuntu 16.04 ESM, Ubuntu
18.04 ESM, and Ubuntu 20.04 ESM. (CVE-2021-21290)
It was discovered that Netty did not properly validate content-length
headers. A remote attacker could possibly use this issue to smuggle
requests. This issue
Oracle
Oracle Oracle Communications Applications Risk Matrix: REST Service Manager (Netty) — CVE-2021-21295
vendor_oracle·2022-10-15·CVSS 5.9
CVE-2021-21295 [MEDIUM] Oracle Oracle Communications Applications Risk Matrix: REST Service Manager (Netty) — CVE-2021-21295
Oracle Oracle Communications Applications Risk Matrix: REST Service Manager (Netty) vulnerability
CVE: CVE-2021-21295
CVSS: 5.9
Protocol: HTTP
Remote exploit: Yes
Affected versions: Network
Advisory: cpuoct2022 (OCT 2022)
Red Hat
netty: Request smuggling via content-length header
vendor_redhat·2021-03-30·CVSS 5.9
CVE-2021-21409 [MEDIUM] CWE-444 netty: Request smuggling via content-length header
netty: Request smuggling via content-length header
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.61.Final there is a vulnerability that enables request smuggling. The content-length header is not correctly validated if the request only uses a single Http2HeaderFrame with the endStream set to to true. This could lead to request smuggling if the request is proxied to a remote peer and translated to HTTP/1.1. This is a followup of GHSA-wm47-8v5p-wjpj/CVE-2021-21295 which did miss to fix this one case. This was fixed as part of 4.1.61.Final.
A flaw was found in Netty. There is an issue where the content-length header is
Red Hat
netty: possible request smuggling in HTTP/2 due missing validation
vendor_redhat·2021-03-09·CVSS 5.9
CVE-2021-21295 [MEDIUM] CWE-444 netty: possible request smuggling in HTTP/2 due missing validation
netty: possible request smuggling in HTTP/2 due missing validation
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and pr
Debian
CVE-2021-21295: netty - Netty is an open-source, asynchronous event-driven network application framework...
vendor_debian·2021·CVSS 5.9
CVE-2021-21295 [MEDIUM] CVE-2021-21295: netty - Netty is an open-source, asynchronous event-driven network application framework...
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request s
Debian
CVE-2021-21409: netty - Netty is an open-source, asynchronous event-driven network application framework...
vendor_debian·2021·CVSS 5.9
CVE-2021-21409 [MEDIUM] CVE-2021-21409: netty - Netty is an open-source, asynchronous event-driven network application framework...
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.61.Final there is a vulnerability that enables request smuggling. The content-length header is not correctly validated if the request only uses a single Http2HeaderFrame with the endStream set to to true. This could lead to request smuggling if the request is proxied to a remote peer and translated to HTTP/1.1. This is a followup of GHSA-wm47-8v5p-wjpj/CVE-2021-21295 which did miss to fix this one case. This was fixed as part of 4.1.61.Final.
Scope: local
bookworm: resolved (fixed in 1:4.1.48-4)
bullseye: resolved (fixed in 1:4.1.48-4)
forky: resolved (fixed in 1:4.1.48-4)
OSV
netty vulnerabilities
osv·2023-04-28·CVSS 7.5
CVE-2020-11612 [HIGH] netty vulnerabilities
netty vulnerabilities
It was discovered that Netty's Zlib decoders did not limit memory
allocations. A remote attacker could possibly use this issue to cause
Netty to exhaust memory via malicious input, leading to a denial of
service. This issue only affected Ubuntu 16.04 ESM and Ubuntu 20.04 ESM.
(CVE-2020-11612)
It was discovered that Netty created temporary files with excessive
permissions. A local attacker could possibly use this issue to expose
sensitive information. This issue only affected Ubuntu 16.04 ESM, Ubuntu
18.04 ESM, and Ubuntu 20.04 ESM. (CVE-2021-21290)
It was discovered that Netty did not properly validate content-length
headers. A remote attacker could possibly use this issue to smuggle
requests. This issue was only fixed in Ubuntu 20.04 ESM. (CVE-2021-21295,
CVE-2021
OSV
CVE-2021-21409: Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol serve
osv·2021-03-30·CVSS 5.9
CVE-2021-21409 [MEDIUM] CVE-2021-21409: Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol serve
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.61.Final there is a vulnerability that enables request smuggling. The content-length header is not correctly validated if the request only uses a single Http2HeaderFrame with the endStream set to to true. This could lead to request smuggling if the request is proxied to a remote peer and translated to HTTP/1.1. This is a followup of GHSA-wm47-8v5p-wjpj/CVE-2021-21295 which did miss to fix this one case. This was fixed as part of 4.1.61.Final.
GHSA
Possible request smuggling in HTTP/2 due missing validation
ghsa·2021-03-09
CVE-2021-21295 [MEDIUM] CWE-444 Possible request smuggling in HTTP/2 due missing validation
Possible request smuggling in HTTP/2 due missing validation
### Impact
If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1.
If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling.
In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has
OSV
CVE-2021-21295: Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol serve
osv·2021-03-09·CVSS 5.9
CVE-2021-21295 [MEDIUM] CVE-2021-21295: Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol serve
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request s
OSV
Possible request smuggling in HTTP/2 due missing validation
osv·2021-03-09
CVE-2021-21295 [MEDIUM] Possible request smuggling in HTTP/2 due missing validation
Possible request smuggling in HTTP/2 due missing validation
### Impact
If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1.
If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling.
In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has
No detection rules found.
No public exploits indexed.
Tenable
Oracle April 2022 Critical Patch Update Addresses 221 CVEs
blogs_tenable·2022-04-20
Oracle April 2022 Critical Patch Update Addresses 221 CVEs
## Cloud Exposure
Tenable Cloud Security (CNAPP) Request a demo
Tenable Cloud Vulnerability Management Request a demo
Tenable CIEM Request a demo
Secure your cloud
## Vulnerability Exposure
Tenable Vulnerability Management Try for free
Tenable Security Center Request a demo
Tenable Web App Scanning Try for free
Tenable Patch Management Request a demo
Tenable Enclave Security Request a demo
Tenable Attack Surface Management Request a demo
Tenable Nessus Try for free
## AI Exposure
Tenable AI Exposure Request a demo
## OT/IoT Exposure
Tenable OT Security Request a demo
## Identity Exposure
Tenable Identity Exposure Request a demo
## Business needs
Active Directory
AI Security Posture Management (AI-SPM)
AWS security
Azure security
Cloud Security Posture Man
arXiv
Security Review of Ethereum Beacon Clients
arxiv_fulltext·2021-09-23
Security Review of Ethereum Beacon Clients
center
[width=7cm]beacon
empty
1cm
Security Review of Ethereum Beacon Clients
1cm
JP Aumasson -- Taurus, Switzerland -- [email protected],
Denis Kolegov -- Tomsk State University, Russia -- [email protected]
Evangelia Stathopoulou -- University College London, UK -- [email protected]
0.5cm
Version
0.5cm
Supported by the Ethereum Foundation.
center
## Abstract
The beacon chain is the backbone of the Ethereum's evolution
towards a proof-of-stake-based scalable network.
Beacon clients are the applications implementing the services
required to operate the beacon chain, namely validators, beacon
nodes, and slashers.
Security defects in beacon clients could lead to loss of funds,
consensus rules violation, network congestion, and other
inconveniences.
We repo
https://github.com/Netflix/zuul/pull/980https://github.com/netty/netty/commit/89c241e3b1795ff257af4ad6eadc616cb2fb3dc4https://github.com/netty/netty/security/advisories/GHSA-wm47-8v5p-wjpjhttps://lists.apache.org/thread.html/r02e467123d45006a1dda20a38349e9c74c3a4b53e2e07be0939ecb3f%40%3Cdev.ranger.apache.org%3Ehttps://lists.apache.org/thread.html/r040a5e4d9cca2f98354b58a70b27099672276f66995c4e2e39545d0b%40%3Cissues.hbase.apache.org%3Ehttps://lists.apache.org/thread.html/r04a3e0d9f53421fb946c60cc54762b7151dc692eb4e39970a7579052%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/r0b09f3e31e004fe583f677f7afa46bd30110904576c13c5ac818ac2c%40%3Cissues.flink.apache.org%3Ehttps://lists.apache.org/thread.html/r15f66ada9a5faf4bac69d9e7c4521cedfefa62df9509881603791969%40%3Cjira.kafka.apache.org%3Ehttps://lists.apache.org/thread.html/r16c4b55ac82be72f28adad4f8061477e5f978199d5725691dcc82c24%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/r1908a34b9cc7120e5c19968a116ddbcffea5e9deb76c2be4fa461904%40%3Cdev.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/r1bca0b81193b74a451fc6d687ab58ef3a1f5ec40f6c61561d8dd9509%40%3Cissues.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/r22adb45fe902aeafcd0a1c4db13984224a667676c323c66db3af38a1%40%3Ccommits.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/r22b2f34447d71c9a0ad9079b7860323d5584fb9b40eb42668c21eaf1%40%3Cissues.hbase.apache.org%3Ehttps://lists.apache.org/thread.html/r268850f26639ebe249356ed6d8edb54ee8943be6f200f770784fb190%40%3Cissues.hbase.apache.org%3Ehttps://lists.apache.org/thread.html/r27b7e5a588ec826b15f38c40be500c50073400019ce7b8adfd07fece%40%3Cissues.hbase.apache.org%3Ehttps://lists.apache.org/thread.html/r2936730ef0a06e724b96539bc7eacfcd3628987c16b1b99c790e7b87%40%3Cissues.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/r2e93ce23e04c3f0a61e987d1111d0695cb668ac4ec4edbf237bd3e80%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/r312ce5bd3c6bf08c138349b507b6f1c25fe9cf40b6f2b0014c9d12b1%40%3Cnotifications.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/r32b0b640ad2be3b858f0af51c68a7d5c5a66a462c8bbb93699825cd3%40%3Cissues.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/r33eb06b05afbc7df28d31055cae0cb3fd36cab808c884bf6d680bea5%40%3Cdev.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/r393a339ab0b63ef9e6502253eeab26e7643b3e69738d5948b2b1d064%40%3Cissues.hbase.apache.org%3Ehttps://lists.apache.org/thread.html/r3c293431c781696681abbfe1c573c2d9dcdae6fd3ff330ea22f0433f%40%3Cjira.kafka.apache.org%3Ehttps://lists.apache.org/thread.html/r3c4596b9b37f5ae91628ccf169d33cd5a0da4b16b6c39d5bad8e03f3%40%3Cdev.jackrabbit.apache.org%3Ehttps://lists.apache.org/thread.html/r3ff9e735ca33612d900607dc139ebd38a64cadc6bce292e53eb86d7f%40%3Cissues.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/r490ca5611c150d193b320a2608209180713b7c68e501b67b0cffb925%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/r4ea2f1a9d79d4fc1896e085f31fb60a21b1770d0a26a5250f849372d%40%3Cissues.kudu.apache.org%3Ehttps://lists.apache.org/thread.html/r5232e33a1f3b310a3e083423f736f3925ebdb150844d60ac582809f8%40%3Cnotifications.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/r5470456cf1409a99893ae9dd57439799f6dc1a60fda90e11570f66fe%40%3Cnotifications.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/r57245853c7245baab09eae08728c52b58fd77666538092389cc3e882%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/r584cf871f188c406d8bd447ff4e2fd9817fca862436c064d0951a071%40%3Ccommits.pulsar.apache.org%3Ehttps://lists.apache.org/thread.html/r59bac5c09f7a4179b9e2460e8f41c278aaf3b9a21cc23678eb893e41%40%3Cjira.kafka.apache.org%3Ehttps://lists.apache.org/thread.html/r5baac01f9e06c40ff7aab209d5751b3b58802c63734e33324b70a06a%40%3Cissues.flink.apache.org%3Ehttps://lists.apache.org/thread.html/r5e66e286afb5506cdfe9bbf68a323e8d09614f6d1ddc806ed0224700%40%3Cjira.kafka.apache.org%3Ehttps://lists.apache.org/thread.html/r5fc5786cdd640b1b0a3c643237ce0011f0a08a296b11c0e2c669022c%40%3Cdev.kafka.apache.org%3Ehttps://lists.apache.org/thread.html/r602e98daacc98934f097f07f2eed6eb07c18bfc1949c8489dc7bfcf5%40%3Cissues.flink.apache.org%3Ehttps://lists.apache.org/thread.html/r67c4f90658fde875521c949448c54c98517beecdc7f618f902c620ec%40%3Cissues.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/r67e6a636cbc1958383a1cd72b7fd0cd7493360b1dd0e6c12f5761798%40%3Cnotifications.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/r6a122c25e352eb134d01e7f4fc4d345a491c5ee9453fef6fc754d15b%40%3Ccommits.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/r6a29316d758db628a1df49ca219d64caf493999b52cc77847bfba675%40%3Cnotifications.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/r6aee7e3566cb3e51eeed2fd8786704d91f80a7581e00a787ba9f37f6%40%3Cissues.hbase.apache.org%3Ehttps://lists.apache.org/thread.html/r6d32fc3cd547f7c9a288a57c7f525f5d00a00d5d163613e0d10a23ef%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/r70cebada51bc6d49138272437d8a28fe971d0197334ef906b575044c%40%3Ccommits.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/r790c2926efcd062067eb18fde2486527596d7275381cfaff2f7b3890%40%3Cissues.bookkeeper.apache.org%3Ehttps://lists.apache.org/thread.html/r7bb3cdc192e9a6f863d3ea05422f09fa1ae2b88d4663e63696ee7ef5%40%3Cdev.ranger.apache.org%3Ehttps://lists.apache.org/thread.html/r837bbcbf12e335e83ab448b1bd2c1ad7e86efdc14034b23811422e6a%40%3Ccommits.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/r855b4b6814ac829ce2d48dd9d8138d07f33387e710de798ee92c011e%40%3Cissues.flink.apache.org%3Ehttps://lists.apache.org/thread.html/r86cd38a825ab2344f3e6cad570528852f29a4ffdf56ab67d75c36edf%40%3Cissues.hbase.apache.org%3Ehttps://lists.apache.org/thread.html/r8bcaf7821247b1836b10f6a1a3a3212b06272fd4cde4a859de1b78cf%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/r8db1d7b3b9acc9e8d2776395e280eb9615dd7790e1da8c57039963de%40%3Cnotifications.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/r9051e4f484a970b5566dc1870ecd9c1eb435214e2652cf3ea4d0c0cc%40%3Cjira.kafka.apache.org%3Ehttps://lists.apache.org/thread.html/r905b92099998291956eebf4f1c5d95f5a0cbcece2946cc46d32274fd%40%3Cdev.hbase.apache.org%3Ehttps://lists.apache.org/thread.html/r96ce18044880c33634c4b3fcecc57b8b90673c9364d63eba00385523%40%3Cjira.kafka.apache.org%3Ehttps://lists.apache.org/thread.html/r9924ef9357537722b28d04c98a189750b80694a19754e5057c34ca48%40%3Ccommits.pulsar.apache.org%3Ehttps://lists.apache.org/thread.html/ra64d56a8a331ffd7bdcd24a9aaaeeedeacd5d639f5a683389123f898%40%3Cdev.flink.apache.org%3Ehttps://lists.apache.org/thread.html/ra655e5cec74d1ddf62adacb71d398abd96f3ea2c588f6bbf048348eb%40%3Cissues.kudu.apache.org%3Ehttps://lists.apache.org/thread.html/ra83096bcbfe6e1f4d54449f8a013117a0536404e9d307ab4a0d34f81%40%3Cissues.hbase.apache.org%3Ehttps://lists.apache.org/thread.html/ra96c74c37ed7252f78392e1ad16442bd16ae72a4d6c8db50dd55c88b%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/racc191a1f70a4f13155e8002c61bddef2870b26441971c697436ad5d%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/rae198f44c3f7ac5264045e6ba976be1703cff38dcf1609916e50210d%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/rb06c1e766aa45ee422e8261a8249b561784186483e8f742ea627bda4%40%3Cdev.kafka.apache.org%3Ehttps://lists.apache.org/thread.html/rb51d6202ff1a773f96eaa694b7da4ad3f44922c40b3d4e1a19c2f325%40%3Ccommits.pulsar.apache.org%3Ehttps://lists.apache.org/thread.html/rb523bb6c60196c5f58514b86a8585c2069a4852039b45de3818b29d2%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/rb592033a2462548d061a83ac9449c5ff66098751748fcd1e2d008233%40%3Cissues.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/rb95d42ce220ed4a4683aa17833b5006d657bc4254bc5cb03cd5e6bfb%40%3Cissues.hbase.apache.org%3Ehttps://lists.apache.org/thread.html/rbadcbcb50195f00bbd196403865ced521ca70787999583c07be38d0e%40%3Cnotifications.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/rbed09768f496244a2e138dbbe6d2847ddf796c9c8ef9e50f2e3e30d9%40%3Cnotifications.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/rc0087125cb15b4b78e44000f841cd37fefedfda942fd7ddf3ad1b528%40%3Cissues.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/rc165e36ca7cb5417aec3f21bbc4ec00fb38ecebdd96a82cfab9bd56f%40%3Cjira.kafka.apache.org%3Ehttps://lists.apache.org/thread.html/rc73b8dd01b1be276d06bdf07883ecd93fe1a01f139a99ef30ba4308c%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/rca0978b634a0c3ebee4126ec29c7f570b165fae3f8f3658754c1cbd3%40%3Cissues.kudu.apache.org%3Ehttps://lists.apache.org/thread.html/rcd163e421273e8dca1c71ea298dce3dd11b41d51c3a812e0394e6a5d%40%3Ccommits.pulsar.apache.org%3Ehttps://lists.apache.org/thread.html/rcf3752209a8b04996373bf57fdc808b3bfaa2be8702698a0323641f8%40%3Ccommits.hbase.apache.org%3Ehttps://lists.apache.org/thread.html/rcfc154eb2de23d2dc08a56100341161e1a40a8ea86c693735437e8f2%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/rcfc535afd413d9934d6ee509dce234dac41fa3747a7555befb17447e%40%3Cissues.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/rd25c88aad0e76240dd09f0eb34bdab924933946429e068a167adcb73%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/rd4a6b7dec38ea6cd28b6f94bd4b312629a52b80be3786d5fb0e474bc%40%3Cissues.kudu.apache.org%3Ehttps://lists.apache.org/thread.html/rd8f72411fb75b98d366400ae789966373b5c3eb3f511e717caf3e49e%40%3Cissues.flink.apache.org%3Ehttps://lists.apache.org/thread.html/rdb4db3f5a9c478ca52a7b164680b88877a5a9c174e7047676c006b2c%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/rdc096e13ac4501ea2e2b03a197682a313b85d3d3ec89d5ae5551b384%40%3Cissues.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/rddbb4f8d5db23265bb63d14ef4b3723b438abc1589f877db11d35450%40%3Cissues.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/re4f70b62843e92163fab03b65e2aa8078693293a0c36f1cc260079ed%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/re6207ebe2ca4d44f2a6deee695ad6f27fd29d78980f1d46ed1574f91%40%3Cissues.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/re7c69756a102bebce8b8681882844a53e2f23975a189363e68ad0324%40%3Cissues.flink.apache.org%3Ehttps://lists.apache.org/thread.html/reafc834062486adfc7be5bb8f7b7793be0d33f483678a094c3f9d468%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/rf36f1114e84a3379b20587063686148e2d5a39abc0b8a66ff2a9087a%40%3Cissues.zookeeper.apache.org%3Ehttps://lists.apache.org/thread.html/rf87b870a22aa5c77c27900967b518a71a7d954c2952860fce3794b60%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/rf934292a4a1c189827f625d567838d2c1001e4739b158638d844105b%40%3Cissues.kudu.apache.org%3Ehttps://lists.apache.org/thread.html/rfff6ff8ffb31e8a32619c79774def44b6ffbb037c128c5ad3eab7171%40%3Cissues.zookeeper.apache.org%3Ehttps://security.netapp.com/advisory/ntap-20210604-0003/https://www.debian.org/security/2021/dsa-4885https://www.oracle.com/security-alerts/cpuapr2022.htmlhttps://github.com/Netflix/zuul/pull/980https://github.com/netty/netty/commit/89c241e3b1795ff257af4ad6eadc616cb2fb3dc4https://github.com/netty/netty/security/advisories/GHSA-wm47-8v5p-wjpjhttps://lists.apache.org/thread.html/r02e467123d45006a1dda20a38349e9c74c3a4b53e2e07be0939ecb3f%40%3Cdev.ranger.apache.org%3Ehttps://lists.apache.org/thread.html/r040a5e4d9cca2f98354b58a70b27099672276f66995c4e2e39545d0b%40%3Cissues.hbase.apache.org%3Ehttps://lists.apache.org/thread.html/r04a3e0d9f53421fb946c60cc54762b7151dc692eb4e39970a7579052%40%3Ccommits.servicecomb.apache.org%3Ehttps://lists.apache.org/thread.html/r0b09f3e31e004fe583f677f7afa46bd30110904576c13c5ac818ac2c%40%3Cissues.flink.apache.org%3Ehttps://lists.apache.org/thread.html/r15f66ada9a5faf4bac69d9e7c4521cedfefa62df9509881603791969%40%3Cjira.kafka.apache.org%3Ehttps://lists.apache.org/thread.html/r16c4b55ac82be72f28adad4f8061477e5f978199d5725691dcc82c24%40%3Ccommits.servicecomb.apache.org%3E
+ 82 more references
2021-03-09
Published