Spcnet.it

2026-06-09 07:36:06

WSL Container: i contenitori Linux nativi su Windows senza Docker Desktop

Al Microsoft Build 2026, Microsoft ha annunciato WSL Container, una nuova funzionalità integrata nel Windows Subsystem for Linux (WSL) che consente di eseguire container Linux OCI-compatibili direttamente su Windows, senza la necessità di installare Docker Desktop o altri strumenti di terze parti.

Si tratta di un cambiamento significativo per sviluppatori e amministratori di sistema che lavorano in ambienti misti Windows/Linux, e che fino ad oggi dovevano fare affidamento su Docker Desktop (a pagamento per le organizzazioni sopra una certa dimensione) o su soluzioni alternative più complesse.

Perché WSL Container cambia le regole del gioco

Eseguire container Linux su Windows è da sempre un’operazione che richiede un livello di indirezione: Docker Desktop, ad esempio, avvia una macchina virtuale Linux in background e su di essa esegue i container. Questo approccio funziona bene, ma porta con sé costi di licenza, overhead di configurazione e una gestione centralizzata separata dalla piattaforma Windows stessa.

WSL Container integra questo meccanismo direttamente nel sistema operativo, eliminando la dipendenza da software di terze parti. Il risultato è una pipeline di sviluppo e operativa più snella, completamente gestibile tramite strumenti nativi Windows.

Come funziona tecnicamente

WSL Container esegue i container OCI all’interno di una macchina virtuale Hyper-V dedicata, separata dalle distribuzioni Linux WSL 2 tradizionali. La comunicazione tra il processo Windows e la VM avviene tramite Hyper-V socket, un canale a bassa latenza ottimizzato per la comunicazione host-guest in ambienti virtualizzati.

La configurazione predefinita della VM prevede:

• 2 vCPU
• 2.000 MB di RAM
• 32 GB di disco virtuale ad espansione dinamica

Questi parametri sono personalizzabili tramite l’SDK C# esposto dal pacchetto NuGet ufficiale.

Il CLI: wslc.exe

Il nuovo strumento da riga di comando wslc.exe sarà distribuito con il prossimo aggiornamento stabile di WSL. Microsoft ha scelto deliberatamente una sintassi analoga a Docker, così chi già conosce Docker non deve imparare nulla di nuovo:

# Avvia un container interattivo e rimuovilo all'uscita
wslc run --rm -it ubuntu:latest bash -c "echo Ciao da WSL Container!"

# Elenca le immagini disponibili localmente
wslc image ls

# Avvia un web server nginx in background, esponendo la porta 8080
wslc run -it --rm -d -p 8080:80 --name webserver nginx

# Elenca i container in esecuzione
wslc container ps

# Ferma il container
wslc container stop webserver

# Accesso a registry privati
wslc registry login registry.example.com
wslc registry logout registry.example.com

La portabilità dei comandi rispetto a Docker è intenzionale: permette di adottare WSL Container senza riscrivere script o pipeline esistenti.

Modalità di rete supportate

WSL Container supporta tre modalità di rete a livello di VM:

• none: nessuna connettività di rete
• NAT: il traffico della VM viene tradotto attraverso la rete dell’host Windows
• virtio-proxy: interfaccia di rete paravirtualizzata, con traffico più diretto e minore overhead

A livello di singolo container, si può scegliere tra bridge, host, none oppure condividere il namespace di rete di un altro container. Il publish delle porte, al momento, inoltro solo connessioni TCP su localhost.

API per sviluppatori Windows

Per chi sviluppa applicazioni Windows, WSL Container espone un’API programmatica via NuGet che include:

• Una libreria C nativa (wslcsdk.dll)
• Una proiezione WinRT (la moderna superficie API di Windows)
• Bindings C# per integrazione .NET

Tramite l’API è possibile: scaricare immagini, creare e avviare container, gestire stdin/stdout, pubblicare porte, montare volumi e abilitare il pass-through GPU. Microsoft cita come scenari d’uso principali i workload AI locali, le pipeline di test e l’elaborazione basata su Linux, anche se i dettagli tecnici specifici sono ancora limitati data la fase di preview.

Controllo enterprise con Group Policy

Per gli ambienti aziendali, WSL Container introduce un’impostazione di Group Policy chiamata WSLContainerRegistryAllowlist. Questa policy limita i registry da cui gli utenti possono scaricare immagini: se un utente tenta di fare pull da un registry non in lista, l’operazione fallisce con l’errore WSLC_E_REGISTRY_BLOCKED_BY_POLICY.

La policy viene applicata a livello di servizio e vale sia per il CLI, sia per l’API, sia per eventuali plugin. Non è aggirabile chiamando l’SDK direttamente. Si tratta di un controllo importante per le organizzazioni che devono garantire la provenienza delle immagini container usate dai team di sviluppo.

Stato attuale e limitazioni

Come chiarito dalla documentazione Microsoft Learn, WSL Container è ancora in sviluppo attivo al momento della scrittura di questo articolo (giugno 2026). Non è ancora disponibile in una release stabile di WSL. Per seguire l’avanzamento del progetto, Microsoft rimanda al repository open-source microsoft/wsl su GitHub.

Tra le informazioni non ancora pubblicate: la versione minima di Windows richiesta, le specifiche di compatibilità hardware, e la roadmap per la disponibilità generale (GA).

Perché è rilevante per sistemisti e DevOps

L’integrazione nativa dei container Linux in Windows apre scenari interessanti:

• Riduzione dei costi di licenza: nessun Docker Desktop a pagamento per le organizzazioni grandi
• Gestione centralizzata via Group Policy: controllo degli allowlist di registry già nei tool di amministrazione esistenti
• Pipeline CI/CD semplificate: possibilità di eseguire container Linux in ambienti Windows senza dipendenze esterne
• Workload AI locali: esecuzione di modelli o pipeline ML su macchine Windows di sviluppo con pass-through GPU

