Artifactory, OpenWrt e TeamCity correggono falle critiche nei server

🛡️ Executive Summary

• JFrog raccomanda l’aggiornamento immediato di Artifactory per più vulnerabilità concatenabili in attacchi critici, senza divulgarne ancora i dettagli.
• OpenWrt corregge CVE-2026-53921, overflow DHCPv6 pre-auth che può eseguire codice come root sui router raggiungibili.
• TeamCity risolve CVE-2026-63077, bypass di autenticazione capace di compromettere server, credenziali e pipeline CI/CD.

JFrog Artifactory, OpenWrt e JetBrains TeamCity hanno pubblicato aggiornamenti di sicurezza urgenti per infrastrutture che occupano posizioni particolarmente sensibili nelle reti e nelle catene di sviluppo. JFrog segnala più vulnerabilità concatenabili in attacchi critici contro le installazioni self-managed di Artifactory, pur senza rendere pubblici i dettagli tecnici. OpenWrt corregge invece un overflow nello stack del server DHCPv6 che può consentire a un aggressore non autenticato di eseguire codice con privilegi root. TeamCity chiude infine un bypass dell’autenticazione pre-auth capace di impartire comandi al sistema operativo e compromettere credenziali, configurazioni, build e artefatti software.

JFrog corregge vulnerabilità concatenabili in Artifactory

Le note di rilascio di JFrog Artifactory Self-Managed contengono un avviso esplicito: la nuova versione è stata progettata per correggere più vulnerabilità di sicurezza che possono essere concatenate fino a produrre attacchi critici. JFrog raccomanda a tutti i clienti di installare la release più recente, senza però pubblicare al momento codici CVE, prerequisiti, vettori o descrizioni delle singole falle. Questa riservatezza riduce la possibilità di costruire immediatamente un exploit partendo dall’advisory, ma complica anche la valutazione per gli amministratori, che non possono stabilire con precisione se l’istanza sia esposta attraverso accesso anonimo, account con privilegi ridotti, repository remoti o API amministrative. Artifactory non è un semplice archivio di file: conserva pacchetti, immagini container, metadati, token, configurazioni dei repository e componenti destinati alle pipeline di produzione. Una compromissione può quindi alterare ciò che gli sviluppatori scaricano o ciò che viene distribuito verso gli ambienti finali. La rilevanza di questi sistemi emerge anche negli attacchi alla supply chain npm attraverso pacchetti AsyncAPI compromessi, dove la fiducia trasferita ai componenti software permette a una singola intrusione di propagarsi verso migliaia di progetti.

L’assenza dei dettagli non riduce l’urgenza dell’aggiornamento

Quando un produttore descrive una catena critica senza divulgarne i singoli passaggi, l’assenza di informazioni pubbliche non deve essere interpretata come assenza di rischio. Gli amministratori dovrebbero verificare la versione installata, preparare un backup coerente, applicare l’ultima release supportata e controllare le attività avvenute prima dell’aggiornamento. Particolare attenzione deve essere riservata alla creazione di utenti e token, alle modifiche dei permessi, ai repository aggiunti o riconfigurati, ai nuovi webhook, ai plugin, alle variazioni dei checksum e ai caricamenti effettuati da account normalmente inattivi. È opportuno ruotare le credenziali amministrative e i token utilizzati dalle pipeline quando emergono anomalie, perché una patch impedisce nuovi accessi attraverso il percorso corretto ma non revoca automaticamente segreti già sottratti. Le istanze Artifactory non dovrebbero inoltre essere esposte direttamente a Internet se l’accesso pubblico non è indispensabile. La segmentazione, l’autenticazione forte e la separazione tra repository di sviluppo e distribuzione riducono l’impatto di una compromissione. Le note ufficiali delle release self-managed di Artifactory restano la fonte da controllare per l’identificazione della build più recente e per eventuali dettagli aggiuntivi che JFrog potrà rendere disponibili dopo l’adozione delle correzioni.

