[
https://issues.apache.org/jira/browse/CASSANDRA-21481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Schnepf updated CASSANDRA-21481:
------------------------------------------
Description:
Hi,
we're running Cassandra 4.1(.11) and got a vulnerability report which lists
e.g. CVE-2026-50010 due to the latest findings in Netty. I had a look and it
seems it is not exploitable: Cassandra does not rely on Netty's flawed
trust-manager hostname verification; it sets
endpointIdentificationAlgorithm("HTTPS") directly on the SSLEngine
(SocketFactory.java:227, active when require_endpoint_verification: true). The
JSSE check runs independently of the vulnerable code path.
Is there a chance to bump _netty-all_ from *4.1.58.Final* → *4.1.135.Final* and
_netty-tcnative-boringssl-static_ from *2.0.36.Final* → *2.0.70.Final*
or alternatively could we extend the suppression list?
It was a scan of "Black Duck", which lists quite some vulnerabilities for Netty
in general, for parts which are just not used in Cassandra
(netty-codec-haproxy, -redis or -http2), like CVE-2026-44890, but still shows
up in the netty-all bundle.
Thead in Slack: https://the-asf.slack.com/archives/CK23JSY2K/p1781524939161659
was:
Hi,
we're running Cassandra 4.1(.11) and got a vulnerability report which lists
e.g. CVE-2026-50010 due to the latest findings in Netty. I had a look and it
seems it is not exploitable: Cassandra does not rely on Netty's flawed
trust-manager hostname verification; it sets
endpointIdentificationAlgorithm("HTTPS") directly on the SSLEngine
(SocketFactory.java:227, active when require_endpoint_verification: true). The
JSSE check runs independently of the vulnerable code path.
Is there a chance to bump netty-all from `4.1.58.Final` → `4.1.135.Final` and
`netty-tcnative-boringssl-static` from `2.0.36.Final` → `2.0.70.Final`
or alternatively could we extend the suppression list?
It was a scan of "Black Duck", which lists quite some vulnerabilities for Netty
in general, for parts which are just not used in Cassandra
(netty-codec-haproxy, -redis or -http2), like CVE-2026-44890, but still shows
up in the netty-all bundle.
Thead in Slack: https://the-asf.slack.com/archives/CK23JSY2K/p1781524939161659
> CVE's around Netty in Cassandra
> -------------------------------
>
> Key: CASSANDRA-21481
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21481
> Project: Apache Cassandra
> Issue Type: Bug
> Reporter: Christoph Schnepf
> Priority: Normal
>
> Hi,
> we're running Cassandra 4.1(.11) and got a vulnerability report which lists
> e.g. CVE-2026-50010 due to the latest findings in Netty. I had a look and it
> seems it is not exploitable: Cassandra does not rely on Netty's flawed
> trust-manager hostname verification; it sets
> endpointIdentificationAlgorithm("HTTPS") directly on the SSLEngine
> (SocketFactory.java:227, active when require_endpoint_verification: true).
> The JSSE check runs independently of the vulnerable code path.
> Is there a chance to bump _netty-all_ from *4.1.58.Final* → *4.1.135.Final*
> and _netty-tcnative-boringssl-static_ from *2.0.36.Final* → *2.0.70.Final*
> or alternatively could we extend the suppression list?
> It was a scan of "Black Duck", which lists quite some vulnerabilities for
> Netty in general, for parts which are just not used in Cassandra
> (netty-codec-haproxy, -redis or -http2), like CVE-2026-44890, but still shows
> up in the netty-all bundle.
> Thead in Slack: https://the-asf.slack.com/archives/CK23JSY2K/p1781524939161659
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