Vale la pena monitorare l’evoluzione di questa funzionalità, specialmente per i team che lavorano su Windows e hanno bisogno di compatibilità con l’ecosistema container Linux.

---

Fonte: 4sysops – WSL container: Linux containers built into Windows | Microsoft Build 2026

WSL container: Linux containers built into Windows – 4sysops

WSL container is a new feature coming to the Windows Subsystem for Linux (WSL), announced at Microsoft Build 2026. It provides a built-in way to run OCI-compati

^{IT Experts (4sysops)}

Spcnet.it

2026-06-08 18:15:30

Miasma Worm: il supply chain attack che ha colpito 73 repository Microsoft su GitHub

Una campagna di attacco alla supply chain ha compromesso 73 repository Microsoft su GitHub, colpendo organizzazioni di alto profilo come Azure, Azure-Samples, Microsoft e MicrosoftDocs. Il responsabile è un worm auto-replicante denominato Miasma, variante del malware Mini Shai-Hulud rilasciato pubblicamente dal gruppo TeamPCP a metà maggio 2026.

L’incidente ha costretto GitHub a disabilitare l’accesso ai repository compromessi, tra cui alcuni di assoluta centralità nell’ecosistema Microsoft open source, come Azure/azure-functions-host e l’intera famiglia dei Durable Task SDK.

La catena di compromissione: dai pacchetti PyPI ai repository GitHub

Miasma non è una minaccia nuova: il worm ha già colpito in precedenza. Il mese prima di questo incidente, il pacchetto PyPI durabletask era stato infettato da TeamPCP per consegnare un information stealer su sistemi Linux. Il fatto che, un mese dopo, l’intero ecosistema Durable Task su GitHub sia stato compromesso — incluse le implementazioni .NET, Go, Java, JavaScript, MSSQL e Protobuf — non è una coincidenza.

Come ha osservato il ricercatore di sicurezza Paul McCarty (alias 6mile): “Quando il repository al centro dell’attacco del mese scorso diventa l’epicentro del takedown di questo mese, non è una coincidenza — è la stessa ferita che si riapre. Chi deteneva quelle credenziali a maggio non le ha probabilmente mai perso del tutto.”

Come funziona Miasma: sfruttare la fiducia, non le vulnerabilità

Quello che rende Miasma particolarmente pericoloso è il suo meccanismo di propagazione: il worm non sfrutta vulnerabilità tecniche nei registri npm o in GitHub. Sfrutta invece il modello di fiducia su cui si reggono questi ecosistemi.

Come sintetizza FalconFeeds.io: “Il genio del worm sta nel fatto che opera interamente attraverso canali legittimi. Non sfrutta una vulnerabilità in npm o GitHub. Sfrutta il modello di fiducia su cui queste piattaforme sono costruite: l’assunzione che se un pacchetto è firmato con una chiave valida e pubblicato da un maintainer autenticato, sia sicuro. Miasma compromette la chiave e il maintainer, poi agisce esattamente come farebbe un publisher legittimo.”

Da un punto di vista dei sistemi di difesa convenzionali, ogni evento di pubblicazione malevolo è indistinguibile da un aggiornamento ordinario.

Il vettore di attacco: gli agenti AI come trigger

Uno degli aspetti più innovativi — e preoccupanti — di Miasma è il suo vettore di detonazione. Secondo l’analisi di SafeDep, il worm ha piantato un payload runner da 4,3 MB nei repository infetti, configurato per attivarsi automaticamente attraverso cinque strumenti di sviluppo:

• Claude Code
• Gemini CLI
• Cursor
• VS Code
• Lo script npm test

In pratica: uno sviluppatore clona un repository infetto, lo apre nel suo agente AI preferito, e il payload si esegue automaticamente. Nessun click, nessuna interazione esplicita richiesta.

Questo segna un’evoluzione significativa nel panorama degli attacchi supply chain: gli agenti AI, progettati per eseguire codice in autonomia, diventano inconsapevolmente vettori di esecuzione per payload malevoli.

I repository Microsoft colpiti

Tra i repository compromessi e disabilitati da GitHub figurano:

• Azure/azure-functions-host
• Azure/durabletask
• durabletask-dotnet
• durabletask-go
• durabletask-js
• durabletask-mssql
• azure-search-openai-demo-purviewdatasecurity
• llm-fine-tuning
• windows-driver-docs
• Connectors-NET-SDK, Connectors-NET-LSP

Oltre ai repository Microsoft, Miasma ha saltato completamente il registro npm in alcuni casi, compromettendo direttamente il repository GitHub icflorescu/mantine-datatable e quattro repository correlati (mantine-contextmenu, next-server-actions-parallel, mantine-datatable-v6, mantine-contextmenu-v6).

Come difendersi dagli attacchi supply chain di questa generazione

La natura di Miasma — operare all’interno dei canali legittimi — rende i controlli tradizionali insufficienti. Ecco le misure pratiche che i team di sviluppo e i sistemisti dovrebbero adottare:

1. Lockfile e hash verification

Usare sempre lockfile (package-lock.json, poetry.lock, go.sum) e verificare gli hash dei pacchetti. Non fare mai npm install o pip install senza version pinning stretto su ambienti di produzione e CI.

2. Controllo delle permission degli agenti AI

Configurare gli agenti AI (VS Code, Cursor, Claude Code, Gemini CLI) in modo che non eseguano script automaticamente alla clonazione di un repository. Molti agenti hanno modalità di esecuzione permissiva abilitata di default: è necessario revisionare le impostazioni.