OpenWrt espone il server DHCPv6 senza autenticazione

CVE-2026-53921, valutata 9,8 su 10, interessa odhcpd, il demone utilizzato da OpenWrt per gestire DHCPv6 e Router Advertisement. Un aggressore capace di raggiungere il servizio può inviare una richiesta DHCPv6 appositamente costruita alla porta UDP 547 e provocare la scrittura oltre i limiti di un buffer da 512 byte allocato sullo stack. L’advisory documenta due percorsi distinti nella gestione delle opzioni IA, entrambi collegati all’insufficiente verifica dello spazio residuo prima dell’aggiunta dei dati alla risposta. Il problema è particolarmente grave perché odhcpd opera come root e molti dispositivi embedded non dispongono di protezioni robuste come stack canary e ASLR pienamente efficaci. L’esito può quindi superare il semplice crash e trasformarsi nell’esecuzione di codice con il controllo completo del router. La vulnerabilità non richiede credenziali, ma l’attaccante deve poter raggiungere il server DHCPv6: nelle configurazioni normali il servizio è destinato alla rete locale, mentre esposizioni errate, reti condivise o segmenti non fidati possono ampliare il perimetro.

OpenWrt 24.10.8 corregge più difetti nei servizi predefiniti

Gli utenti del ramo OpenWrt 24.10 devono installare la versione 24.10.8, mentre quelli della serie 25.12 devono passare alla 25.12.5. La correzione introduce controlli sulla capacità residua del buffer prima di aggiungere i dati della risposta DHCPv6. Le release chiudono anche ulteriori problemi pre-authentication in odhcpd, tra cui scritture fuori limite, use-after-free, esposizione della memoria, denial of service, letture oltre lo stack e spoofing del proxy Neighbor Discovery. Sono presenti inoltre correzioni per tre vulnerabilità di HTTP request smuggling in uhttpd e per CVE-2026-62948, attraverso la quale un hostname DHCPv6 malevolo può produrre stored XSS nella pagina delle lease di LuCI quando viene aperta da un amministratore. Non tutte le vulnerabilità discusse parallelamente dai ricercatori di Hacker House risultavano però incluse nella release stabile al momento della pubblicazione: alcuni fix per componenti LuCI opzionali erano ancora in revisione. Occorre quindi evitare di attribuire automaticamente a OpenWrt 24.10.8 ogni correzione descritta nello stesso articolo. L’aggiornamento resta comunque prioritario perché chiude il percorso DHCPv6 più grave e diversi problemi nei servizi abilitati per impostazione predefinita. La precedente analisi sulle vulnerabilità OpenWrt e sulle backdoor contro i router aveva già mostrato come un apparato di rete compromesso possa diventare punto di intercettazione, persistenza e movimento laterale.

Le falle LuCI richiedono verifiche separate dai firmware

L’audit assistito dall’intelligenza artificiale condotto da Hacker House ha individuato ulteriori problemi di command injection, path traversal e cross-site scripting in applicazioni LuCI opzionali. Alcuni richiedono un account autenticato e specifici permessi, mentre altri possono diventare raggiungibili senza sessione soltanto quando l’amministratore ha deliberatamente esposto un comando parametrizzato come pubblico. Una vulnerabilità in luci-app-olsr permette invece a un nodo mesh malevolo di inserire un hostname che esegue codice nel browser quando l’amministratore apre la pagina dei vicini. Questi difetti non rappresentano una RCE anonima universale contro ogni router OpenWrt e non devono essere confusi con CVE-2026-53921. Le organizzazioni devono verificare quali pacchetti LuCI siano effettivamente installati, rimuovere quelli inutilizzati, limitare i permessi delegati e controllare se luci-app-commands contenga funzioni contemporaneamente pubbliche e parametrizzate. I pacchetti installati separatamente dall’immagine firmware possono inoltre richiedere aggiornamenti autonomi. Al momento della divulgazione non risultavano prove pubbliche di sfruttamento attivo di CVE-2026-53921 e la falla non compariva nel catalogo KEV di CISA, ma la presenza di proof of concept pubblici riduce il margine disponibile per aggiornare.

