Spcnet.it

2026-08-29 15:50:51

Azure SQL Managed Instance: addio alla quota regionale unica, ora i limiti sono per famiglia hardware

Il problema: quote regionali condivise e capacity planning complicato

Chi gestisce ambienti Azure SQL Managed Instance (MI) su larga scala conosce bene un problema che, fino a pochi giorni fa, complicava ogni fase di dimensionamento: le quote regionali di subnet. Ogni Managed Instance deve risiedere in una subnet dedicata e delegata al servizio, e fino ad oggi il numero massimo di vCore utilizzabili in quella subnet era vincolato a una quota unica per regione e sottoscrizione, condivisa indistintamente tra tutte le generazioni hardware disponibili (Standard-series, Premium-series e Premium-series Memory Optimized).

In pratica, se un team aveva già saturato la quota regionale con istanze su hardware Standard-series, non poteva provisionare una nuova istanza Premium-series nella stessa regione senza prima aprire una richiesta di supporto per l’aumento della quota, anche se la subnet stessa aveva ancora spazio IP disponibile. Un vincolo “trasversale” che poco aveva a che fare con la reale capacità di rete e molto con una limitazione amministrativa lato piattaforma, particolarmente dolorosa per chi gestisce deployment multi-tenant, ambienti di disaster recovery con failover group, o strategie di aggiornamento side-by-side che richiedono temporaneamente il doppio delle risorse.

Cosa cambia: quote per generazione hardware, non più una quota unica

Microsoft ha annunciato il passaggio a un modello di limiti semplificati e granulari: la quota regionale condivisa viene sostituita da quote indipendenti per ciascuna famiglia hardware. In altre parole, i vCore disponibili per Standard-series, quelli per Premium-series e quelli per Premium-series Memory Optimized vengono ora contabilizzati separatamente, e i deployment sono governati dai normali limiti di rete virtuale di Azure Resource Manager (ARM) piuttosto che da un vincolo specifico del servizio SQL MI.

Il cambiamento si applica sia ai deployment single-zone sia a quelli zone-redundant, e riguarda tutte le subnet delegate a Microsoft.Sql/managedInstances. Per i clienti esistenti la transizione è trasparente: le quote regionali di vCore attualmente in uso vengono convertite automaticamente nel nuovo modello per-hardware, senza necessità di riconfigurare le istanze già in esercizio.

Perché è rilevante per chi fa capacity planning

• Richieste di quota più mirate: se serve solo più capacità Premium-series Memory Optimized, non è più necessario negoziare un aumento che finirebbe per “gonfiare” anche lo spazio per le altre famiglie hardware.
• Pianificazione degli upgrade side-by-side più semplice: le operazioni che richiedono capacità aggiuntiva temporanea (ad esempio il passaggio da hardware Gen5 legacy a Standard-series) impattano ora solo la quota della famiglia hardware coinvolta.
• Meno attrito nei deployment multi-team: in sottoscrizioni condivise tra più team o applicazioni, un consumo intensivo di una famiglia hardware non blocca più il provisioning su un’altra famiglia nella stessa regione.

Cosa resta invariato: il dimensionamento della subnet

È importante non confondere questo cambiamento con un allentamento dei requisiti di rete: la subnet dedicata a Managed Instance deve continuare a rispettare i vincoli storici del servizio. Microsoft continua a raccomandare un blocco CIDR di almeno /27 (32 indirizzi) per garantire margine sufficiente a operazioni di manutenzione, failover e scaling, con /28 come limite minimo assoluto per ambienti realmente contenuti. Restano inoltre valide le regole che vietano di condividere la subnet con altre risorse non delegate e che richiedono una tabella di route e un gruppo di sicurezza di rete (NSG) dedicati e configurati secondo i requisiti del servizio.

Per chi deve verificare lo stato attuale delle quote, il percorso resta quello consueto tramite portale Azure, sotto Subscriptions > Usage + quotas filtrando per il provider Microsoft.Sql, oppure via Azure CLI:

az sql instance-pool list-usage --location "westeurope"

# oppure, per verificare i limiti di risorsa applicabili a una specifica instance pool
az sql instance-pool show --name mypool --resource-group myRG