3. Ambienti sandbox per il codice sconosciuto

Prima di aprire repository esterni in un agente AI, eseguire un’ispezione manuale dei file package.json, pyproject.toml, script di lifecycle, e configurazioni degli agenti (.cursor/, .claude/, .vscode/). Meglio ancora: usare ambienti sandbox isolati (container, VM) per il primo accesso a codice di terze parti.

4. Monitoraggio delle dipendenze con tool come OpenSourceMalware e SafeDep

Strumenti come OpenSourceMalware e SafeDep monitorano attivamente l’ecosistema npm, PyPI e GitHub per rilevare comportamenti anomali nei pacchetti. Integrare questi feed nei processi di revisione delle dipendenze.

5. Principio del minimo privilegio per le credenziali di repository

La ricompaprsa delle stesse credenziali a distanza di un mese dimostra che il reset delle credenziali post-incidente spesso non è completo. Implementare credenziali rotate automaticamente, short-lived token (es. GitHub OIDC token in CI), e auditing degli accessi ai repository.

Il quadro più ampio: la minaccia ai modelli di sviluppo moderni

L’attacco Miasma evidenzia una tensione strutturale nell’ecosistema software moderno: la velocità e l’apertura che rendono l’open source produttivo sono le stesse caratteristiche che lo rendono vulnerabile a questa classe di attacchi. I worm supply chain che operano “dentro le regole” sono una categoria di minaccia che crescerà, soprattutto con la diffusione degli agenti AI come strumenti di sviluppo quotidiani.

Per i team di sviluppo e i sistemisti, il messaggio è chiaro: i controlli di sicurezza devono evolvere oltre la verifica dell’autenticità formale dei pacchetti, verso un’analisi comportamentale dei contenuti e una gestione più granulare delle permission degli strumenti di sviluppo.

---

Fonte: 4sysops – Miasma worm compromises 73 Microsoft GitHub repositories | The Hacker News – Miasma Worm Hits 73 Microsoft GitHub Repositories

Miasma worm compromises 73 Microsoft GitHub repositories in supply chain attack – 4sysops

A self-replicating worm named Miasma has successfully compromised 73 Microsoft GitHub repositories across several organizations, including Azure and MicrosoftDo

^{IT News (4sysops)}

Spcnet.it

2026-06-08 18:15:02

VS Code 1.124: cronologia chat per sessione, multi-chat e regex flag per i folding marker

Visual Studio Code 1.124 è disponibile dal 4 giugno 2026 e porta con sé miglioramenti significativi alla finestra Agenti, novità sul controllo dei folding marker e altri raffinamenti per il workflow di sviluppo. Ecco una panoramica tecnica delle novità più rilevanti.

Finestra Agenti: storico chat contestuale per sessione

Fino alla versione precedente, la navigazione cronologica dei prompt nella finestra Agenti (tasto ↑ / ↓ nell’input della chat) includeva prompt provenienti da sessioni diverse. Questo comportamento poteva far trapelare contesti di lavoro non pertinenti all’attività corrente.

Con VS Code 1.124, la cronologia dei prompt è ora limitata alla sessione corrente. Navigare la cronologia con i tasti freccia restituisce solo i comandi digitati nella stessa sessione attiva, evitando contaminazioni di contesto tra task distinti. Un miglioramento apparentemente piccolo, ma apprezzabile nei workflow che prevedono sessioni parallele o rapide rotazioni di contesto.

Multi-chat e invio in background

La versione 1.124 introduce il supporto multi-chat per le sessioni locali: è ora possibile tenere aperte più conversazioni indipendenti nella finestra Agenti senza dover gestire tutto in un’unica thread lineare.

Altrettanto utile è il nuovo invio in background (background send). Con Alt+Invio oppure Alt+clic sul pulsante Send, si avvia una sessione agente senza che il focus venga spostato su di essa. Il vantaggio pratico: si può lanciare un’attività lunga e iniziare immediatamente a comporre il messaggio successivo nella sessione successiva, senza interruzioni del flusso.

Navigazione da tastiera e chiusura massiva delle sessioni

La griglia delle sessioni nella finestra Agenti ora supporta la navigazione da tastiera:

• Ctrl+1 – Ctrl+9 (oppure Cmd+1 – Cmd+9 su macOS) per portare il focus sulla sessione nella posizione corrispondente.
• Ctrl+K Ctrl+W (Cmd+K Cmd+W su Mac) per chiudere tutte le sessioni attive in una sola operazione.

Chi lavora con più agenti in esecuzione simultanea troverà queste scorciatoie particolarmente utili per tenere sotto controllo lo spazio di lavoro senza dover ricorrere al mouse.

Regex flags per i folding marker

Un aggiornamento più tecnico riguarda la configurazione dei folding marker nei file di definizione del linguaggio (language-configuration.json). In precedenza, i pattern di apertura e chiusura dei blocchi di codice piegabili accettavano solo stringhe regex semplici.

Con VS Code 1.124, i pattern supportano ora un formato a oggetto che permette di specificare flag aggiuntivi, come la corrispondenza case-insensitive:

{
  "folding": {
    "markers": {
      "start": { "pattern": "#region", "flags": "i" },
      "end":   { "pattern": "#endregion", "flags": "i" }
    }
  }
}

Questo permette ai maintainer di estensioni linguistiche di definire regole di folding più granulari e flessibili, utili ad esempio per linguaggi che non rispettano convenzioni di case uniformi.

Come aggiornare

L’aggiornamento a VS Code 1.124 avviene automaticamente per chi ha attivato gli aggiornamenti automatici. In alternativa, è possibile aggiornare manualmente tramite Aiuto → Controlla aggiornamenti oppure scaricando l’installer dal sito ufficiale.

