Spcnet.it

2026-07-20 17:23:37

SQL Server su VM Azure: la migrazione via Azure Arc è ora GA, ecco come funziona

Chi gestisce ambienti SQL Server on-premises conosce bene il problema: la migrazione verso il cloud richiede quasi sempre di mettere insieme tool diversi per la valutazione, il trasferimento dei dati, il monitoraggio e infine il cutover. Ogni fase ha strumenti propri, competenze diverse e margini di errore che si sommano. Con l’annuncio della disponibilità generale (GA) della migrazione a SQL Server su macchine virtuali Azure tramite Azure Arc, Microsoft porta l’intero ciclo di vita della migrazione dentro un’unica esperienza guidata nel portale Azure, lo stesso modello già usato per le migrazioni verso Azure SQL Managed Instance.

Per chi amministra data center misti, con carichi legacy e SQL Server sparsi su fisico e virtuale, questa novità merita attenzione: non è solo un annuncio di marketing, ma un cambio concreto di flusso di lavoro operativo.

Cos’è cambiato con la GA

Fino a poco tempo fa, chi voleva spostare un’istanza SQL Server su una VM Azure doveva combinare Azure Migrate, Database Migration Service e strumenti di backup/restore manuali, gestendo ciascuno con logiche e dashboard separate. Con la funzionalità di migrazione integrata in Azure Arc, il processo si consolida in quattro fasi accessibili da un singolo pannello, il Database Migration, associato all’istanza SQL Server abilitata da Arc:

• Assess source instance — valutazione di leggibilità e readiness dell’istanza sorgente
• Select target — scelta o creazione della VM SQL Server di destinazione
• Migrate data — trasferimento effettivo dei database
• Monitor and cutover — monitoraggio della sincronizzazione e passaggio finale in produzione

La discovery delle istanze e la generazione dei report di readiness avvengono automaticamente ogni fine settimana, ma possono essere lanciate anche manualmente, senza configurazioni aggiuntive: la funzione è disponibile di default per tutte le istanze SQL Server abilitate da Arc a partire da SQL Server 2012 (11.x).

Copilot integrato nel flusso di migrazione

Una parte interessante della nuova esperienza è l’integrazione di Microsoft Copilot direttamente nel pannello di migrazione. Non si tratta di un chatbot generico: interroga la knowledge base Microsoft nel contesto specifico della vostra migrazione e risponde a richieste operative come:

Come vengono eseguite le valutazioni?
Aiutami a confrontare le opzioni di destinazione
Avvia la migrazione
Aiutami a scegliere il metodo di migrazione corretto
Monitora la migrazione in corso
Completa la migrazione

Per un DBA che gestisce decine di istanze, questo significa poter chiedere direttamente nel pannello “quale VM SKU è consigliata per questo carico?” invece di andare a cercare tabelle di sizing nella documentazione.

Come funziona la migrazione via backup e restore

Il meccanismo sotto il cofano non è nuovo per chi ha familiarità con le migrazioni SQL Server classiche: si basa su backup e restore con log shipping continuo, pensato per supportare scenari di migrazione online con downtime minimo.

1. Viene eseguito un backup completo del database sorgente
2. Il backup viene caricato su un account di Azure Blob Storage intermedio
3. Il backup viene ripristinato sull’istanza SQL Server target sulla VM Azure
4. I backup dei log delle transazioni vengono caricati in continuo sullo stesso storage e applicati automaticamente al database target, mantenendolo sincronizzato
5. Al momento del cutover, Azure Arc applica l’ultimo backup caricato e porta online il database target

Un vincolo operativo da tenere a mente in fase di progettazione: l’account di Azure Blob Storage e la VM SQL Server target devono trovarsi nella stessa region Azure. È un dettaglio facile da trascurare se si pianifica la migrazione partendo dalla region “storica” dell’organizzazione invece che da quella scelta per il nuovo carico.

Prerequisiti pratici

• Una subscription Azure attiva
• L’istanza SQL Server deve essere abilitata da Azure Arc con l’estensione più recente installata (l’estensione si aggiorna indipendentemente da SQL Server, quindi va controllata separatamente)
• L’ambiente sorgente preparato secondo le linee guida ufficiali, incluso l’upload iniziale dei backup nello storage account

Per verificare rapidamente la versione dell’istanza sorgente prima di avviare l’assessment, un semplice controllo T-SQL è sempre un buon punto di partenza:

SELECT SERVERPROPERTY('ProductVersion') AS Versione,
       SERVERPROPERTY('Edition') AS Edizione,
       SERVERPROPERTY('EngineEdition') AS TipoMotore;

Cosa considerare prima di partire

Il pannello di monitoraggio e cutover mostra in tempo reale quali database sono migrati con successo, quali sono ancora in corso, il metodo di migrazione scelto, la durata della sincronizzazione e i log dettagliati. Quando lo stato passa a “Ready for cutover”, si può decidere il momento esatto del passaggio in produzione selezionando Cutover, con opzioni diverse in base al metodo di migrazione utilizzato.

