Tre falle critiche colpiscono Gitea, WebLogic e Keycloak

Tre vulnerabilità critiche emerse tra il 24 e il 26 agosto 2026 riguardano tre componenti molto diffusi in ambienti aziendali: Gitea, Oracle WebLogic e Keycloak. Due di queste, Gitea e Oracle WebLogic, risultano già sfruttate attivamente secondo CISA; la terza, Keycloak, non risulta al momento usata in attacchi reali, ma può consentire il controllo completo di qualsiasi account se non viene corretta.

Per un’azienda il punto non è solo tecnico: questi prodotti stanno spesso dietro repository di codice, applicazioni interne, portali e sistemi di autenticazione. Se restano esposti o non aggiornati, il rischio concreto va dal furto di dati all’accesso non autorizzato, fino all’uso dei server per attività malevole come il cryptojacking.

Cosa è successo

Negli ultimi giorni sono state rese note tre falle di severità molto alta o critica.

La prima riguarda Gitea, piattaforma open source per l’hosting di repository Git. Il 26 agosto 2026 The Hacker News ha riportato che CISA ha avvisato della presenza di sfruttamento attivo della vulnerabilità CVE-2026-60004, con punteggio CVSS 9.8. Si tratta di una vulnerabilità di esecuzione di codice da remoto che permette a un attaccante con normali permessi di scrittura su un repository di eseguire comandi shell come utente di sistema di Gitea.

La seconda interessa Oracle HTTP Server e Oracle WebLogic Server Proxy Plug-in. Il 25 agosto 2026 CISA ha inserito nel catalogo KEV la vulnerabilità CVE-2026-21962, con punteggio CVSS 10.0, indicando anche qui evidenze di sfruttamento attivo. In questo caso il problema consente a un attaccante non autenticato, raggiungibile via HTTP, di ottenere accesso non autorizzato o modificare dati critici.

La terza colpisce Keycloak, software open source di identity e access management. Il 24 agosto 2026 Red Hat e il progetto Keycloak hanno pubblicato correzioni per CVE-2026-18963, valutata 9.1. Non risultano exploit confermati in circolazione alla data del 24 agosto, ma la falla è particolarmente delicata perché consentirebbe a un attaccante remoto non autenticato di reimpostare la password di qualsiasi utente, inclusi account amministrativi.

Perché queste tre notizie meritano attenzione insieme

Anche se i prodotti sono diversi, il filo conduttore è chiaro: gli attaccanti stanno continuando a colpire componenti infrastrutturali centrali, non solo i PC degli utenti.

Gitea è spesso usato dai team di sviluppo o dai fornitori software. WebLogic compare ancora in molte applicazioni enterprise, portali legacy e integrazioni verticali. Keycloak presidia l’accesso a sistemi e applicazioni. In altre parole, non si parla di strumenti secondari: sono nodi strategici dell’ecosistema IT.

Quando una vulnerabilità interessa uno di questi livelli, il danno potenziale non è limitato al singolo server. Può diventare un punto d’ingresso verso codice sorgente, dati aziendali, ambienti di test e produzione, identità digitali e applicazioni interne.

Il caso Gitea: rischio concreto anche senza credenziali rubate

L’aspetto più insidioso della vulnerabilità di Gitea è la combinazione tra gravità tecnica e configurazioni permissive molto comuni.

Secondo l’avviso del progetto, il problema nasce dall’abuso dell’endpoint diffpatch, che può essere usato per installare ed eseguire un hook Git tramite contenuti controllati dal repository. Se l’istanza Gitea permette la registrazione aperta, un visitatore esterno può ottenere da solo il requisito minimo necessario: creare un account, aprire un repository e ottenere i diritti di scrittura al suo interno.

Le versioni interessate sono tutte dalla 1.17 e la correzione è arrivata con Gitea 1.27.1.

Un’analisi indipendente citata nelle fonti descrive un caso in cui l’exploit sarebbe stato usato per distribuire un payload simile a un miner di criptovalute. L’episodio è emerso dopo una segnalazione del provider HOSTKEY, che aveva rilevato per lungo tempo un utilizzo superiore al 70% della CPU su un VPS, arrivando a limitarne temporaneamente le risorse.

È un dettaglio importante per le aziende: non tutti gli attacchi puntano subito al furto di dati. A volte il primo segnale è un degrado anomalo delle prestazioni, costi infrastrutturali più alti o blocchi imposti dal provider.

Oracle WebLogic: una falla da CVSS 10 già nel mirino

Nel caso di Oracle WebLogic, la situazione è ancora più severa sul piano teorico: CVE-2026-21962 ha punteggio 10.0, il massimo della scala CVSS.

Secondo CISA, la vulnerabilità è dovuta a un problema di controllo degli accessi in Oracle HTTP Server e Oracle WebLogic Server Proxy Plug-in. Un attaccante non autenticato con accesso via HTTP può compromettere le istanze bersaglio, ottenere accesso a dati critici oppure crearli, cancellarli o modificarli senza autorizzazione.