Per chi usa VS Code Insiders, le stesse funzionalità erano già disponibili nelle build di maggio-giugno 2026 con la possibilità di testarle in anticipo.

Considerazioni finali

VS Code 1.124 non è una release rivoluzionaria, ma dimostra come Microsoft stia raffinando sistematicamente l’esperienza degli agenti AI integrati nell’editor. La contestualizzazione della cronologia chat, il supporto multi-sessione e le scorciatoie di navigazione sono dettagli che, sommati, riducono il friction quotidiano per chi lavora intensamente con GitHub Copilot o altri agenti AI nel proprio workflow.

Il miglioramento ai folding marker è invece un regalo apprezzato per chi sviluppa o mantiene estensioni per linguaggi personalizzati o poco comuni.

---

Fonte: VS Code 1.124 Release Notes · 4sysops

Visual Studio Code 1.124 enhances agent chat and folding markers – 4sysops

Visual Studio Code version 1.124 introduces significant improvements to the Agents window for managing AI-driven interactions. The chat input history is now sco

^{IT News (4sysops)}

Spcnet.it

2026-06-08 18:14:43

PHP-FPM: perché usare pm static per le massime prestazioni in produzione

Chi amministra server Linux con stack LEMP o LAMP sa bene che le prestazioni di PHP-FPM dipendono in larga misura dalla corretta configurazione del process manager (PM). L’impostazione predefinita pm = dynamic va bene per molti scenari, ma su server ad alto traffico con memoria disponibile può diventare un collo di bottiglia. Vediamo perché pm = static è spesso la scelta migliore per la produzione.

Le tre modalità di PHP-FPM process manager

PHP-FPM offre tre strategie per gestire i processi worker:

pm = dynamic

Il numero di processi varia dinamicamente in base ai parametri:

pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35

PHP-FPM mantiene un pool variabile: avvia un certo numero di processi al boot, ne crea di nuovi sotto carico e termina quelli in eccesso in fase di inattività. È la modalità più flessibile ma anche quella con più overhead gestionale.

pm = ondemand

pm = ondemand
pm.max_children = 50
pm.process_idle_timeout = 10s

I processi vengono creati solo quando arrivano le richieste e terminati dopo un timeout di inattività. Ideale quando la memoria è scarsa o si gestiscono molti pool con traffico basso (tipicamente hosting condiviso con cPanel). Il limite è che su server con traffico intermittente ma costante, i processi vengono continuamente creati e distrutti, aggiungendo latenza esattamente nei momenti di picco.

pm = static

pm = static
pm.max_children = 100
pm.max_requests = 1000

Il numero di processi è fisso: pm.max_children worker vengono avviati al boot e restano sempre in memoria, pronti a rispondere. Non c’è overhead di creazione/terminazione dei processi.

L’analogia con il CPU governor

La scelta tra le tre modalità rispecchia esattamente quella del governor CPUFreq su Linux:

• ondemand (CPU): scala la frequenza in base al carico, poi scende — stessa logica di pm ondemand
• conservative (CPU): simile ma più graduale — analogo a pm dynamic
• performance (CPU): massima frequenza sempre — equivalente a pm static

Su un server di produzione dedicato con carico consistente, proprio come si imposta il governor a performance, ha senso impostare PHP-FPM a static: si sacrifica un po’ di memoria per azzerare la latenza di spawn dei processi.

Quando usare pm static

pm = static è la scelta giusta quando:

• Il server ha memoria abbondante rispetto al traffico atteso
• Il carico è costante o con picchi frequenti (non siti dormenti)
• Si gestisce un singolo pool PHP-FPM per applicazione
• Si vuole la latenza minima possibile per ogni richiesta

Con i worker già in memoria, un picco di traffico improvviso viene assorbito senza dover attendere lo spawn di nuovi processi — che su sistemi sotto carico può richiedere decine di millisecondi.

Calcolare il valore corretto di pm.max_children

Impostare pm.max_children a caso è il classico errore. Troppo alto esaurisce la RAM, troppo basso crea code di attesa. Ecco come calcolarlo con dati reali.

Step 1: misurare la dimensione media di un worker

ps --no-headers -o rss -C php-fpm | awk '{ sum += $1; n++ } END { print sum/n/1024 " MB" }'

Questo comando mostra la dimensione media in MB del Resident Set Size (RSS) di ogni processo php-fpm in esecuzione. Eseguirlo sotto carico reale, non a server scarico.

Step 2: applicare la formula

pm.max_children = memoria_allocabile_MB / dimensione_media_worker_MB

Esempio concreto: se il worker medio pesa 60 MB e si possono allocare 6 GB a PHP-FPM:

pm.max_children = 6144 / 60 ≈ 100

Importante: non assegnare tutta la RAM disponibile a PHP-FPM. Lasciare sempre headroom per il kernel, Nginx/Apache, il database (MySQL/PostgreSQL) e la cache del filesystem. Una regola empirica è non superare il 60-70% della RAM totale per PHP-FPM su un server LEMP monolitico.

Step 3: impostare pm.max_requests

pm.max_requests = 1000

Con pm = static, i processi non vengono mai riavviati automaticamente per inattività. pm.max_requests definisce dopo quante richieste un worker viene riavviato — utile per prevenire memory leak in applicazioni PHP non perfette. Un valore alto (1000+) riduce l’overhead mantenendo una certa protezione. Solo se si ha certezza assoluta di assenza di leak si può usare pm.max_requests = 0.

Monitoraggio dei processi PHP-FPM

Per verificare il comportamento in produzione:

# Vedere tutti i processi PHP-FPM con CPU e memoria
top -bn1 | grep php-fpm

# Contare i worker attivi vs idle (richiede pm.status_path abilitato)
curl http://localhost/fpm-status