Le richieste di aumento quota, quando necessarie, si effettuano ancora tramite una richiesta di supporto dedicata dal portale Azure, specificando ora la famiglia hardware interessata anziché una generica richiesta regionale.

Considerazioni pratiche per l’infrastruttura

Per chi sta pianificando una migrazione verso Managed Instance, o un ampliamento di un ambiente esistente, questo è un buon momento per rivedere la topologia di rete. Alcuni suggerimenti operativi:

• Documentate quale famiglia hardware usa ciascuna istanza nel vostro inventario CMDB o nei tag delle risorse: con quote separate, sapere “chi consuma cosa” diventa più rilevante per prevedere colli di bottiglia futuri.
• Rivedete le pipeline di provisioning IaC (Bicep, Terraform, ARM template): se avevate logica custom per gestire manualmente errori di quota condivisa, potete probabilmente semplificarla.
• Pianificate in anticipo gli upgrade di generazione hardware: sapere che la quota Premium-series è indipendente da quella Standard-series consente di programmare finestre di migrazione senza il rischio che un’altra applicazione “consumi” involontariamente la capacità necessaria.
• Verificate i failover group cross-region: assicuratevi che anche nella regione secondaria la quota per la famiglia hardware utilizzata sia sufficiente, dato che il DR richiede risorse equivalenti a quelle primarie.

Conclusione

Si tratta di una modifica infrastrutturale che non introduce nuove funzionalità visibili agli sviluppatori, ma che rimuove un attrito operativo reale per chi amministra ambienti Azure SQL Managed Instance su larga scala. Il passaggio da una quota condivisa a quote per hardware allinea meglio la governance delle risorse SQL a quella già in uso per il resto della rete virtuale, riduce le richieste di supporto necessarie per operazioni di routine e semplifica la pianificazione di capacity planning e upgrade. Per i team che gestiscono più applicazioni con esigenze hardware eterogenee nella stessa sottoscrizione, il beneficio pratico si vedrà già alla prossima richiesta di provisioning.

Fonte: Petri IT Knowledgebase – Azure SQL Managed Instance Removes a Capacity Planning Hurdle for Large Deployments

Azure SQL Managed Instance Drops Regional Subnet Quotas

Microsoft has removed regional subnet quotas for Azure SQL Managed Instance, simplifying deployment planning.

^{Rabia Noureen (Petri IT Knowledgebase)}

Spcnet.it

2026-08-29 15:50:38

768 chiavi AWS con accesso amministrativo ancora attive: la guida pratica all’igiene delle credenziali cloud

Truffle Security ha passato al setaccio oltre 430.000 fonti pubbliche — repository Git, dataset di training, immagini Docker, log di CI — e ne ha estratto 64.024 coppie di chiavi AWS uniche, distribuite su oltre 50.000 account. Il dato che dovrebbe far drizzare le antenne a qualsiasi sistemista non è tanto il numero in sé, quanto quello che è successo quando i ricercatori hanno riverificato un campione di 10.616 chiavi ad agosto 2026: l’88% era ancora valido. Non credenziali di test dimenticate in un branch morto: chiavi vive, utilizzabili, spesso con privilegi amministrativi completi su account aziendali.

È un caso di studio quasi perfetto su come l’igiene delle credenziali cloud si degradi silenziosamente nel tempo, e su cosa si può fare concretamente — oggi, con gli strumenti che AWS mette già a disposizione — per non finire nella prossima ricerca di questo tipo.

I numeri che contano davvero

La metodologia merita una menzione: i ricercatori non hanno letto policy IAM né toccato dati applicativi, ma hanno usato esclusivamente chiamate di sola lettura come sts:GetCallerIdentity, iam:ListAccessKeys e budgets:DescribeBudgets per confermare che una chiave fosse autentica e capire a cosa desse accesso. Un approccio pulito, che rende i numeri difficili da liquidare come esagerazioni.

Il quadro che emerge sul campione riverificato:

