CVE-2026-47691, CVE-2026-45674, CVE-2026-44249, CVE-2026-45416, CVE-2026-45673
Data: 2026-06-09
Severity: High
CVSS Score:
CVE-2026-47691: 8.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N)
CVE-2026-45674: 8.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N)
CVE-2026-44249: 8.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H)
CVE-2026-45416: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
CVE-2026-45673: 6.8 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N)
Nota
La severity e i CVSS Score si riferiscono alle vulnerabilità delle librerie. Come descritto nella sezione GovWay, le vulnerabilità lato server (CVE-2026-44249 e CVE-2026-45416) non si manifestano nel prodotto, mentre per quelle relative al resolver DNS (CVE-2026-47691, CVE-2026-45674, CVE-2026-45673) il rischio è fortemente limitato dal contesto di deployment.
Riferimenti:
CVE-2026-47691 (GHSA-5pvg-856g-cp85):
CVE-2026-45674 (GHSA-676x-f7gg-47vc):
CVE-2026-44249 (GHSA-3qp7-7mw8-wx86):
CVE-2026-45416 (GHSA-x4gw-5cx5-pgmh):
CVE-2026-45673 (GHSA-xmv7-r254-6q78):
Libreria: io.netty:netty-resolver-dns, io.netty:netty-handler (>= 4.2.0.Final, <= 4.2.14.Final)
Descrizione
[CVE-2026-47691] CWE-349: Acceptance of Extraneous Untrusted Data With Trusted Data (DNS Cache Poisoning)
Il resolver DNS di Netty (DnsResolveContext.AuthoritativeNameServerList#add) non valida correttamente la bailiwick dei record NS: accetta qualsiasi record NS presente nella sezione AUTHORITY purché il nome del record sia un suffisso della questionName. Un attaccante che controlli un name server autoritativo per un sottodominio può quindi inserire record NS che rivendicano autorità sul dominio padre (es. co.uk.); i corrispondenti record A presenti nella sezione ADDITIONAL vengono memorizzati in authoritativeDnsServerCache sotto la chiave del dominio padre, avvelenando la cache per tutte le risoluzioni successive. Risolto nella versione 4.2.15.Final.
[CVE-2026-45674] CWE-349: Acceptance of Extraneous Untrusted Data With Trusted Data (DNS Cache Poisoning)
Il resolver DNS di Netty (DnsResolveContext#buildAliasMap) elabora la sezione ANSWER di una risposta DNS e memorizza tutti i record CNAME senza verificarne l’origine (bailiwick), in violazione di quanto previsto da RFC 5452, Section 6 (i dati vanno accettati solo se l’originatore è autoritativo per la QNAME o per un suo genitore). Ciò abilita attacchi di DNS Cache Poisoning. Risolto nella versione 4.2.15.Final.
[CVE-2026-44249] CWE-284: Improper Access Control (IPv6 Subnet Filter Bypass)
Il metodo IpSubnetFilterRule#compareTo(InetSocketAddress) di Netty esegue l’operazione di AND bit a bit tra l’indirizzo IP in ingresso e il networkAddress configurato anziché con la subnetMask. Per effetto di questo masking errato, indirizzi IPv6 pubblici validi possono eludere le regole di subnet configurate, bypassando i controlli di accesso basati su IpSubnetFilter. Risolto nella versione 4.2.15.Final.
[CVE-2026-45416] CWE-770: Allocation of Resources Without Limits or Throttling
SslClientHelloHandler.decode() legge la lunghezza a 24 bit dell’handshake TLS e, quando il ClientHello non rientra nel primo record, alloca immediatamente un buffer di dimensione pari alla lunghezza dichiarata. Con i costruttori comunemente usati di SniHandler/AbstractSniHandler (maxClientHelloLength=0 e handshakeTimeoutMillis=0) il controllo sulla lunghezza è disabilitato e non viene schedulato alcun timeout: una richiesta che dichiara 16 MiB provoca un’allocazione immediata (non poolizzata) trattenuta fino alla chiusura del canale. Un attaccante può così innescare una Denial of Service inviando pochi byte. Risolto nella versione 4.2.15.Final.
[CVE-2026-45673] CWE-330: Use of Insufficiently Random Values (DNS Cache Poisoning / Kaminsky)
Il resolver DNS di Netty utilizza un PRNG prevedibile per la generazione dei transaction ID DNS (DnsQueryIdSpace reinserisce gli ID tramite ThreadLocalRandom, un LCG prevedibile) e, con il channelStrategy di default ChannelPerResolver, una porta UDP sorgente statica. La combinazione riduce l’entropia delle query DNS, facilitando attacchi di DNS Cache Poisoning (Kaminsky). Risolto nella versione 4.2.15.Final.
GovWay
Le librerie Netty non sono utilizzate direttamente da GovWay: vengono incluse esclusivamente come dipendenza transitiva di Redisson (org.redisson:redisson:4.3.1), il client utilizzato per connettersi a un server Redis quando l’amministratore abilita le funzionalità distribuite basate su Redis (contatori distribuiti del controllo del traffico / rate limiting in cluster, cache distribuita, protezione anti-replay JTI). In questo contesto Netty opera unicamente come client verso il server Redis.
Le cinque vulnerabilità presentano un impatto differenziato sul prodotto.
Vulnerabilità non esercitate (non si manifestano in GovWay)
CVE-2026-44249 riguarda l’handler di access control
IpSubnetFilterdi Netty (filtro lato server della pipeline), che non viene mai istanziato né da Redisson né da GovWay;CVE-2026-45416 riguarda
SslClientHelloHandler/SniHandler, ovvero la gestione lato server del ClientHello TLS in ingresso; GovWay non espone alcun server TLS basato su Netty (Redisson agisce esclusivamente come client TLS verso Redis), pertanto tali handler non vengono utilizzati.
Vulnerabilità sul resolver DNS (rischio residuo limitato dal deployment)
Le tre vulnerabilità di DNS Cache Poisoning (CVE-2026-47691, CVE-2026-45674, CVE-2026-45673) insistono invece su codice effettivamente esercitato: Redisson impiega il resolver DNS di Netty per risolvere e monitorare gli hostname dei nodi Redis. Il codice vulnerabile è quindi raggiungibile e la criticità è da considerarsi potenzialmente sfruttabile, sebbene il rischio effettivo sia fortemente limitato dal contesto di esercizio:
la risoluzione riguarda esclusivamente gli hostname dei nodi Redis configurati dall’amministratore, e non il traffico applicativo gestito da GovWay; un’eventuale cache avvelenata potrebbe al più dirottare le connessioni verso il backend Redis, non le richieste verso gli applicativi esposti;
Redis viene tipicamente collocato in una rete interna fidata; lo sfruttamento richiede un attaccante in grado di iniettare risposte DNS contraffatte per quelle specifiche query (posizione on-path, oppure attacco off-path tipo Kaminsky contro il resolver utilizzato);
come mitigazione applicabile da subito, è possibile configurare l’endpoint Redis tramite indirizzo IP anziché hostname, evitando del tutto la risoluzione DNS, oppure affidarsi a un resolver DNS fidato e protetto.
Il rischio è pertanto valutato basso, ma non nullo, fino all’aggiornamento della libreria.
Versione affette:
3.3.x: <= 3.3.19.p1
3.4.x: <= 3.4.2.p1
Risoluzione:
3.3.x: 3.3.20
3.4.x: 3.4.3