# Dimensione totale RSS usata da PHP-FPM
ps --no-headers -o rss -C php-fpm | awk '{ sum += $1 } END { print sum/1024 " MB totali" }'

Abilitare il status page di PHP-FPM nel pool configuration è fondamentale per il monitoring:

; in /etc/php/8.x/fpm/pool.d/www.conf
pm.status_path = /fpm-status

Quando ondemand e dynamic restano la scelta giusta

Non tutto è nero o bianco. pm ondemand e pm dynamic restano preferibili in questi scenari:

• Hosting condiviso con 100+ pool: con tanti siti a traffico basso, tenere worker statici per ogni pool divorberebbe la RAM. cPanel stessa usa ondemand come default per questo motivo.
• Server con memoria limitata: se la RAM è il collo di bottiglia, meglio sacrificare un po’ di latenza che andare in swap.
• Ambienti containerizzati con autoscaling orizzontale: in un setup Kubernetes dove i pod scalano orizzontalmente, ha più senso un pm ondemand con confini ben definiti per container, lasciando che l’orchestratore gestisca il scaling.

Esempio di configurazione ottimale per server ad alto traffico

[www]
user = www-data
group = www-data

listen = /run/php/php8.3-fpm.sock
listen.owner = www-data
listen.group = www-data

pm = static
pm.max_children = 80
pm.max_requests = 2000

pm.status_path = /fpm-status

request_terminate_timeout = 60s
request_slowlog_timeout = 10s
slowlog = /var/log/php/fpm-slow.log

php_admin_value[error_log] = /var/log/php/fpm-error.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 256M

Conclusione

Su server dedicati ad alto traffico con memoria disponibile, pm = static è quasi sempre la configurazione vincente. Elimina l’overhead del process manager, garantisce latenza costante e rende il comportamento del sistema prevedibile sotto carico. La chiave è misurare prima di configurare: il valore di pm.max_children deve essere basato sulla dimensione reale dei worker in produzione, non su stime.

Per ambienti multi-pool o con memoria limitata, ondemand rimane una scelta sensata. Ma per il classico server LEMP di produzione con una singola applicazione, passare a pm static è spesso uno dei miglioramenti più semplici e impattanti che si possano fare.

---

Fonte originale: PHP-FPM tuning: Using ‘pm static’ for max performance — LinuxBlog.io

PHP-FPM tuning: Using 'pm static' for max performance | LinuxBlog.io

Let's take a quick look at how best to set up PHP-FPM for high throughput, low latency, and more stable CPU and memory use. By default, most setups have

^{Hayden James (LinuxBlog.io)}

Spcnet.it

2026-06-08 18:15:22

NuGet Package Pruning in .NET 10: dipendenze più pulite e meno falsi positivi di vulnerabilità

Se hai mai eseguito dotnet list package --vulnerable su un progetto .NET, probabilmente hai visto avvisi per pacchetti transitivi che non hai mai installato esplicitamente — come System.Text.Json o System.Formats.Asn1. In molti casi, questi pacchetti sono già forniti in una versione più recente dal runtime .NET, e gli avvisi sono falsi positivi. Con .NET 10, NuGet risolve questo problema in modo elegante: il package pruning.

Il problema: dipendenze transitorie fantasma

Molte librerie su NuGet.org hanno come target netstandard2.0 per massima compatibilità, e portano con sé dipendenze da pacchetti come System.Memory, System.Text.Json o System.IO.Pipelines — pacchetti che nel frattempo sono diventati parte delle .NET Runtime Libraries.

Il risultato pratico: un progetto .NET 10 che dipende da una di queste librerie si trova a risolvere durante il restore System.Text.Json 8.0.0 come dipendenza transitiva, anche se il runtime .NET 10 già include una versione più recente. Quando viene pubblicata una CVE contro quella versione, i vulnerability scanner la segnalano — anche se la tua applicazione non la usa affatto.

Questo genera tre problemi concreti:

• Falsi positivi nelle vulnerability scan: avvisi per pacchetti già coperti dal runtime
• Grafi di restore più grandi: più pacchetti da risolvere e scaricare
• Riferimenti obsoleti: entry vecchie nel dependency graph che non rispecchiano cosa usa davvero l’app

Come funziona il Package Pruning

Il package pruning rimuove dal grafo di dipendenze NuGet i pacchetti già forniti dalle .NET Runtime Libraries al momento del restore. Il .NET SDK include una lista dei pacchetti forniti da ciascun target framework, con la versione massima disponibile. Se una dipendenza transitiva rientra in quel range, NuGet la elimina.

Ad esempio, net10.0 include System.Text.Json 10.x: una dipendenza transitiva su System.Text.Json 9.0.0 verrebbe pruned; una su System.Text.Json 11.0.0 no (perché il runtime non copre quella versione).

Prima del pruning

Sample.csproj : warning NU1903: Package 'System.Formats.Asn1' 6.0.0 has a
known high severity vulnerability

Project 'Sample' has the following package references
   [net10.0]:
   Top-level Package              Resolved
   > Microsoft.Extensions.AI      10.0.1
   > NuGet.Protocol               6.9.1

   Transitive Package                                     Resolved
   > System.Diagnostics.DiagnosticSource                  10.0.0
   > System.Formats.Asn1                                  6.0.0   ← VULNERABILE
   > System.Text.Json                                     10.0.0
   > System.Threading.Channels                            10.0.0
   ...

Dopo il pruning

Project 'Sample' has the following package references
   [net10.0]:
   Top-level Package              Resolved
   > Microsoft.Extensions.AI      10.0.1
   > NuGet.Protocol               6.9.1

   Transitive Package                                     Resolved
   > Microsoft.Extensions.AI.Abstractions                 10.0.1
   > Newtonsoft.Json                                      13.0.3
   > NuGet.Common                                         6.9.1
   ...
   (System.Formats.Asn1, System.Text.Json, System.Threading.Channels rimossi)