• 768 chiavi aziendali con controllo amministrativo totale sull’account che le ospitava.
• 526 di queste erano chiavi di root, cioè l’identità con poteri illimitati che AWS stessa raccomanda di non usare mai in produzione.
• 130 chiavi root appartenevano addirittura all’account di gestione dell’intera organizzazione AWS, con potenziale impatto su tutti gli account figli collegati via AWS Organizations.
• 242 utenti IAM avevano la policy AdministratorAccess allegata direttamente o tramite un gruppo.
• Su un sottoinsieme di 1.157 utenti IAM di cui è stato possibile enumerare le policy, il 976, cioè l’84%, risultava amministratore.

Ma il dato più interessante per chi fa capacity planning della propria postura di sicurezza è un altro: l’età mediana delle chiavi ancora attive era di circa 5 anni, con punte fino a 17,4 anni. E solo il 13,7% aveva accanto una chiave più recente, segno che il resto — l’86% — non era mai stato ruotato dal giorno della creazione. Le chiavi AWS non scadono da sole: se nessuno le ruota o le revoca attivamente, restano valide per sempre, anche dopo che la persona che le ha create ha lasciato l’azienda o dimenticato il progetto in cui erano incluse.

Da dove escono le chiavi

La fonte principale identificata non è GitHub, come ci si aspetterebbe, ma Hugging Face: 8.482 chiavi uniche trovate in 3.394 dataset pubblici, con la percentuale più alta di chiavi root fra tutte le sorgenti analizzate (17,9%). Il meccanismo è subdolo: uno sviluppatore include per errore un file di configurazione o un notebook con credenziali hardcoded in un dataset poi scaricato, clonato e reimpacchettato migliaia di volte per l’addestramento di modelli. A quel punto cancellare il file originale non serve a nulla, perché la credenziale è ormai disseminata in decine di copie derivate. Le altre fonti classiche — cronologia Git, immagini Docker, registri dei package manager, log di CI esposti — restano comunque significative.

Perché l’impatto economico è il segnale più sottovalutato

Un altro dato da isolare: sui soli account con spesa mensile leggibile, il totale ammontava a oltre 420.000 dollari al mese, con nove account sopra i 10.000 dollari/mese. La parte più scomoda: solo il 9,5% degli account leggibili aveva un budget alert configurato, anche minimo. La maggior parte delle organizzazioni coinvolte non avrebbe quindi ricevuto alcun segnale automatico in caso di abuso delle credenziali per cryptomining o exfiltration, se non la fattura di fine mese — e un budget alert a 10 dollari costa letteralmente nulla da configurare. È probabilmente il controllo con il miglior rapporto sforzo/beneficio dell’intero articolo, eppure resta il più trascurato.

Il piano d’azione per chi gestisce account AWS in produzione

1. Eliminare le chiavi di root, senza eccezioni

Come ricordano gli stessi ricercatori, nel 2026 non esiste più alcuna ragione legittima per avere una chiave di accesso root attiva. Ogni operazione che un tempo richiedeva le credenziali root può oggi essere delegata a un utente o ruolo IAM con permessi granulari. Il primo passo è un inventario:

aws iam get-account-summary --query 'SummaryMap.AccountAccessKeysPresent'

Se il valore restituito è diverso da zero, esiste ancora una chiave di accesso root da eliminare dalla console IAM (sezione «Credenziali di sicurezza» dell’account root). Questo controllo va ripetuto su ogni account collegato via AWS Organizations, inclusi quelli storici creati anni fa e magari dimenticati.

2. Fare l’inventario e la rotazione delle chiavi IAM

Per ogni utente IAM, un comando come questo restituisce l’età di ciascuna chiave attiva:

aws iam list-access-keys --user-name nome-utente \
  --query 'AccessKeyMetadata[].{Id:AccessKeyId,Status:Status,Created:CreateDate}'

Per farlo su scala, conviene generare il credential report integrato di IAM, che include per ogni utente la data dell’ultima rotazione e dell’ultimo utilizzo:

aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d > credential-report.csv

Da qui è possibile costruire una policy interna semplice ma efficace: nessuna chiave IAM viva più di 90 giorni senza rotazione, e nessuna chiave inutilizzata da oltre 45 giorni resta attiva. Questi controlli si possono automatizzare con AWS Config, usando le regole gestite access-keys-rotated e iam-user-unused-credentials-check, che segnalano automaticamente le credenziali fuori policy.

