SICUREZZA

BeyondTrust Remote Support: zero-day sfruttata, patch e triage

CVE-2026-102764 colpisce BeyondTrust Remote Support self-hosted fino alla 26.2.3. Come verificare esposizione, applicare BT26-05-RS e separare patching e incident response.

BeyondTrust Remote Support protetto dalla patch per CVE-2026-102764 con percorso di contenimento e triage
Indice dell'articolo

Rischio e azione: BeyondTrust ha corretto CVE-2026-102764, vulnerabilità critica di Remote Support che può consentire a un attaccante remoto non autenticato di eseguire operazioni sui file dell’appliance. Le installazioni SaaS sono già state aggiornate dal fornitore; chi gestisce Remote Support self-hosted fino alla versione 26.2.3 deve verificare subito il canale di aggiornamento, applicare la patch BT26-05-RS e trattare le appliance esposte come sistemi privilegiati da sottoporre a triage.

Quali sistemi sono coinvolti

L’advisory riguarda BeyondTrust Remote Support in tutte le versioni fino alla 26.2.3. Il difetto è nell’origine dei messaggi ricevuti da componenti interni: in condizioni favorevoli può essere sfruttato per operazioni sui file. Il punteggio CVSS v4 dichiarato è 9,3 e il vettore non richiede privilegi né interazione dell’utente.

La distinzione operativa è tra SaaS e self-hosted. BeyondTrust dichiara di avere distribuito la correzione a tutti i clienti SaaS il 9 ottobre 2026. Per le appliance autogestite, la patch BT26-05-RS è disponibile per le versioni dalla 24.3.1 alla 26.2.3. Un’installazione precedente alla 24.3.1 deve prima essere portata a una versione compatibile: non basta cercare la patch senza verificare la release di partenza.

Inventario e prerequisiti prima della patch

Individuare ogni appliance, nodo secondario, ambiente di disaster recovery e accesso amministrativo pubblicato. Registrare versione, modalità di aggiornamento, esposizione Internet, ultima configurazione salvata e destinazione dei log. Verificare nell’interfaccia /appliance se gli aggiornamenti automatici sono attivi e se la patch risulta già applicata; la sola presenza di una release 26.x non prova la correzione.

Prima dell’intervento esportare la configurazione secondo la procedura del fornitore, preservare i log e annotare gli hash degli artefatti acquisiti. Se l’appliance gestisce sessioni privilegiate verso server, workstation o apparati di rete, identificare anche le credenziali, i token e le chiavi raggiungibili dal prodotto. Questo passaggio serve a definire il possibile raggio d’azione, non a rinviare l’aggiornamento.

Concordare inoltre una finestra breve ma esplicita con chi gestisce help desk e assistenza: sospendere nuove sessioni durante il cambio, notificare gli operatori, verificare le integrazioni di autenticazione e predisporre un percorso alternativo per gli interventi urgenti. Continuità e sicurezza devono essere validate insieme.

Patching e risposta all’incidente sono attività diverse

L’applicazione della patch chiude il percorso vulnerabile, ma non dimostra che il sistema fosse integro prima dell’aggiornamento. L’inserimento nel catalogo Known Exploited Vulnerabilities di CISA rende necessario separare due flussi: aggiornare il prodotto e verificare eventuali segni di accesso precedente.

Per il triage conservare log dell’appliance, reverse proxy, firewall, DNS, autenticazione e sistemi gestiti. Cercare modifiche inattese, account o chiavi nuovi, file anomali, sessioni amministrative fuori orario e connessioni verso destinazioni non previste. Se emergono indicatori, isolare l’accesso amministrativo senza distruggere le evidenze, coinvolgere il supporto BeyondTrust e avviare la rotazione graduata dei segreti potenzialmente raggiungibili. Ripristinare da un backup non verificato o importare alla cieca una vecchia configurazione può reintrodurre persistenza.

Checklist verificabile

  1. Inventariare tutte le appliance Remote Support, incluse DR e istanze non più presidiate.
  2. Distinguere SaaS e self-hosted e registrare versione, esposizione e stato degli aggiornamenti.
  3. Per release anteriori alla 24.3.1 pianificare prima l’upgrade a una versione supportata.
  4. Preservare configurazione e log locali ed esterni prima di modificare il sistema.
  5. Applicare BT26-05-RS alle versioni dalla 24.3.1 alla 26.2.3.
  6. Verificare il livello patch dopo l’installazione e provare accesso amministrativo e una sessione remota controllata.
  7. Correlare i log per accessi, file e sessioni anomali nel periodo precedente alla correzione.
  8. In caso di indicatori, attivare incident response, contenimento e rotazione dei segreti secondo il perimetro reale.
  9. Documentare esito, orario, responsabile, rollback e prova funzionale conclusiva.

Devi aggiornare un sistema di accesso remoto privilegiato senza interrompere l’operatività? Richiedi una verifica tecnica a MSP In Cloud.

Fonti primarie