System.Formats.Asn1, System.Text.Json e System.Threading.Channels non compaiono più come dipendenze transitorie perché sono ridondanti su net10.0. L’avviso di vulnerabilità scompare.

Le novità in .NET 10

Il package pruning era disponibile come opt-in dal .NET SDK 9.0.200. Con .NET 10 diventa il comportamento predefinito per i progetti che hanno come target net10.0 o versioni successive.

In parallelo, NuGetAuditMode ora vale all per default, estendendo l’audit alle dipendenze transitorie. Pruning e audit lavorano insieme: il pruning rimuove i pacchetti ridondanti, l’audit si concentra sulle dipendenze che la tua app usa davvero.

I risultati misurati dal team NuGet:

• 70% di report di vulnerabilità transitorie in meno rispetto ai default precedenti
• Fino al 50% di riduzione del tempo di restore a livello di singolo progetto
• Tasso di successo del restore misurabilmente più alto

Gestione dei PackageReference diretti

Se hai un riferimento diretto a un pacchetto che rientra nel range del pruning, NuGet non lo rimuove automaticamente dal tuo .csproj, ma lo “privatizza” aggiungendo implicitamente PrivateAssets='all' e IncludeAssets='none'. Quando un riferimento diretto può essere rimosso completamente, NuGet emette il warning NU1510:

<!-- Prima: riferimento diretto ridondante -->
<PackageReference Include="System.Text.Json" Version="10.0.0" />

<!-- NuGet emetterà NU1510: puoi rimuovere questo riferimento -->

Come attivare manualmente (per progetti precedenti)

Per progetti che non usano ancora i default di .NET 10, è possibile attivare pruning e audit esplicitamente:

<PropertyGroup>
  <NuGetAuditMode>all</NuGetAuditMode>
  <RestoreEnablePackagePruning>true</RestoreEnablePackagePruning>
</PropertyGroup>

In un progetto multi-target, se almeno un target framework è net10.0 o successivo, il pruning si applica a tutti i target framework del progetto.

Impatto su pipeline CI/CD e security scanning

Per i team che usano tool come OWASP Dependency-Check, Snyk, GitHub Dependabot o dotnet-outdated, il package pruning riduce significativamente il rumore nei report. I vulnerability report post-pruning riflettono le dipendenze reali dell’applicazione, rendendo le decisioni di remediation più precise e il triage più veloce.

Il comando per verificare lo stato attuale del tuo progetto:

dotnet list package --include-transitive --vulnerable

Con .NET 10 e pruning attivo, l’output dovrebbe essere significativamente più corto rispetto a .NET 8/9 con gli stessi package di primo livello.

Conclusione

Il package pruning in .NET 10 è uno di quei miglioramenti silenziosi che hanno un impatto concreto quotidiano: meno rumore nei report di sicurezza, restore più veloci, e un dependency graph che rispecchia davvero cosa usa la tua applicazione. Se stai ancora su .NET 9, vale la pena attivarlo subito con le due property nella sezione precedente.

Fonte: NuGet Package Pruning: Cleaner Dependencies and Actionable Vulnerability Reports — .NET Blog

NuGet Package Pruning: Cleaner Dependencies and Actionable Vulnerability Reports - .NET Blog

Package pruning in .NET 10 removes platform-provided packages from your dependency graph. With transitive auditing enabled by default, projects with these defaults have 70% fewer transitive vulnerability reports compared to projects using the previou…

^{Nikolche Kolev (.NET Blog)}

(in)sicurezza digitale

2026-06-08 18:17:21

Polyfill.io torna attivo nel 2026: pop-up di login sospetti colpiscono Toshiba, Muji e Samsung

Il dominio polyfill[.]io — protagonista di uno dei più clamorosi supply chain attack del 2024 — è tornato attivo a fine maggio 2026 con un nuovo vettore: risposte HTTP 401 che inducono i browser a mostrare finestre di autenticazione false agli utenti di siti che non avevano ancora rimosso il vecchio script. Tra le vittime più note: Toshiba, Muji, Zojirushi e Samsung Smart TV.

Il contesto: l’incidente polyfill.io del 2024

Polyfill è una libreria JavaScript che permette ai siti web di supportare funzionalità moderne su browser legacy, fornendo uno strato di compatibilità lato client. Per anni, milioni di siti hanno caricato questa libreria dal CDN ospitato su polyfill[.]io — un dominio che tuttavia non era mai stato di proprietà del creatore del progetto open source, Andrew Betts.

Nel febbraio 2024, il dominio polyfill[.]io fu acquistato da un’entità cinese (Funnull), che lo utilizzò per iniettare codice malevolo negli script distribuiti dal CDN, colpendo oltre 100.000 siti. Betts reagì subito consigliando a tutti gli amministratori di rimuovere il servizio dai propri siti e rilancò il progetto originale sotto nuovi domini (polyfill.com, poi polyfill.top). Le autorità e diversi CDN provider bloccarono l’accesso a polyfill[.]io, fermando i redirect malevoli.

Maggio 2026: il dominio risponde di nuovo — con HTTP 401

Il problema del 2026 ha un meccanismo diverso ma altrettanto insidioso. Secondo il ricercatore di sicurezza Pasquale Pillitteri, a partire da fine maggio 2026 il dominio polyfill[.]io ha ricominciato a rispondere alle richieste, questa volta restituendo codici HTTP 401 (Unauthorized). Quando un browser carica una risorsa da un dominio esterno e riceve una risposta 401, interpreta questo come una richiesta di autenticazione e mostra automaticamente una finestra di dialogo per inserire username e password.