3. Sostituire le chiavi statiche con credenziali temporanee dove possibile

La causa profonda del problema non è solo la disattenzione nel pubblicare codice: è l’uso stesso di chiavi statiche a lunga durata dove non servirebbero. Per workload su EC2, ECS o Lambda, i ruoli IAM associati all’istanza o alla funzione eliminano la necessità di distribuire chiavi: le credenziali vengono generate automaticamente, durano poche ore e non finiscono mai su disco. Per l’accesso umano da riga di comando, IAM Identity Center (ex AWS SSO) con aws sso login ottiene lo stesso risultato: credenziali temporanee via autenticazione federata, mai una coppia access key/secret key permanente da custodire.

4. Restringere il raggio d’azione con permission boundary e Access Analyzer

Dove le chiavi IAM restano necessarie, i permission boundary impongono un tetto massimo ai privilegi che una policy può concedere a un utente, indipendentemente da eventuali policy troppo permissive aggiunte in futuro per errore. AWS IAM Access Analyzer va usato in modo proattivo per capire chi, all’esterno dell’account, può potenzialmente raggiungere le risorse tramite trust policy troppo larghe:

aws accessanalyzer list-findings \
  --analyzer-arn arn:aws:access-analyzer:eu-west-1:123456789012:analyzer/nome-analyzer \
  --filter '{"status":{"eq":["ACTIVE"]}}'

5. Impedire che le chiavi finiscano nel commit, non solo dopo

Trattare ogni commit come una potenziale fuga di dati è l’unico approccio realistico: il 43% delle chiavi individuate nella ricerca era presente in più posizioni contemporaneamente, segno che, una volta trapelata, una credenziale si propaga rapidamente in fork, mirror e archivi di terze parti. Strumenti come gitleaks o TruffleHog vanno integrati come pre-commit hook, così da bloccare il problema prima che raggiunga il repository remoto:

# installazione di un pre-commit hook con gitleaks
gitleaks protect --staged -v

GitHub, GitLab e Gitea offrono inoltre scanning nativo dei secret sui push, con notifica automatica ad AWS quando viene rilevata una chiave valida: è da qui che nasce la policy AWSCompromisedKeyQuarantine, applicata automaticamente da AWS quando una chiave viene rilevata esposta pubblicamente. Nella ricerca, il 12% delle chiavi la portava già — un segnale che, se ignorato, lascia comunque la chiave tecnicamente valida per operazioni di sola lettura in molti casi, e va trattato come un incidente da chiudere subito, non come un avviso a bassa priorità.

Conclusione

Il dato più utile di questa ricerca non è il numero assoluto di chiavi esposte, ma la fotografia di cosa succede quando la rotazione delle credenziali non è un processo automatizzato ma una buona intenzione: dopo cinque anni, in media, nessuno se ne ricorda più. Per chi amministra infrastrutture AWS, il valore pratico sta tutto nella lista di controlli sopra — nessuno dei quali richiede strumenti terzi costosi o una rewrite dell’architettura. Un inventario delle chiavi, un budget alert, un permission boundary e un pre-commit hook sono interventi che si implementano in un pomeriggio e che, secondo questi numeri, la maggior parte delle organizzazioni non ha ancora messo in pratica.

Fonte: Truffle Security — «768 Leaked Corporate AWS Keys Held Full Admin Rights», ripreso da Petri.com.

Hundreds of Exposed AWS Keys Still Provide Administrative Access

Hundreds of exposed AWS keys still provide administrative access, with many credentials remaining active years after being leaked.

^{Rabia Noureen (Petri IT Knowledgebase)}

Spcnet.it

2026-08-28 08:55:32

Kubernetes v1.37 “Garhwal”: HPA con scale-to-zero nativo e un API server più resiliente su larga scala

Il rilascio del 26 agosto