TeamCity permette comandi remoti prima del login

CVE-2026-63077 interessa tutte le versioni di TeamCity On-Premises e consente a un aggressore non autenticato con accesso HTTP o HTTPS al server di bypassare i controlli di autenticazione ed eseguire comandi arbitrari con i privilegi del processo TeamCity. Il percorso vulnerabile si trova nel protocollo utilizzato per il polling degli agenti, che può essere raggiunto prima del login e trasformato in un canale per impartire istruzioni al sistema operativo. L’impatto dipende dai privilegi assegnati al servizio, ma può comprendere accesso ai dati di TeamCity, configurazioni, credenziali memorizzate, chiavi, token e repository collegati. Un attaccante potrebbe inoltre modificare lo stato del server, manipolare build e compromettere l’integrità degli artefatti prodotti dalle pipeline. Questo rende la vulnerabilità più grave di una normale intrusione applicativa: il sistema CI/CD rappresenta un ponte tra sorgenti, segreti, agenti di compilazione e pacchetti distribuiti. Le precedenti campagne in cui BianLian sfruttava TeamCity per gli attacchi ransomware e gruppi criminali utilizzavano una grave falla JetBrains dimostrano che queste piattaforme vengono rapidamente trasformate in punti di accesso alla supply chain.

JetBrains corregge TeamCity e distribuisce un plugin di emergenza

JetBrains ha corretto CVE-2026-63077 nelle versioni 2025.11.7 e 2026.1.3 e raccomanda l’aggiornamento immediato di ogni server on-premises. Per gli ambienti che non possono effettuare subito il passaggio, il produttore ha pubblicato un security patch plugin compatibile con TeamCity 2017.1 e versioni successive. Sui rami dal 2017.1 al 2018.1 il server deve essere riavviato dopo l’installazione, mentre dalle versioni successive il plugin può essere attivato senza reboot. La misura corregge esclusivamente CVE-2026-63077 e non sostituisce l’aggiornamento completo, che comprende anche ulteriori correzioni di sicurezza e stabilità. TeamCity Cloud non richiede interventi perché le protezioni sono state applicate dal fornitore e JetBrains dichiara di non avere evidenze di sfruttamento della vulnerabilità negli ambienti gestiti. Anche per le installazioni on-premises non risultavano attacchi attivi al momento dell’advisory, ma l’assenza di prove non elimina il rischio per i server già esposti. Il bollettino JetBrains dedicato a CVE-2026-63077 raccomanda inoltre di limitare TeamCity alle reti fidate, utilizzare VPN o un ulteriore livello di accesso e separare il server dagli agenti di build.

Repository, router e CI/CD richiedono controlli dopo la patch

I tre aggiornamenti interessano prodotti diversi, ma condividono un elemento operativo: tutti occupano una posizione capace di amplificare una singola compromissione. Artifactory controlla la distribuzione dei componenti software, OpenWrt instrada e osserva il traffico della rete, mentre TeamCity genera build e gestisce credenziali destinate ai sistemi successivi. Gli amministratori non devono quindi limitarsi a verificare che l’upgrade sia terminato correttamente. Su Artifactory occorre controllare utenti, token, repository e checksum; sui router OpenWrt è necessario esaminare configurazioni, processi e modifiche persistenti; su TeamCity devono essere revisionate build, agenti, credenziali, plugin e artefatti prodotti durante il periodo di esposizione. Particolare attenzione va riservata ai server TeamCity direttamente raggiungibili da Internet e alle installazioni Artifactory che consentono accesso anonimo o integrano numerose pipeline. La patch chiude il percorso vulnerabile, ma non rende automaticamente affidabili pacchetti, build o configurazioni che un aggressore potrebbe avere già modificato prima dell’intervento.