Tutti i siti che negli ultimi due anni non avevano completato la pulizia del codice — rimuovendo ogni riferimento a polyfill[.]io — si sono trovati improvvisamente a presentare ai propri utenti delle finestre di login che sembravano provenire dal sito legittimo, ma erano in realtà generate da una risorsa esterna non controllata dall’azienda.

Le organizzazioni colpite

Il colosso tecnologico Toshiba ha pubblicato un avviso urgente ai propri utenti il 2 giugno 2026, chiedendo di annullare qualsiasi finestra di autenticazione insolita apparsa sul sito e di non inserire credenziali. Il gigante del retail Muji ha emesso un comunicato simile, dichiarando di non aver rilevato accessi non autorizzati o fughe di dati, ma invitando comunque alla prudenza chi avesse eventualmente inserito le proprie credenziali. Anche Zojirushi (elettrodomestici), FiNC Technologies (app di salute), Ishiyaku Publishers e Hobonichi (editore e brand lifestyle) hanno segnalato lo stesso problema. Pillitteri ha riportato che il fenomeno si è manifestato anche sui televisori Samsung Smart TV l’1 giugno 2026.

Analisi tecnica: il meccanismo dell’HTTP 401 browser prompt

Il comportamento è standard nelle specifiche HTTP: quando una risorsa (script, immagine, iframe) risponde con 401, il browser mostra automaticamente una finestra di autenticazione nativa (WWW-Authenticate challenge). L’aspetto visivo di questa finestra è quello di un dialog box del browser — non una pagina web — il che può dare all’utente l’impressione di una richiesta legittima proveniente dal sito che sta visitando. Se l’utente inserisce le credenziali, queste vengono inviate in chiaro (o con Basic Auth) al server che ha emesso la challenge — in questo caso polyfill[.]io.

Al momento della pubblicazione dell’articolo originale di BleepingComputer (5 giugno 2026), non erano emerse prove concrete che le credenziali eventualmente inserite dagli utenti fossero state effettivamente raccolte. Toshiba e Muji hanno dichiarato di aver rimosso il riferimento a polyfill[.]io e di aver sospeso il servizio. Tuttavia, il rischio per gli utenti che abbiano inserito credenziali prima della chiusura rimane reale, e il cambio password immediato è fortemente consigliato.

Cosa devono fare gli amministratori di siti web

La lezione principale di questo incidente è chiara: le dipendenze da CDN esterni non controllati rappresentano un rischio persistente anche dopo che un incidente di sicurezza è stato apparentemente risolto. Gli amministratori devono verificare immediatamente che nessuna pagina del proprio sito contenga riferimenti a polyfill[.]io — incluse pagine secondarie, template legacy e componenti di terze parti. Gli strumenti di Content Security Policy (CSP) e Subresource Integrity (SRI) possono prevenire questo tipo di attacco bloccando il caricamento di risorse da domini non autorizzati o con hash diverso da quello atteso. Qualsiasi CDN di terze parti dovrebbe essere monitorato per variazioni nel comportamento delle risorse caricate.

Indicatori

## Dominio da bloccare
polyfill.io
cdn.polyfill.io

## Pattern da cercare nel codice sorgente
src="https://polyfill.io/
src='https://polyfill.io/
src="//polyfill.io/

(in)sicurezza digitale

2026-06-08 18:16:34

Luna Moth incassa 20 milioni di dollari da Weil Gotshal & Manges: il gruppo entra fisicamente negli uffici per rubare dati

Weil, Gotshal & Manges — una delle law firm più influenti al mondo, con un portafoglio clienti che include le maggiori transazioni M&A e contenziosi corporate degli Stati Uniti — ha corrisposto tra 18 e 20 milioni di dollari al gruppo di estorsione noto come Luna Moth, Silent Ransom Group o UNC3753. Il pagamento è avvenuto nell’arco di tre giorni dalla richiesta. Contemporaneamente, l’FBI ha emesso un alert FLASH — il secondo in dodici mesi su questo attore, il primo a livello FLASH — documentando un’escalation tattica senza precedenti: il gruppo ora invia operativi fisici negli uffici delle vittime.

Chi è Luna Moth / Silent Ransom Group

Luna Moth è attiva dal 2022 e affonda le proprie radici nelle operazioni BazarCall, un’infrastruttura di phishing telefonico che fino alla primavera di quell’anno aveva fornito accesso iniziale alle operazioni ransomware di Ryuk e Conti. Dopo il collasso di Conti (aprile 2022), il nucleo operativo si è separato dando vita al Silent Ransom Group, che ha abbandonato il modello tradizionale di ransomware con cifratura dei sistemi in favore di pura estorsione via data theft.

Il modello economico è cinico ma efficace: non cifrare i sistemi delle vittime significa non bloccare l’operatività aziendale (il che riduce la pressione a chiamare le forze dell’ordine) e concentrarsi sulla minaccia più cogente per le law firm — la pubblicazione di documenti riservati dei clienti. Secondo la società di sicurezza Halcyon, tra il 2025 e l’inizio del 2026 si contano oltre 200 incidenti ransomware/estorsione ai danni di studi legali, con il SRG protagonista indiscusso della verticalizzazione su questo settore.

Il caso Weil Gotshal: cronologia e dettagli

Secondo il reporting esclusivo di The Insurer, Luna Moth ha ottenuto accesso a un numero non specificato di documenti riservati dei clienti di Weil, Gotshal & Manges e li ha caricati su un’infrastruttura cloud esterna senza autorizzazione. La richiesta di riscatto — definita “suppression payment” — ammonta a una cifra tra 18 e 20 milioni di dollari. Il pagamento sarebbe stato effettuato entro tre giorni dalla richiesta.