Va detto che, come per ogni migrazione basata su backup/restore, restano da valutare a parte gli aspetti di sizing della VM di destinazione (storage, IOPS, memoria per il buffer pool), la licenza SQL Server (Hybrid Benefit se applicabile) e la strategia di alta disponibilità post-migrazione, che questo strumento non copre direttamente ma per cui l’assessment fornisce indicazioni.

Conclusione

Portare discovery, assessment, migrazione e monitoraggio in un’unica dashboard riduce sensibilmente l’attrito operativo delle migrazioni SQL Server verso Azure, soprattutto per i team che gestiscono ambienti ibridi complessi con decine o centinaia di istanze. Non elimina la necessità di pianificazione — region, sizing e licensing restano decisioni da prendere a monte — ma consolida in un solo posto ciò che prima richiedeva più tool scollegati tra loro. Per chi ha già istanze abilitate da Azure Arc, vale la pena aggiornare l’estensione e lanciare un primo assessment anche solo per farsi un’idea della readiness del proprio parco macchine.

Fonte: Petri IT Knowledgebase e documentazione Microsoft Learn.

Microsoft Makes SQL Server Migration to Azure VMs GA in Azure Arc

Microsoft has made SQL Server migrations to Azure Virtual Machines generally available through Azure Arc.

^{Rabia Noureen (Petri IT Knowledgebase)}

Spcnet.it

2026-07-20 17:23:33

HollowByte: come 11 byte possono esaurire la memoria dei server OpenSSL

Ogni tanto una vulnerabilità ricorda quanto la nostra infrastruttura digitale dipenda da librerie fondamentali che diamo per scontate. È il caso di HollowByte, una falla di tipo Denial of Service scoperta dal team di ricerca di Okta in OpenSSL: con un payload malevolo di appena 11 byte, un attaccante remoto e non autenticato può costringere un server ad allocare quantità di memoria completamente sproporzionate, prima ancora che l’handshake di sicurezza abbia inizio.

Per chi gestisce server web, database o qualsiasi servizio che parla TLS — quindi, in pratica, quasi tutti i sistemisti — vale la pena capire come funziona e, soprattutto, cosa fare subito.

Fidarsi ciecamente dell’header

L’handshake TLS comincia con un messaggio ClientHello incapsulato in un record. Ogni messaggio di handshake porta un header di 4 byte che dichiara quanto sarà grande il corpo del messaggio in arrivo.

Nelle versioni vulnerabili di OpenSSL, il buffer di ricezione viene allocato sulla base di quella lunghezza dichiarata dall’attaccante, prima ancora che i dati siano effettivamente arrivati. La catena di chiamate è semplice quanto pericolosa:

Lettura header (4 byte)
  → grow_init_buf()
    → OPENSSL_clear_realloc()
      → malloc(dimensione_dichiarata_dall_attaccante)

Poiché a questo stadio non esiste alcuna validazione del payload, un header che dichiara una lunghezza di 3 byte può far allocare fino a 131 KB basandosi solo sulla dichiarazione del pacchetto, che nessuno verifica. Il worker thread resta poi bloccato ad attendere dati che non arriveranno mai.

L’effetto moltiplicatore: la frammentazione della memoria

Tenere connessioni aperte per esaurire i thread è un trucco vecchio quanto Slowloris. Quello che rende HollowByte più insidioso è l’interazione con la gestione della memoria di glibc (GNU C Library).

Quando una connessione dell’attaccante si chiude, OpenSSL libera il buffer — ma glibc non restituisce immediatamente al sistema operativo le allocazioni di dimensione piccola o media: le trattiene per un possibile riutilizzo. Lanciando ondate di connessioni con dimensioni dichiarate casuali, un attaccante impedisce all’allocatore di riutilizzare in modo efficiente quei blocchi liberati. L’heap si frammenta pesantemente e la Resident Set Size (RSS) del processo cresce in modo continuo.

Il punto critico è questo: anche dopo che l’attaccante si è disconnesso, il processo resta con un footprint di memoria permanentemente gonfiato. L’unico modo per recuperarla davvero è riavviare il servizio.

I numeri dei test

Il team di Okta ha testato istanze OpenSSL patchate e non patchate dietro NGINX, sotto diverse condizioni di carico:

• In un ambiente con 1 GB di RAM, il server non patchato è stato terminato dall’OOM killer dopo aver accumulato 547 MB di memoria frammentata e inutilizzabile
• In un ambiente con 16 GB di RAM, l’attacco ha bloccato il 25% della memoria totale del sistema, restando sotto la soglia massima di connessioni consentite — il che significa che le classiche difese basate su rate limiting delle connessioni non fermano questo attacco

Dato che OpenSSL è incorporato ovunque, l’impatto potenziale copre web server (Apache, NGINX), runtime di linguaggi (Node.js, Python, Ruby, PHP) e database (MySQL, PostgreSQL) che si appoggiano alla libreria per TLS.