Kubernetes v1.37, nome in codice Garhwal, è stato rilasciato il 26 agosto 2026 dopo il consueto ciclo con enhancement freeze a metà giugno e code freeze a fine luglio. Il changelog conta 86 enhancement complessivi, di cui 16 passano a Stable e altri 28 sono classificati come “Graduating” tra Alpha e Beta. Per chi gestisce cluster in produzione, due filoni meritano un approfondimento perché toccano direttamente i costi operativi e la resilienza del control plane: lo scale-to-zero nativo dell’HPA e una serie di ottimizzazioni interne pensate per proteggere l’API server sotto carico estremo.

Scale-to-zero: l’HPA impara a spegnere tutto

Da anni chi vuole azzerare le repliche di un workload realmente idle (un job batch, un ambiente di staging fuori orario, un microservizio a bassissimo traffico) deve appoggiarsi a soluzioni esterne come KEDA, che introducono un ulteriore componente da gestire e monitorare. Con la KEP-2021 (“Support scaling to/from zero pods for object/external metrics”), che in questa release passa da Alpha a Beta, l’Horizontal Pod Autoscaler nativo guadagna questa capacità senza dipendenze esterne.

La differenza pratica rispetto al comportamento precedente è che ora si può impostare minReplicas: 0 quando l’HPA è configurato su metriche di tipo Object o External (non su CPU/memoria, per ovvie ragioni: non esiste un consumatore da cui misurare l’utilizzo se non ci sono pod):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker-scale-to-zero
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 0
  maxReplicas: 10
  metrics:
  - type: External
    external:
      metric:
        name: queue_messages_ready
        selector:
          matchLabels:
            queue: orders
      target:
        type: AverageValue
        averageValue: "30"

La novità architetturale più interessante della graduazione a Beta è l’introduzione di una condizione di stato esplicita, ScaledToZero, esposta nell’oggetto HorizontalPodAutoscaler. Prima, un deployment a zero repliche poteva significare “l’HPA ha deciso di spegnerlo” oppure “qualcuno lo ha messo in pausa manualmente con kubectl scale --replicas=0“, e i controller di automazione (o gli operatori umani) non avevano un modo affidabile per distinguere i due casi. Con questa condizione visibile via kubectl describe hpa o via API, strumenti di GitOps e dashboard di osservabilità possono finalmente riconciliare correttamente lo stato desiderato senza riportare falsamente in vita un workload che era stato fermato apposta da un operatore.

Tolleranza configurabile: basta con il 10% fisso per tutti

Una seconda modifica, meno appariscente ma altrettanto utile in produzione, riguarda la KEP-4951 (“Configurable tolerance for Horizontal Pod Autoscalers”), che con questa release passa a Stable. Fino a v1.36, l’HPA applicava una tolleranza fissa a livello di cluster (il classico 10%) prima di decidere che uno scarto tra metrica osservata e target giustificasse un’azione di scaling. Questo valore, impostato una volta a livello di kube-controller-manager, andava bene come default generico ma era un compromesso scomodo per workload con esigenze molto diverse tra loro: un servizio latency-sensitive vorrebbe reagire a scostamenti minimi, mentre un batch job tollera oscillazioni ben più ampie senza bisogno di “flappare” in continuazione.

Ora il campo di tolleranza è configurabile per singolo HPA, direttamente in spec.behavior:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: latency-sensitive-api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-gateway
  minReplicas: 3
  maxReplicas: 20
  behavior:
    scaleUp:
      tolerance: "0.05"
    scaleDown:
      tolerance: "0.20"
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

Con questa configurazione, l’API gateway scala verso l’alto già con uno scostamento del 5% (per assorbire i picchi rapidamente) ma tollera fino al 20% di margine prima di scalare verso il basso (per evitare di disfare capacità troppo aggressivamente). L’algoritmo di calcolo dello scaling resta invariato: cambia solo la soglia di sensibilità, il che rende la migrazione da configurazioni esistenti sostanzialmente priva di rischi.

Proteggere l’API server: il vero collo di bottiglia dei cluster grandi