Weil ha confermato l’incidente in una dichiarazione ufficiale, specificando che “un attore malintenzionato ha caricato senza autorizzazione un numero limitato di documenti clienti su una risorsa cloud esterna”. La firma ha aggiunto che i forensic specialist ingaggiati non hanno trovato prove di penetrazione nella rete interna e che non è stata rilevata attività non autorizzata nei monitoraggi successivi. La società ha notificato i clienti i cui dati sono stati coinvolti e ha comunicato di aver allertato le forze dell’ordine. Il pagamento del riscatto non è stato confermato da Weil.

L’impatto reputazionale è comunque significativo: una law firm che gestisce transazioni miliardarie e contenziosi sensibili è per definizione un target ad altissimo valore per chi punta alla pubblicazione di informazioni riservate. Secondo EclecticIQ, il SRG ha già pubblicato dati di oltre 38 studi legali sul proprio leak site, con un totale di incidenti che supera i 100.

L’escalation tattica: dal vishing all’infiltrazione fisica

L’elemento più allarmante documentato dall’alert FLASH dell’FBI (numero FLASH-20260526-01) è l’evoluzione della kill chain del SRG, che si è articolata in tre generazioni tattiche distinte.

Fase 1 (2022-2024) — Callback phishing: invio massivo di email che impersonano servizi di subscription con un numero telefonico da chiamare per “risolvere il problema”. L’operatore al telefono — che finge di essere il supporto del servizio — convince la vittima a installare un tool di remote monitoring and management (RMM) da un sito fake dell’helpdesk. Non ci sono link o allegati malevoli nell’email, il che consente di bypassare la stragrande maggioranza dei filtri enterprise.

Fase 2 (primavera 2025-inizio 2026) — IT impersonation via cold call: invece di aspettare che la vittima chiami, il SRG inizia a contattare direttamente i dipendenti spacciandosi per l’IT interno dell’azienda target. Il pretesto standard è una “manutenzione di routine” o una risposta a un presunto attacco phishing ricevuto. La richiesta è la stessa: concedere l’accesso a una sessione desktop remota. Il livello di preparazione degli operatori è elevato: registrano domain typosquatted che impersonano i portali IT delle law firm target, personalizzano il social engineering in base all’organigramma aziendale.

Fase 3 (primavera 2026) — Infiltrazione fisica: questa è la novità documentata dall’FBI nel FLASH alert. Quando i tentativi di accesso remoto falliscono, il SRG invia un operativo fisicamente presso la sede della vittima. L’attore si presenta come tecnico IT e dichiara di dover “clonare il disco” o “creare un backup” per far fronte a potenziali impatti del phishing ricevuto. Una volta ottenuto l’accesso fisico alla macchina, inserisce un dispositivo di storage per estrarre i dati direttamente.

TTP e strumenti tecnici

Una volta ottenuto l’accesso remoto o fisico, la metodologia del SRG è caratterizzata da minima privilege escalation e rapido pivot verso l’esfiltrazione. Gli strumenti principali documentati dall’FBI sono WinSCP (Windows Secure Copy) e versioni nascoste o rinominate di rclone per la sincronizzazione cloud. Il gruppo usa le credenziali carpite per accedere a repository documentali, drive condivisi e cartelle clienti. Il leak site è attivo e viene aggiornato regolarmente come strumento di pressione nelle negoziazioni.

Le richieste di riscatto variano significativamente in base alla dimensione dell’organizzazione target: secondo EclecticIQ i range storici vanno da 1 a 8 milioni di dollari. Il caso Weil Gotshal — con 18-20 milioni — rappresenta un massimo storico documentato per questa famiglia, coerente con il profilo ultra-premium della law firm target.

Perché le law firm sono il target ideale

Le law firm concentrano un livello di riservatezza dei dati che pochi altri settori possono eguagliare: memorie difensive in contenziosi attivi, documenti M&A pre-annuncio, segreti industriali, comunicazioni privilegiate attorney-client, strategie fiscali. La minaccia di pubblicazione crea pressioni sia sulla firma sia sui clienti rappresentati — un effetto moltiplicatore che rende la negoziazione più probabile rispetto ad altri settori. Alcuni dei clienti più importanti di Weil includono aziende Fortune 500, fondi private equity e istituzioni finanziarie: la pubblicazione di loro documenti strategici avrebbe conseguenze che vanno ben oltre il danno reputazionale della firma.

Due righe per i difensori

• Verifica out-of-band dell’identità: qualsiasi richiesta di accesso remoto da presunto personale IT deve essere verificata tramite canale separato (non il numero fornito dal chiamante). Istituire procedure di autenticazione per gli interventi tecnici da remoto.
• Politiche di accesso fisico: nessun tecnico esterno deve poter connettere dispositivi USB o storage alle macchine aziendali senza autorizzazione documentata e supervisione. Badge visitatori con registrazione obbligatoria.
• Allowlist degli strumenti RMM: bloccare l’installazione di RMM tool non approvati (AnyDesk, ConnectWise, TeamViewer e simili) tramite application control.
• DLP e monitoraggio esfiltrazione: alert su uso anomalo di WinSCP o rclone, trasferimenti bulk verso storage cloud esterni, accessi insoliti a repository documentali fuori orario.
• Formazione specifica sul vishing: simulazioni di callback phishing e IT impersonation per tutti i dipendenti, con enfasi sul non fornire mai accesso remoto a chiamanti inbound non verificati.
• MFA resistente al phishing: FIDO2/hardware token per tutti gli accessi ai sistemi documentali.

Fonti: The Insurer, BleepingComputer, FBI FLASH-20260526-01, EclecticIQ, Dark Reading