La correzione: crescita incrementale del buffer

Il team OpenSSL ha risolto il problema passando a una crescita incrementale del buffer (merge delle pull request #30792, #30793 e #30794): invece di fidarsi della lunghezza dichiarata nell’header, il buffer cresce solo quando i byte arrivano effettivamente sulla connessione. Una dichiarazione senza seguito ora non costa più nulla al server.

Il fix è stato incluso silenziosamente nella release OpenSSL 4.0.1, con backport altrettanto silenziosi sulle versioni:

3.6.3
3.5.7
3.4.6
3.0.21

Un dettaglio non trascurabile: OpenSSL ha trattato la correzione come un semplice hardening fix, senza assegnare un CVE ufficiale, nonostante la gravità dell’impatto. Questo significa che molti scanner di vulnerabilità basati solo su database CVE potrebbero non segnalare l’esposizione: va verificata manualmente la versione installata.

Cosa fare subito

Alcune azioni concrete da mettere in pratica sui vostri sistemi:

• Verificate la versione di OpenSSL su tutti i server esposti:

openssl version -a

• Aggiornate i pacchetti di sistema alla versione patchata più recente disponibile per la vostra distribuzione:

# Debian/Ubuntu
apt update && apt list --upgradable | grep -i openssl
apt install --only-upgrade openssl libssl3

# RHEL/Fedora/Alma
dnf check-update openssl
dnf update openssl

• Non fermatevi al pacchetto di sistema: controllate anche runtime e linguaggi che incorporano una propria build di OpenSSL (build statiche di Node.js, alcune distribuzioni Python, container con immagini “slim” che a volte portano versioni di OpenSSL più vecchie di quelle dell’host)
• Monitorate la RSS dei processi che terminano connessioni TLS, non solo il numero di connessioni attive: un aumento di memoria residente senza corrispondente crescita del traffico è un segnale d’allarme
• Irrigidite i timeout di handshake lato reverse proxy, ad esempio su NGINX:

ssl_handshake_timeout 10s;
client_header_timeout 10s;

• Valutate regole di rate limiting sulle nuove connessioni TLS per IP a livello di firewall o WAF, anche se — come mostrato dai test — da sole non bastano contro questa specifica tecnica

Conclusione

HollowByte è un buon esempio di come un bug apparentemente piccolo — la fiducia cieca in un header di pochi byte — possa diventare un vettore di Denial of Service difficile da rilevare con le metriche di monitoraggio standard, perché resta sotto le soglie di allarme sulla banda e sulle connessioni. La buona notizia è che la correzione è già disponibile e il percorso di mitigazione è chiaro: aggiornare OpenSSL su tutta la superficie esposta, non fidarsi solo dei database CVE per capire se si è vulnerabili, e aggiungere il monitoraggio della memoria residente ai controlli già in essere sui vostri servizi TLS.

Fonte: BleepingComputer e Okta Security.

OpenSSL HollowByte: A DoS Hiding in 11 Bytes

Every so often, a vulnerability reminds us how deeply our digital infrastructure relies on foundational libraries. Recently, the Okta Red Team discovered

^{Okta, Inc. (Okta Security)}

Spcnet.it

2026-07-19 20:18:42

Testare le skill degli agenti AI senza colpire API reali: Dev Proxy e Promptfoo in pipeline CI/CD

Chi sta integrando agenti AI in pipeline CI/CD si scontra presto con un problema pratico: come si testano in modo affidabile le “skill” di un agente (le istruzioni locali che gli insegnano quando e come usare una capacità) senza colpire API reali, senza costi imprevedibili e senza risultati non deterministici? La risposta che sta emergendo nella comunità DevOps combina due strumenti complementari: Dev Proxy di Microsoft per simulare le API a livello di rete, e Promptfoo per valutare in modo strutturato se una skill funziona meglio di un’altra.

Vale la pena approfondire entrambi gli approcci, perché il problema che risolvono — testare comportamento non deterministico in modo ripetibile — è ormai centrale per chiunque gestisca agenti AI in produzione, non solo per chi scrive skill per Claude o Codex.

Perché i mock server tradizionali falliscono con gli agenti AI

L’approccio classico al test di un’integrazione API è il mock server: si sostituisce l’endpoint reale con uno fittizio, spesso puntando l’applicazione a localhost. Con gli agenti AI questo approccio introduce un problema sottile ma serio: cambiare l’URL di una skill per puntare a un server di test altera il contesto di token visto dal modello. Il modello che si sta testando non è più identico, a livello di token, a quello che verrà effettivamente distribuito in produzione. Questa discrepanza introduce una variabile nascosta che può invalidare i risultati della valutazione e produrre comportamenti inattesi una volta in produzione, quando la skill torna a puntare agli URL reali.

Un approccio più efficace consiste nell’usare un proxy leggero che intercetta il traffico HTTP e restituisce dati predefiniti letti da file JSON locali, senza mai modificare gli URL che l’agente chiama. È esattamente il compito per cui è nato Dev Proxy: l’agente continua a chiamare gli URL di produzione, ma riceve risposte deterministiche senza che avvenga alcuna chiamata di rete reale né alcuna gestione di server. I dati si azzerano a ogni esecuzione, il contesto di token resta identico a quello di produzione, e diventa possibile eseguire test di regressione rigorosi all’interno di pipeline CI/CD.

Dev Proxy: simulare le API senza toccare il codice

Dev Proxy è uno strumento a riga di comando, open source e gratuito, che funziona su qualsiasi piattaforma e con qualsiasi stack tecnologico, perché intercetta le richieste di rete invece di agganciarsi al codice dell’applicazione. Le funzionalità principali coprono scenari che vanno ben oltre il semplice mocking:

• Simulare errori delle API senza modificare una riga di codice, per verificare che l’app non perda dati dei clienti quando una dipendenza esterna fallisce
• Simulare rate limiting per verificare che l’applicazione gestisca correttamente il throttling
• Simulare latenza e risposte lente per validare le protezioni lato UX
• Generare rapidamente mock API CRUD senza scrivere codice destinato a non essere mai distribuito
• Fornire guida contestuale su permessi e best practice, in particolare per chi integra Microsoft Graph

Per il caso specifico degli agenti AI, Dev Proxy include funzionalità dedicate ai language model che permettono di simulare scenari realistici e tracciare l’uso delle risorse, oltre a un tool integrato nel proprio server MCP che fornisce agli agenti di coding raccomandazioni su come costruire le configurazioni. In pratica, un team che sviluppa una skill che chiama un’API esterna può configurare Dev Proxy per intercettare quelle chiamate specifiche e restituire fixture JSON versionate insieme al codice, garantendo che ogni esecuzione della pipeline CI/CD parta da uno stato pulito e riproducibile.

Promptfoo: valutare quale versione di una skill funziona meglio

Simulare le API risolve solo metà del problema. L’altra metà è capire, in modo misurabile, se una skill fa il proprio lavoro correttamente e se una nuova versione è effettivamente migliore della precedente. È qui che entra in gioco Promptfoo, un framework di valutazione che permette di confrontare due versioni della stessa skill eseguendo gli stessi task fianco a fianco.

Il pattern di base è semplice: si mantengono identici il modello, i file di task e i permessi, cambiando solo il file SKILL.md tra una versione e l’altra. Una struttura tipica per confrontare due versioni di una skill review-standards è organizzata così:

skill-eval/
├── promptfooconfig.yaml
└── fixtures/
    ├── v1/
    │   ├── .claude/skills/review-standards/SKILL.md
    │   └── src/auth.ts
    └── v2/
        ├── .claude/skills/review-standards/SKILL.md
        └── src/auth.ts

Nel file di configurazione si definiscono due provider basati sul Claude Agent SDK, identici tranne che per la working_dir, che punta alla fixture v1 o v2:

providers:
  - id: anthropic:claude-agent-sdk
    label: review-standards-v1
    config:
      model: claude-sonnet-4-6
      working_dir: ./fixtures/v1
      setting_sources: ['project']
      skills: ['review-standards']
      append_allowed_tools: ['Read', 'Grep', 'Glob']
  - id: anthropic:claude-agent-sdk
    label: review-standards-v2
    config:
      model: claude-sonnet-4-6
      working_dir: ./fixtures/v2
      setting_sources: ['project']
      skills: ['review-standards']
      append_allowed_tools: ['Read', 'Grep', 'Glob']

Il parametro setting_sources: ['project'] fa scoprire a Promptfoo i file SKILL.md sotto .claude/skills/, mentre il filtro skills: restringe la sessione a una singola skill e ne abilita automaticamente il tool associato. Per Codex o OpenCode la struttura equivalente usa .agents/skills/ al posto di .claude/skills/, ma la logica di confronto resta identica.

Tre livelli di asserzioni per un confronto solido

Una valutazione utile si costruisce a strati. Il primo verifica semplicemente che la skill sia stata invocata:

defaultTest:
  assert:
    - type: skill-used
      value: review-standards

Claude espone le chiamate al tool Skill direttamente, e Promptfoo le normalizza nell’asserzione skill-used: questo distingue una risposta corretta ottenuta senza passare dalla skill da una prodotta effettivamente attraverso il workflow che si vuole testare, una distinzione che spesso sfugge a chi valuta solo la qualità della risposta finale.

Il secondo livello valuta la qualità del lavoro svolto, per esempio calcolando quanti problemi attesi sono stati effettivamente individuati in una revisione di codice, con una soglia di recall minima. Il terzo livello aggiunge segnali secondari come costo e latenza, utili quando due versioni sono entrambe corrette ma una è molto più lenta o costosa dell’altra:

defaultTest:
  assert:
    - type: cost
      threshold: 0.50
    - type: latency
      threshold: 120000

Per chi gestisce bundle di skill correlate, un errore comune è testare solo il percorso “felice” di ciascuna skill. Vale la pena aggiungere anche prompt limite che dovrebbero instradare verso una skill vicina, asserendo sia la skill desiderata sia quella che non deve attivarsi, con il costrutto not-skill-used. Questo cattura i casi in cui una skill risolve correttamente il task ma si attiva anche quando non dovrebbe, un problema di “routing” difficile da individuare guardando solo l’output finale.

Mettere insieme i due strumenti in CI/CD

La combinazione pratica è: Dev Proxy intercetta le chiamate API reali fatte durante l’esecuzione della skill e restituisce fixture deterministiche, mentre Promptfoo esegue lo stesso set di task contro versioni diverse della skill e assegna un punteggio ai risultati. L’eval si lancia con un semplice comando:

npx promptfoo@latest eval -c promptfooconfig.yaml

Aggiungendo --repeat 3 si ottiene un campione più robusto del comportamento non deterministico dell’agente, mentre --no-cache è utile durante l’iterazione sul testo della skill per garantire risultati sempre freschi. Il comando npx promptfoo@latest view apre una vista web che affianca i risultati delle due versioni, rendendo immediato individuare dove una skill supera l’altra.

Conclusione

Il punto centrale di entrambi gli strumenti è lo stesso: eliminare le variabili nascoste che rendono inaffidabile il test di un comportamento non deterministico. Dev Proxy garantisce che il contesto visto dal modello in test sia identico a quello di produzione, eliminando la variabile del cambio di URL. Promptfoo garantisce che il confronto tra due versioni di una skill sia equo, isolando l’unica variabile che conta — il testo della skill stessa — e fornendo asserzioni misurabili su invocazione, qualità, costo e latenza.

Per un team che già gestisce pipeline CI/CD tradizionali, l’investimento per aggiungere questo livello di test alle proprie skill AI è relativamente contenuto: entrambi gli strumenti sono open source, si integrano con gli SDK di Claude, Codex e OpenCode, e restituiscono risultati confrontabili senza richiedere infrastruttura dedicata oltre a quella già in uso per il testing tradizionale.

Fonti: 4sysops.com, Microsoft Learn – Dev Proxy, Promptfoo – Test Agent Skills

Testing AI agent skills safely using local API proxies – 4sysops

Evaluating AI agent skills that interact with APIs often introduces high costs and risks to production data integrity. Running hundreds of test scenarios agains

^{IT News (4sysops)}

Spcnet.it

2026-07-19 20:18:48

wp2shell: la RCE non autenticata in WordPress e come proteggersi (con o senza Cloudflare)

Nessun login richiesto

Il 17 luglio 2026 il team di sicurezza di WordPress ha rilasciato in silenzio, e con qualche ora di anticipo condiviso solo con i principali fornitori di infrastruttura, la patch per due vulnerabilità che insieme formano una catena di attacco particolarmente pericolosa: una SQL injection e una remote code execution non autenticata. Nessuna delle due richiede che l’attaccante possieda credenziali o interagisca con un utente reale: basta una richiesta HTTP costruita ad arte contro l’endpoint batch della REST API.

Se gestisci anche un solo sito WordPress — e in Italia sono milioni, molti dei quali proprio su blog tecnici o aziendali come questo — questa è una di quelle vulnerabilità da trattare come priorità operativa immediata, non come lettura per il weekend.

Le due CVE, in breve

Le vulnerabilità colpiscono punti diversi della catena di elaborazione di una richiesta:

• CVE-2026-60137 — SQL injection. Presente da WordPress 6.8 in poi. Un input malformato riesce ad alterare una query verso il database. Severità: Alta.
• CVE-2026-63030 — Remote Code Execution non autenticata. Presente da WordPress 6.9 in poi, e collegata direttamente alla SQL injection precedente. Sfrutta l’endpoint batch della REST API quando il sito non utilizza una cache a oggetti persistente (persistent object cache). Severità: Critica.

La combinazione delle due — nella comunità di sicurezza già ribattezzata informalmente “wp2shell” — permette a un attaccante di passare da un parametro malformato a esecuzione di codice arbitrario sul server, senza autenticazione e senza alcuna interazione da parte di amministratori o utenti.

Perché la object cache fa la differenza

Il dettaglio tecnico più interessante per chi amministra WordPress è che la RCE si manifesta specificamente quando manca una cache a oggetti persistente (tipicamente basata su Redis o Memcached). Molte installazioni WordPress “di default” — senza un livello di caching applicativo esterno a PHP — si affidano a una cache in memoria che vive solo per la durata della singola richiesta: è proprio l’assenza di persistenza a lasciare aperta la finestra che l’endpoint batch della REST API sfrutta per concatenare SQL injection ed esecuzione di codice. In altre parole, i siti più “semplici”, senza uno stack di caching avanzato, sono paradossalmente più esposti di quelli con un’infrastruttura più sofisticata.

La risposta di WordPress

Trattandosi della classe di severità più alta prevista dal team di sicurezza di WordPress, il rilascio della patch è stato accompagnato da aggiornamento automatico forzato per la maggior parte dei siti, un meccanismo che WordPress riserva solo alle emergenze più critiche. Le versioni corrette sono:

• 7.0.2 — release principale, corregge entrambe le vulnerabilità
• 6.9.5 — backport, corregge entrambe le vulnerabilità
• 6.8.6 — backport, corregge solo la SQL injection (la RCE non è presente su questo ramo)
• 7.1 Beta 2 — corregge entrambe

Le versioni precedenti alla 6.8 non risultano affette. Anche con l’aggiornamento automatico attivo, è buona norma verificare manualmente la versione installata:

# Da riga di comando, con WP-CLI
wp core version

# Oppure dalla dashboard: Bacheca → Aggiornamenti

Il ruolo del WAF: difesa in profondità, non sostituto della patch

Cloudflare, informata in anticipo dal team WordPress, ha distribuito due regole WAF dedicate alle 17:03 UTC del 17 luglio, attive automaticamente per tutti i clienti — inclusi quelli su piano gratuito — il cui traffico passa attraverso il proxy Cloudflare:

Regola	CVE	Azione predefinita
WordPress – SQL Injection	CVE-2026-60137	Block
WordPress – Remote Code Execution	CVE-2026-63030	Block

La prima regola intercetta i valori dei parametri malformati prima che raggiungano WordPress; la seconda blocca le richieste dirette verso il percorso di esecuzione del codice. Insieme coprono due punti distinti della catena di attacco. Cloudflare è però esplicita su un punto che vale la pena ribadire: le regole WAF riducono l’esposizione, non sostituiscono la patch. Chi utilizza Cloudflare su piano Pro, Business o Enterprise dovrebbe verificare che il Managed Ruleset sia attivo e che non vi siano override che trasformano l’azione da “Block” a “Log” — una configurazione non rara in ambienti dove si è voluto in passato ridurre i falsi positivi.

Checklist operativa

Per chi amministra siti WordPress, indipendentemente dal fatto che si usi o meno Cloudflare, questi sono i passi concreti da seguire subito:

• Verificare la versione di WordPress su tutte le installazioni gestite (non solo quella principale — anche i sotto-siti, gli ambienti di staging e i multisite dimenticati).
• Forzare l’aggiornamento a 7.0.2, 6.9.5 o 6.8.6 se l’auto-update non è ancora scattato:

  wp core update --version=7.0.2
  wp core update-db

• Se dietro Cloudflare: controllare in dashboard che le due regole (ID gestito 7dfb2bd4708d4b88b9911dc0550664b6 per la RCE e 1c060d3a371549219ee290d7ed933fcc per la SQLi) siano impostate su Block, e monitorare i Security Events per richieste bloccate su questi ID.
• Se non si usa un WAF: valutare regole custom su ModSecurity con OWASP CRS mirate all’endpoint /wp-json/*/batch, oppure disabilitare temporaneamente il batch endpoint tramite un mu-plugin, in attesa che l’aggiornamento venga completato su tutta la flotta:

  <?php
  // mu-plugins/disable-rest-batch.php
  add_filter('rest_pre_dispatch', function ($result, $server, $request) {
      if (strpos($request->get_route(), '/batch') !== false) {
          return new WP_Error('batch_disabled', 'Endpoint batch temporaneamente disabilitato', ['status' => 403]);
      }
      return $result;
  }, 10, 3);

• Abilitare una object cache persistente (Redis o Memcached) come mitigazione indiretta aggiuntiva, oltre ai benefici di performance che porta comunque.
• Controllare i log delle ultime settimane per richieste sospette verso gli endpoint REST batch, prima di considerare l’incidente chiuso.

In conclusione

Questa vicenda è un promemoria utile su due fronti. Il primo è tecnico: un endpoint REST pensato per efficienza (il batching di più operazioni in un’unica chiamata) può diventare superficie di attacco se la validazione dei parametri non è sufficientemente rigorosa lungo tutta la catena. Il secondo è organizzativo: la differenza tra un incidente e un mancato incidente, in casi come questo, si misura in ore — quelle tra la disclosure coordinata e la disponibilità pubblica dei dettagli, durante le quali chi ha automatizzato patching e monitoraggio dorme sonni più tranquilli di chi deve intervenire manualmente su decine di installazioni.

Fonte: The Cloudflare Blog.

Cloudflare WAF protects WordPress applications from two high-severity vulnerabilities

Cloudflare has deployed two WAF rules in response to high-severity vulnerabilities disclosed to us by the WordPress security team.

^{The Cloudflare Blog}

Spcnet.it

2026-07-19 20:18:46

MCP 2026-07-28: il Model Context Protocol diventa stateless, ecco cosa cambia per chi sviluppa agenti AI

Il 28 luglio 2026 entra in vigore la nuova revisione della specifica Model Context Protocol (MCP), lo standard aperto introdotto da Anthropic che permette ai modelli AI di collegarsi in modo sicuro a strumenti e sorgenti dati esterne. Non si tratta di un aggiornamento cosmetico: la revisione 2026-07-28 ridisegna il nucleo del protocollo, passando da un modello con stato a uno completamente stateless, e introduce cambiamenti che toccano direttamente chi progetta, ospita o consuma server MCP in produzione.

Per chi lavora con agenti AI e integrazioni enterprise, questa è una di quelle revisioni che vale la pena capire in dettaglio prima che arrivi la versione finale, perché tocca scalabilità, autenticazione e compatibilità con le versioni precedenti.

Dal protocollo con stato al core stateless

Nelle versioni precedenti di MCP, un client doveva eseguire un handshake initialize prima di poter fare qualsiasi cosa: il server rispondeva con un identificatore di sessione da includere in ogni richiesta successiva. Chi ha provato a mettere in produzione un server MCP dietro un load balancer conosce il problema: il client restava “incollato” a una specifica istanza, e scalare orizzontalmente richiedeva sticky session o uno store di sessione condiviso.

La revisione 2026-07-28 elimina sia l’handshake initialize sia il concetto stesso di sessione a livello di protocollo. Ogni richiesta è ora autosufficiente: versione del protocollo, informazioni sul client e capability dichiarate viaggiano in ogni singola chiamata invece di essere negoziate una volta sola all’apertura della connessione. Un nuovo metodo, server/discover, permette al client di recuperare le capability del server solo quando gli servono davvero.

La conseguenza pratica è che, non esistendo più un identificatore di sessione, qualsiasi richiesta può essere instradata verso qualunque istanza del server. Diventa possibile piazzare un server MCP dietro un banale load balancer round-robin, senza sticky session né store condiviso. Se un’applicazione ha comunque bisogno di mantenere uno stato tra una chiamata e l’altra, la soluzione prevista è restituire un handle esplicito (ad esempio un ID di un “carrello” o di una sessione applicativa) da uno strumento, e far sì che il client lo passi indietro come un normale argomento nelle chiamate successive. È lo stesso pattern usato da anni nelle API REST stateless: lo stato non sparisce, si sposta semplicemente dal trasporto al payload applicativo.

Multi Round-Trip Requests: confermare senza tenere aperta una connessione

Un protocollo stateless ha comunque bisogno di un modo per gestire i casi in cui un server deve chiedere qualcosa al client a metà di una chiamata, per esempio una conferma dell’utente prima di eseguire un’operazione sensibile. Nelle versioni precedenti questo richiedeva tenere aperto uno stream Server-Sent Events per tutta la durata dell’interazione. La nuova revisione sostituisce questo meccanismo con le Multi Round-Trip Requests (MRTR).

Quando un server ha bisogno di input dall’utente durante l’esecuzione di uno strumento, restituisce un oggetto InputRequiredResult contenente le domande da porre e un blob requestState. Il client raccoglie le risposte e riemette la chiamata originale includendo sia le risposte sia lo stato “echoed” ricevuto in precedenza. Poiché tutto ciò che serve al server è contenuto nel payload, qualunque istanza del server può gestire il retry, anche se è diversa da quella che ha generato la richiesta iniziale. È un dettaglio che semplifica enormemente il deployment di server MCP dietro infrastrutture di bilanciamento del carico stateless.

Header instradabili e caching esplicito

Due modifiche più contenute a livello di trasporto rendono il traffico MCP molto più facile da osservare e instradare in produzione. Il trasporto Streamable HTTP richiede ora un header Mcp-Method su ogni richiesta, mentre l’header Mcp-Name è obbligatorio solo per tipi di richiesta specifici, come tools/call, resources/read e prompts/get. Un gateway o un load balancer può leggere questi header per instradare il traffico senza dover analizzare il corpo della richiesta, un vantaggio non trascurabile per chi gestisce infrastrutture MCP a scala aziendale. I server rifiutano le richieste in cui header e corpo non sono coerenti tra loro.

In secondo luogo, i risultati di liste e letture di risorse ora includono i campi ttlMs e cacheScope, modellati sul comportamento dell’header HTTP Cache-Control. I client sanno esattamente per quanto tempo una risposta a tools/list resta valida e se può essere condivisa tra utenti diversi. Non è più necessario mantenere uno stream a lungo termine solo per scoprire che una lista è cambiata: un pattern di polling con cache esplicita è sufficiente.

Autenticazione più rigorosa, allineata a OAuth 2.0

La revisione stringe le regole di autorizzazione per allinearle più da vicino a OAuth 2.0 e OpenID Connect. I client devono ora validare il parametro iss nelle risposte di autorizzazione secondo la RFC 9207, una mitigazione contro i “mix-up attack”, una classe di attacchi più rilevante nel pattern tipico di MCP in cui un singolo client dialoga con molti server diversi.

I client devono inoltre dichiarare il proprio application_type durante la Dynamic Client Registration, così gli authorization server non assumono più di default che i client desktop o CLI siano applicazioni “web”, evitando il rifiuto ingiustificato dei redirect URI su localhost. Le credenziali vengono vincolate all’authorization server che le ha emesse, e la specifica chiarisce come richiedere i refresh token durante l’autenticazione step-up.

Funzionalità deprecate: cosa cambia per chi ha già integrato MCP

Tre funzionalità core vengono formalmente deprecate: Roots, Sampling e Logging. Roots permetteva a un client di dichiarare i confini del filesystem a un server; Sampling permetteva a un server di chiedere al modello del client di generare testo per suo conto; Logging forniva notifiche a livello di protocollo dal server al client.

La deprecazione non significa rimozione immediata: questi metodi, tipi e capability flag continuano a funzionare in questa release e in ogni versione della specifica pubblicata entro un anno da essa. Da qui in poi, però, sono su un orologio di rimozione. Le alternative consigliate sono parametri degli strumenti o URI di risorse al posto di Roots, integrazione diretta con le API dei provider LLM al posto di Sampling, e OpenTelemetry per l’osservabilità strutturata al posto del Logging di protocollo. Chi mantiene librerie o server MCP dovrebbe iniziare a pianificare la migrazione già da ora.

Schema degli strumenti, codici di errore ed estensioni

Gli schema di input e output degli strumenti utilizzano ora JSON Schema 2020-12 completo. Gli schema di input mantengono il vincolo della radice type: "object" ma ora permettono composizione con oneOf, anyOf e allOf, oltre a condizionali e riferimenti. Gli schema di output non hanno più restrizioni, e structuredContent può essere qualsiasi valore JSON, non solo un oggetto.

Il codice di errore per una risorsa mancante cambia dal valore custom MCP -32002 allo standard JSON-RPC -32602 (Invalid Params). Chi ha client che fanno pattern matching sul valore letterale -32002 deve aggiornare quel codice prima del 28 luglio.

Le estensioni, già presenti nella release precedente ma senza un processo formale, ricevono ora una struttura definita: sono identificate da ID reverse-DNS, negoziate tramite una mappa extensions, e vivono in repository indipendenti con maintainer dedicati, versionando separatamente dalla specifica principale. Due estensioni ufficiali arrivano con questa release: MCP Apps, che permette ai server di fornire interfacce HTML interattive renderizzate dagli host in un iframe sandboxed, e Tasks, promossa da funzionalità sperimentale a estensione ufficiale, che fornisce un modello stateless per lavori a lunga esecuzione: un server può rispondere a tools/call con un task handle, e il client lo gestisce con tasks/get, tasks/update e tasks/cancel.

SDK beta disponibili da subito

Sono già disponibili release beta degli SDK Python, TypeScript, Go e C#. Python v2 rinomina FastMCP in MCPServer ma mantiene l’API a decoratori. TypeScript v2 divide l’SDK monolitico in pacchetti focalizzati come @modelcontextprotocol/server e @modelcontextprotocol/client, ed è ora ESM-only. Go integra il supporto alla revisione 2026-07-28 in v1.7.0-pre.1 sullo stesso module path. C# rilascia la versione 2.0.0-preview.1 dei pacchetti ModelContextProtocol.

Per chi ha già server e client in produzione, la buona notizia è che nulla si rompe automaticamente il giorno del rilascio: i nuovi client che parlano la revisione 2026-07-28 tornano automaticamente all’handshake initialize quando raggiungono un server che implementa una versione precedente o uguale al 2025-11-25. Chi però pubblica librerie che dipendono dal pacchetto Python mcp dovrebbe aggiungere un limite superiore esplicito, per esempio mcp>=1.27,<2, in modo che il passaggio alla v2 stabile non colga di sorpresa gli utenti del proprio pacchetto.

Conclusione

La revisione 2026-07-28 di MCP è un cambiamento strutturale, non un semplice aggiornamento incrementale. Il core stateless elimina la necessità di session affinity e semplifica scaling orizzontale e load balancing di server MCP in produzione. I nuovi pattern come le MRTR e gli header instradabili rendono il protocollo più facile da operare su larga scala. L’irrigidimento delle regole di autorizzazione allinea MCP alle pratiche standard di OAuth e OpenID Connect, riducendo la superficie di attacco tipica delle integrazioni multi-server. Le funzionalità deprecate restano funzionanti per ora, ma vanno sostituite secondo un piano preciso prima che scada la finestra di un anno.

Chi sviluppa o ospita server MCP dovrebbe testare gli SDK beta contro i propri carichi di lavoro prima della data finale del 28 luglio, verificando in particolare la gestione dei codici di errore, la compatibilità dei client con l’handshake legacy e l’impatto delle nuove regole di autorizzazione sulle integrazioni desktop e CLI esistenti.

Fonte: 4sysops.com

2026-07-28 Model Context Protocol (MCP): stateless, multi-round-trip, routable headers, authorization hardening – 4sysops

The Model Context Protocol (MCP) specification dated July 28, 2026, introduces the largest revision of the protocol since its launch. The update transitions the

^{IT Experts (4sysops)}