Il secondo filone di novità riguarda chi gestisce cluster di grandi dimensioni, dove l’API server è spesso il componente che soffre per primo sotto carico. La KEP-6178 (“Concurrent Watch Object Decode”) affronta un problema molto concreto: durante le migrazioni di versione delle Custom Resource Definition, ogni evento di watch attivo deve essere convertito nella nuova versione dello schema, e questa conversione avveniva storicamente in modo sequenziale. Su cluster con oltre 10.000 workload e numerosi watcher attivi, questo causava timeout verso etcd e, nei casi peggiori, errori HTTP 500 lato API server proprio nei momenti di maggior carico.

In questa release, il feature gate ConcurrentWatchObjectDecode passa a Beta ed è abilitato di default, permettendo la decodifica e conversione parallela degli eventi di watch. Per abilitarlo o disabilitarlo esplicitamente sull’API server:

kube-apiserver \
  --feature-gates=ConcurrentWatchObjectDecode=true \
  # ...altri flag esistenti

Collegata a questo filone c’è anche la KEP-6164 (“Eliminating Internal API Types”), che entra in questa release come novità in Alpha. Il problema di fondo è che Kubernetes mantiene internamente tipi API “interni” separati dai tipi versionati esposti tramite l’API, e ogni conversione tra i due formati durante operazioni di list su larga scala consuma CPU e memoria in modo non trascurabile. La prima fase della proposta rende i tipi interni memory-identical a quelli versionati, con benchmark che riportano guadagni fino a 5,7 volte in velocità e una riduzione di memoria di 3,3 volte nelle operazioni interessate; le fasi successive prevedono la sostituzione con Go type alias prima della rimozione completa della duplicazione. È presto per usarla in produzione (è Alpha), ma è un buon segnale di dove sta andando il lavoro di scalabilità del control plane nei prossimi cicli di rilascio.

Altre novità che meritano attenzione

Il changelog di v1.37 include diverse altre graduazioni utili nella pratica quotidiana:

• Pod-level resources (KEP-2837): permette di definire un pool condiviso di CPU, memoria e hugepages a livello di pod invece che per singolo container, migliorando l’utilizzo delle risorse per pod con più container che hanno pattern di consumo complementari;
• Storage Version Migrator in-tree (KEP-4192): porta nativamente nel cluster, tramite l’API storagemigration.k8s.io, la funzionalità di riscrittura automatica dei dati quando cambia la storage version di una risorsa, un’operazione che prima richiedeva strumenti esterni;
• CBOR come formato di serializzazione (KEP-4222, Beta): fino a 8 volte più veloce in encoding e 2 volte in decoding rispetto a JSON per le Custom Resource Definition, un dettaglio che pesa parecchio su cluster con molti CRD ad alta frequenza di aggiornamento;
• Nomi Service più permissivi (KEP-5311): i nomi ora possono iniziare con un numero (es. 123-backend), passando dal vincolo RFC 1035 al più permissivo formato DNS Label;
• Pod Certificates (KEP-4317): distribuzione di certificati X.509 ai pod senza passare da bearer token, tramite il nuovo oggetto PodCertificateRequest, utile per chi sta migrando verso autenticazione mutual TLS tra servizi;
• ClusterTrustBundles (KEP-3257, Beta): permette di montare bundle di trust CA come volume proiettato nei pod, semplificando la distribuzione di certificate authority personalizzate senza dover gestire ConfigMap manualmente.

Cosa verificare prima di aggiornare

Come per ogni major/minor release di Kubernetes, prima di pianificare l’upgrade su cluster di produzione vale la pena controllare tre cose in particolare: primo, se si usano CRD con più versioni attive contemporaneamente, testare il comportamento con ConcurrentWatchObjectDecode abilitato in un ambiente di staging che replichi il volume di watcher reale; secondo, se si dipende oggi da KEDA solo per lo scale-to-zero su metriche esterne (code, topic Kafka, metriche custom da Prometheus Adapter), valutare se la KEP-2021 in Beta copre già il caso d’uso, tenendo presente che è comunque prudente aspettare la Stable prima di rimuovere KEDA da workload critici; terzo, verificare la compatibilità di eventuali webhook di ammissione e operator custom con i pod-level resources, se già si sfruttano richieste/limiti a livello di container in modo granulare.

