SICUREZZA

Apache Struts: quattro vulnerabilità, aggiornare a 7.4.0 o 6.12.0

Quattro vulnerabilità in Apache Struts richiedono verifica di mapper, allowlist OGNL, REST plugin e messaggi localizzati: versioni corrette e checklist operativa.

Gateway applicativo Apache Struts protetto da controlli su espressioni e richieste REST
Indice dell'articolo

Rischio e azione: Apache ha pubblicato quattro bollettini di sicurezza per Struts. Il caso più grave può consentire l’iniezione OGNL e la possibile esecuzione di codice quando un’applicazione usa il mapper RESTful legacy; gli altri problemi riguardano denial of service e possibile esposizione di dati. Inventariate subito versioni e componenti, verificate le precondizioni e aggiornate a Struts 7.4.0 o, per il ramo 6.x, a 6.12.0.

Quali applicazioni richiedono priorità

Il bollettino S2-075, associato a CVE-2026-104711, riguarda le applicazioni configurate con il mapper RESTful legacy. I rami 2.0-2.3.37, 2.5-2.5.33, 6.0-6.11.0 e 7.0-7.3.0 rientrano nell’intervallo interessato; per Struts 7 la condizione richiede anche che la allowlist OGNL sia stata disabilitata, mentre è attiva per impostazione predefinita.

Questo dettaglio è essenziale per evitare sia sottovalutazioni sia falsi allarmi. La sola presenza di Struts non dimostra che l’applicazione sia sfruttabile: servono il componente e la configurazione indicati. Al contrario, un’applicazione legacy raggiungibile da Internet con quelle condizioni va trattata come priorità elevata, anche se non esistono ancora indicatori interni.

Gli altri tre bollettini

S2-076, CVE-2026-104712, riguarda il binding di parametri verso proprietà java.math.BigDecimal e la successiva visualizzazione tramite tag Struts: input appositamente costruiti possono produrre risposte sproporzionate e consumare risorse. S2-077, CVE-2026-104713, interessa il plugin REST opzionale: il corpo della richiesta viene letto in memoria senza un limite, con rischio di esaurimento dell’heap e indisponibilità del servizio.

La correzione introduce per il plugin REST un limite predefinito di 2 MB. Le applicazioni che accettano payload più grandi devono impostare consapevolmente struts.rest.content.maxLength e mantenere un limite finito. Chi non può aggiornare subito deve applicare una soglia sul reverse proxy o sul servlet container.

S2-078, CVE-2026-104714, coinvolge messaggi localizzati che formattano data o ora. Richieste concorrenti possono interferire e mostrare a un utente un valore appartenente a un’altra risposta oppure generare errori. Le applicazioni che non formattano date o orari nei propri message bundle non soddisfano questa precondizione.

Prerequisiti e limiti

L’upgrade non va applicato alla cieca. Struts 7 richiede Java 17 e Jakarta EE; il ramo 6.x resta la linea compatibile con ambienti basati su Servlet API 3.1, JSP 2.1 e Java 8. Prima della finestra occorre quindi mappare runtime, dipendenze, plugin, mapper, test automatici e procedure di rollback.

Un limite al body sul proxy riduce il rischio specifico di S2-077 ma non corregge l’iniezione OGNL, la gestione di BigDecimal o il formatter concorrente. Allo stesso modo, disabilitare un endpoint pubblico può essere una mitigazione temporanea, non un sostituto della versione corretta.

Patching e incident response

Questi bollettini descrivono condizioni di vulnerabilità, non provano una compromissione. Se trovate endpoint anomali, errori OGNL, picchi di heap, risposte eccezionalmente grandi, processi figli inattesi o modifiche non autorizzate, preservate log applicativi, access log, configurazione e artefatti prima del riavvio. In quel caso serve incident response; l’aggiornamento chiude l’esposizione futura ma non rimuove eventuale persistenza.

Checklist operativa

  1. Inventariare applicazioni, versione Struts, Java, container e owner.
  2. Verificare mapper RESTful legacy e stato della allowlist OGNL.
  3. Individuare REST plugin, endpoint e limiti correnti del request body.
  4. Cercare binding BigDecimal e messaggi localizzati con date o orari.
  5. Salvare configurazioni, log e piano di rollback.
  6. Aggiornare a 7.4.0 o 6.12.0 secondo il runtime supportato.
  7. Testare autenticazione, routing, API REST, upload, localizzazione e carico.
  8. Controllare errori e anomalie precedenti; aprire un incidente se convergono.
  9. Documentare sistemi esclusi, mitigazioni temporanee e data di riesame.

Devi aggiornare applicazioni Java senza interrompere i servizi? Richiedi una verifica tecnica a MSP In Cloud.

Fonti primarie