ACS 1.1.9.14: perché questo aggiornamento non è rimandabile

Ad agosto 2026 è uscito IBM i Access Client Solutions 1.1.9.14. Non è un aggiornamento di funzioni: è un aggiornamento di sicurezza, e corregge sei vulnerabilità.

CVE-2026-13094 · CVE-2026-13105 · CVE-2026-13433 · CVE-2026-14866 · CVE-2026-14875 · CVE-2026-16695

Che cosa era esposto

Le versioni precedenti sono vulnerabili a un insieme di problemi che meritano di essere letti uno per uno, perché descrivono scenari diversi:

• Esecuzione di codice arbitrario su Windows quando ACS è installato per tutti gli utenti: la directory e il file di configurazione risultano scrivibili da chiunque usi la macchina.
• Iniezione di una certification authority fasulla, perché il truststore è scrivibile. Tradotto: qualcuno può far accettare ad ACS un certificato che non dovrebbe accettare.
• Zip slip (attraversamento di percorsi) nell'importazione di una configurazione. Un file di configurazione ricevuto da qualcuno può scrivere fuori dalla cartella prevista.
• Le versioni dalla 1.1.8.3 alla 1.1.9.13 scaricano codice non verificato quando sono configurate per aggiornarsi da un IBM i.
• Gli script di esempio in Documentation\Sample_Scripts\Linux_Mac_Other eseguono codice arbitrario con parametri costruiti ad arte.

Il quarto punto è quello da guardare due volte

Aggiornare ACS da una cartella condivisa sull'IBM i è la configurazione che si consiglia normalmente, ed è quella che quasi tutte le installazioni ordinate hanno: si mette il pacchetto in un punto solo, i client se lo prendono da lì, nessuno gira per gli uffici con una chiavetta.

È anche il percorso che, dalla 1.1.8.3 alla 1.1.9.13, non verifica quello che scarica.

Vuol dire che chi ha fatto la cosa giusta, centralizzare la distribuzione, ha la finestra aperta, e chi aggiorna a mano un client per volta ce l'ha chiusa: la configurazione consigliata è quella esposta.

Come si scopre quale versione hanno i client

Dentro ACS: Guida → Informazioni su.

Per una flotta il dato utile è il file AcsConfig.properties sui client, oppure, se la distribuzione è centralizzata, la versione del pacchetto nella cartella da cui tutti attingono, che è il posto da sistemare per primo: finché lì c'è una 1.1.9.13, ogni client che si aggiorna continua a prendere la versione vulnerabile.

Che cosa fare, in ordine

1. Sostituire il pacchetto nella cartella di distribuzione con la 1.1.9.14. Va per primo: è la sorgente da cui gli altri client si servono.
2. Aggiornare i client. Quelli configurati per aggiornarsi da soli prenderanno la versione nuova al primo avvio utile.
3. Controllare i permessi della cartella di installazione sui Windows dove ACS è installato per tutti gli utenti: se sono scrivibili da chiunque, il problema resta anche a versione aggiornata, perché è la macchina a essere configurata male.
4. Buttare gli script di esempio se non li usi. Sono in Documentation\Sample_Scripts\.

Esempio: il censimento prima dell'aggiornamento

Il problema di ACS non è aggiornarlo, è sapere chi ha quale versione. Il client sta sulle postazioni, non sul sistema, e nessuno lo aggiorna da solo.

Il giro che funziona è questo.

Chiedi al sistema chi si è collegato di recente. Le connessioni dei client passano dai server host, quindi lasciano traccia: profilo e provenienza si leggono con NETSTAT OPTION(*CNN) mentre sono attive, oppure, se il giornale di audit è acceso, con SYSTOOLS.AUDIT_JOURNAL_PW, che è la strada descritta in accendere il giornale di audit.

Da lì esce un elenco di postazioni, non di persone. È quello che serve: l'aggiornamento si fa per postazione.

Su ciascuna, la versione si legge da ACS, in Guida → Informazioni su. Chi ha una 1.1.9.x precedente rientra nell'aggiornamento.

Il conto che quasi sempre sorprende è la differenza fra i profili censiti e le postazioni trovate: le seconde sono di più, perché lo stesso profilo viene usato da più macchine; ed è esattamente il motivo per cui l'elenco va costruito e non ricordato.

Che cosa portava la versione precedente

La 1.1.9.13 è quella distribuita insieme al Technology Refresh di luglio 2026. Portava il supporto al SQL Error Logging Facility (SELF) dentro Run SQL Scripts e nuovi esempi SQL orientati alla misurazione della sicurezza del sistema. Sono aggiunte utili, e restano tutte nella 1.1.9.14: aggiornare non toglie niente.

Da non confondere. Esiste un bollettino separato e precedente, CVE-2026-7770, che riguarda l'esecuzione di codice da remoto quando ACS è configurato per ricevere richieste da IBM i Navigator. È un'altra cosa rispetto alle sei di questa versione.

Su quali versioni funziona

Riguarda ACS come programma client, su Windows, Linux e macOS, a prescindere dal rilascio di IBM i a cui si collega. La vulnerabilità dell'aggiornamento da IBM i riguarda le versioni dalla 1.1.8.3 alla 1.1.9.13 comprese.

Fonti

• IBM Community — ACS 1.1.9.14 is released — elenco delle CVE corrette
• IBM i Access — ACS Updates — pagina ufficiale dei download
• Security Bulletin CVE-2026-7770