Nel complesso, v1.37 conferma una tendenza chiara delle ultime release: meno feature “vistose” rivolte all’utente finale, più lavoro di fondo su efficienza e resilienza del control plane, proprio nei punti dove i cluster più grandi iniziano a sentire la pressione della scala.

Fonte: 4sysops, con dettagli tecnici da PerfectScale e dalle note di rilascio ufficiali del progetto Kubernetes.

Kubernetes v1.37 lets idle workloads hit zero while shielding the API server – 4sysops

Kubernetes v1.37 adds 67 enhancements, including default-enabled HPA scale-to-zero support and stronger kube-apiserver protection during startup and recovery. T

^{IT News (4sysops)}

Spcnet.it

2026-08-28 08:55:30

Next.js sotto attacco: due RCE critiche (AVIF e Windows) da patchare subito

Due vulnerabilità critiche, due superfici di attacco diverse

Il 25 agosto 2026 il team di Next.js ha rilasciato un aggiornamento di sicurezza fuori dal normale ciclo di rilascio, anticipando la pubblicazione dopo aver identificato una seconda vulnerabilità critica in una dipendenza upstream mentre stava già preparando la patch per la prima. Il risultato sono due falle di Remote Code Execution non autenticata con severità critica, entrambe corrette nelle versioni 15.5.24 (Maintenance LTS) e 16.3.3 (Active LTS). Per chi gestisce applicazioni Next.js in produzione, specialmente self-hosted, questo è un aggiornamento da applicare senza rimandare.

CVE-1: RCE tramite l’Image Optimization API su file AVIF

La prima vulnerabilità (GHSA-2xp9-vwfh-vxw4, CVSS stimato 9.5) risiede in libheif, la libreria usata da sharp per la decodifica delle immagini AVIF, a sua volta impiegata dall’Image Optimization API integrata in Next.js. La falla upstream (GHSA-g89c-p67h-r497) è un heap buffer overflow nel codice di scaling delle immagini: un file AVIF costruito ad arte, con riferimenti annidati di tipo identity-derivation e auxiliary item, induce il decoder a costruire un’immagine con una profondità di bit del canale Alpha incoerente rispetto al buffer allocato. Lo scaler alloca spazio per dati a 8 bit ma vi scrive valori a 16 bit, scrivendo circa 16.384 byte oltre il limite dell’allocazione: la combinazione classica che apre la strada all’esecuzione di codice arbitrario.

L’aspetto più critico è la superficie di attacco: qualunque endpoint Next.js che passi un’immagine controllata dall’utente attraverso l’Image Optimization API (upload di avatar, contenuti caricati da terzi, immagini remote proxate) è potenzialmente sfruttabile senza autenticazione. Le versioni patchate risolvono il problema nell’immediato disabilitando l’ottimizzazione AVIF finché la fix upstream in libheif non sarà completamente propagata nella supply chain.

CVE-2026-75604: RCE su server Windows con Pages Router + App Router

La seconda falla (CVE-2026-75604 / GHSA-p293-qw3h-jr36, CVSS stimato 9.0) è più circoscritta ma non meno seria per chi ospita Next.js su Windows. Colpisce le applicazioni che utilizzano contemporaneamente Pages Router e App Router senza avere Cache Components attivo, quando il server gira su un filesystem Windows: in questo scenario è possibile innescare un path traversal che porta a RCE non autenticata sfruttando le differenze di gestione dei percorsi tra i due router in ambiente Windows.

Linux e macOS non sono affetti da questa specifica vulnerabilità, il che la rende particolarmente rilevante per ambienti enterprise .NET/Windows Server che ospitano frontend Next.js accanto a backend .NET, uno scenario comune in molte aziende italiane con infrastruttura ibrida. Il team Next.js è stato esplicito: non esiste una mitigazione applicativa nota per le applicazioni Windows-hosted affette; l’unica strada è l’aggiornamento.

Versioni interessate

• Path traversal su Windows (CVE-2026-75604): Next.js 13.4–15.5.23 e 16.0–16.3.2
• RCE via AVIF: Next.js 10.0.0–15.5.23 e tutte le versioni 16.x fino alla 16.3.2
• libheif: tutte le versioni fino alla 1.23.1 inclusa