Le patch erano state rilasciate da Oracle già a gennaio 2026, ma nel tempo sono emerse prove di sfruttamento reale da parte di più osservatori del settore, tra cui GreyNoise, CloudSEK e SOCRadar. Le fonti citano anche attività ostili che prendevano di mira più vulnerabilità note di WebLogic e, in un contesto più ampio, l’uso di questa CVE in campagne attribuite a un attore legato alla Cina contro infrastrutture governative e commerciali in oltre 100 Paesi.

Per chi gestisce applicazioni aziendali datate, il messaggio è semplice: se WebLogic è ancora presente, non basta presumere che sia “dietro il firewall” o poco visibile. È uno dei bersagli preferiti proprio perché è storicamente diffuso e spesso dimenticato nei cicli di aggiornamento.

Keycloak: nessun exploit confermato, ma impatto potenzialmente devastante

La vulnerabilità di Keycloak merita attenzione anche se, nelle fonti disponibili, non ci sono prove di sfruttamento attivo.

Il problema riguarda il flusso di reset password. In sostanza, una richiesta appositamente costruita può far avanzare la sessione di autenticazione direttamente alla fase di aggiornamento della password, senza richiedere il token di azione che normalmente viene inviato via e-mail. Se l’attacco riesce, l’aggressore può prendere il controllo di qualsiasi account, compresi quelli amministrativi.

Per gli utenti del progetto upstream, la versione corretta è 26.7.2, rilasciata il 19 agosto 2026. Per i clienti Red Hat build of Keycloak, gli aggiornamenti indicati nelle fonti sono 26.4.15 e 26.6.6.

Per chi non può aggiornare immediatamente, Red Hat ha indicato una mitigazione temporanea molto netta: disattivare la funzione “Forgot password” in tutti i realm. Non è una soluzione definitiva, ma riduce l’esposizione fino all’aggiornamento.

Il denominatore comune: patch management e superficie esposta

Queste tre vicende mostrano un problema ricorrente nelle aziende: il rischio non nasce solo dalla falla, ma dall’insieme di tre fattori.

Il primo è la mancanza di inventario: molte organizzazioni non hanno una mappa aggiornata di quali servizi siano effettivamente pubblicati su Internet.

Il secondo è il ritardo negli aggiornamenti: WebLogic insegna che una patch disponibile da mesi può trasformarsi comunque in incidente, se non viene applicata.

Il terzo è la configurazione predefinita o permissiva: nel caso Gitea, la registrazione aperta può trasformare un vincolo teorico in un vettore pratico di attacco.

In termini manageriali, il punto è questo: non serve che tutti i dipendenti sbaglino qualcosa. Basta un solo servizio critico lasciato indietro.

Cosa significa per la tua azienda

Se sei una PMI o uno studio professionale con software interni, portali gestionali, sistemi di autenticazione centralizzata o repository di sviluppo, le azioni prioritarie sono concrete.

1. Verifica subito se usi Gitea, WebLogic o Keycloak, direttamente o tramite fornitori software. In molte aziende questi componenti non sono “visibili” agli uffici, ma sono presenti dentro applicazioni affidate a terzi.

2. Controlla le versioni installate e confrontale con quelle corrette indicate dai produttori: Gitea 1.27.1, Keycloak 26.7.2, RHBK 26.4.15 o 26.6.6. Per Oracle WebLogic e Oracle HTTP Server verifica che siano state applicate le patch rilasciate a gennaio 2026.

3. Riduci l’esposizione immediata dove non puoi aggiornare in giornata. Per esempio, su Gitea verifica se la registrazione aperta sia davvero necessaria; su Keycloak valuta la disattivazione temporanea del recupero password; su WebLogic limita l’accesso di rete ai soli soggetti che ne hanno bisogno.

4. Monitora i segnali anomali: picchi di CPU, processi sconosciuti, traffico inatteso, modifiche ai dati o accessi irregolari possono essere l’unico indizio di compromissione già avvenuta.

5. Prepara un piano di ripristino. Se un server viene compromesso, avere copie integre e verificabili fa la differenza tra un fermo contenuto e una crisi operativa. In questo contesto sono utili soluzioni di backup remoto e una revisione più ampia della sicurezza informatica.

6. Formalizza la manutenzione dei server critici. Molte PMI non hanno un processo costante di patching, verifica e hardening. Un servizio di gestione continuativa o un contratto di assistenza informatica aiuta a evitare che gli aggiornamenti dipendano dall’urgenza del momento.

La raccomandazione più importante è non trattare queste notizie come temi “da reparto IT”. Se uno di questi sistemi supporta autenticazione, applicazioni aziendali o repository di sviluppo, l’impatto potenziale è business-critical.

Domande frequenti

Se non uso direttamente questi software, posso ignorare la notizia?

No. Potrebbero essere presenti dentro applicazioni gestite da un fornitore, da una software house o da un hosting provider. Conviene chiedere una verifica esplicita.

Gitea e Keycloak sono open source: significa che sono meno sicuri?

No. Il problema non è il modello open source in sé, ma la velocità con cui si applicano patch, si controllano le configurazioni e si riduce l’esposizione.

Qual è la priorità più urgente oggi?

Identificare se i sistemi sono presenti nel tuo ambiente e verificare subito patch e configurazioni. Per Gitea e WebLogic il rischio è più alto perché risultano già oggetto di sfruttamento attivo.