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à.

Aggiornamento di ottobre 2026. Dopo la 1.1.9.14 sono uscite la 1.1.9.15 (agosto) e la 1.1.9.16 (settembre), che corregge altre tre vulnerabilità: STRPCCMD mandato da un IBM i compromesso, le macro dell'emulatore con l'azione RunProgram e i file di sessioni multiple con l'azione Run ora chiedono conferma. IBM scrive che le correzioni si danno solo per la versione corrente: si installa l'ultima, che contiene anche tutto quello che segue.

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. Va bene per una macchina, non per quaranta.

Se la distribuzione è centralizzata, il dato utile è la versione del pacchetto nella cartella da cui tutti attingono, che è il posto da sistemare per primo: finché lì c'è una versione vecchia, ogni client che si aggiorna continua a prendere quella.

Che cosa fare, in ordine

1. Sostituire il pacchetto nella cartella di distribuzione con la versione corrente. 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 è collegato. Le connessioni dei client passano dai server host, e mentre sono attive indirizzo e porta si leggono con NETSTAT OPTION(*CNN). Ripetuto in momenti diversi della giornata, dà l'elenco delle postazioni che usano ACS. Il giornale di audit non sostituisce questo passo: AUDIT_JOURNAL_PW registra le password sbagliate, non i collegamenti riusciti.

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 non ha la versione corrente rientra nell'aggiornamento.

La versione precedente

La 1.1.9.13 è di maggio 2026, e IBM la elenca fra le novità del 7.6 TR2: porta in Run SQL Scripts il supporto a SELF (SQL Error Logging Facility) e nuovi esempi. Tutto resta nelle versioni successive: aggiornare non toglie niente. Correggeva anche tre vulnerabilità, fra cui CVE-2026-7770: le versioni dalla 1.1.5.0 alla 1.1.9.12 eseguivano codice da remoto quando erano configurate per ricevere richieste da IBM i Navigator.

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
• IBM: IBM i 7.6 TR2 Enhancements