Come verificare l’esposizione e aggiornare

Il primo passo è capire quale router state utilizzando e se l’Image Optimization API è esposta a input non fidati. Un controllo rapido nella codebase:

# Versione installata di Next.js
npm ls next

# Cercate se esistono sia pages/ che app/ nello stesso progetto
find . -maxdepth 2 -type d \( -name "pages" -o -name "app" \) -not -path "*/node_modules/*"

# Verificate se il Cache Components flag è attivo in next.config
grep -R "cacheComponents" next.config.*

Se il progetto usa entrambi i router senza Cache Components e il server è ospitato su Windows (IIS con iisnode, Windows Server con PM2, container Windows), l’aggiornamento non è opzionale. Per aggiornare:

npm install next@15.5.24   # ramo 15.5 (Maintenance LTS)
npm install next@16.3.3    # ramo 16.3 (Active LTS)

# con pnpm
pnpm add next@15.5.24
pnpm add next@16.3.3

# con yarn
yarn add next@15.5.24
yarn add next@16.3.3

Dopo l’aggiornamento, ricordate di rigenerare il lockfile e di verificare in CI che la build non introduca regressioni, in particolare se il progetto fa uso intensivo di next/image con sorgenti AVIF: l’ottimizzazione per quel formato resterà disabilitata finché non arriverà una fix upstream in libheif, quindi può essere necessario prevedere temporaneamente un fallback a JPEG/WebP per le immagini caricate dagli utenti.

Perché conviene reagire subito, anche se si usa Vercel

Le applicazioni ospitate su Vercel sono protette automaticamente lato piattaforma, ma questo non copre chi fa self-hosting su VM, container Docker, Kubernetes, Azure App Service, IIS o qualunque altro ambiente gestito direttamente. Per i team DevOps italiani che gestiscono deployment Next.js su infrastruttura on-premise o su Windows Server per motivi di compliance o integrazione con sistemi legacy .NET, il rischio è concreto: si tratta di RCE non autenticata, quindi sfruttabile da un attaccante remoto senza credenziali, con impatto potenzialmente totale sul server applicativo.

Alcune azioni consigliate oltre al semplice upgrade:

• Inventariate tutte le applicazioni Next.js in produzione, incluse quelle gestite da team diversi, e verificate la versione installata con npm ls next o controllando il package-lock.json.
• Se non potete aggiornare immediatamente, valutate di disabilitare temporaneamente l’Image Optimization API per sorgenti non fidate, o di filtrare a livello di reverse proxy/WAF le richieste verso l’endpoint /_next/image.
• Per gli ambienti Windows, se non è possibile aggiornare a breve, considerate la migrazione temporanea del workload su un host Linux/macOS finché la patch non è applicata, dato che non esiste mitigazione nota per Windows.
• Automatizzate il monitoraggio delle security advisory di Next.js e delle sue dipendenze critiche (in particolare sharp e le librerie di decodifica immagini) tramite Dependabot, Renovate o strumenti equivalenti, per ridurre il tempo di reazione a futuri annunci simili.

Conclusione

Questo doppio rilascio di sicurezza è un promemoria utile su due fronti. Il primo è tecnico: le pipeline di elaborazione immagini, spesso trattate come funzionalità “di contorno”, restano una delle superfici di attacco più insidiose nelle applicazioni web moderne, perché processano input binario complesso proveniente direttamente dagli utenti. Il secondo è organizzativo: la disponibilità di RCE non autenticate senza mitigazione nota per specifiche piattaforme (in questo caso Windows) impone di conoscere esattamente dove e come sono ospitate le proprie applicazioni Next.js, non solo quale versione del framework stanno eseguendo. Chi gestisce ambienti misti Windows/.NET con frontend Next.js dovrebbe trattare questo aggiornamento come priorità operativa immediata.

Fonte: Next.js – August 2026 Security Release e The Hacker News – Next.js Patches Critical AVIF and Windows Flaws Enabling Unauthenticated RCE

August 2026 Security Release

The August 2026 security release for Next.js is now available

^{Josh Story (nextjs.org)}