#wespenspinne #ArgiopeBruennichi #waspSpider #spinne #spider #naturephotography #macrophotography #makrofotografie #naturfotografie #smallanimal #arachnida #WildlifePhotography #Spinnenliebe #Arthropods #photography #fotografie #naturelovers #Spinnennetz #web #spiderweb #spidersNet #stabilimentum #beautyofnature #naturephotographer #Meadow #wiese #nature #detail #closeup #closeupphotography #animalphotography #summer

Il problema degli agenti AI che “guardano” il browserChi ha provato a far navigare un agente AI su un sito #web sa quanto sia fragile il paradigma attuale: screenshot della pagina, #analisi visiva per capire dove cliccare, simulazione del click, nuovo screenshot per verificare cosa è successo, e via così ad ogni passaggio. Funziona, ma è lento, costoso in token e si rompe alla prima modifica del layout o al primo elemento che carica in ritardo. È lo stesso problema che affligge da anni gli script di web scraping tradizionali, solo applicato ad agenti che devono anche “capire” cosa stanno guardando.

WebMCP (Web Model Context Protocol) nasce per rovesciare questo approccio: invece di far indovinare all’agente dove cliccare, è il sito stesso a dichiarare quali azioni sono disponibili, con che parametri, e come invocarle direttamente in codice. #Cloudflare ha da poco reso disponibile il supporto sperimentale a WebMCP nella sua piattaforma #Browser Run, un’occasione utile per capire come funziona davvero questo standard ancora in bozza.

Cos’è WebMCP e chi lo sta sviluppandoLa proposta iniziale è stata pubblicata nell’agosto 2025 da ingegneri di Microsoft e #Google, e oggi è portata avanti principalmente dal team #Chrome come bozza sperimentale — non è ancora uno standard web consolidato, ma è già implementabile e testabile in Chrome beta. L’idea centrale è una nuova API del browser, navigator.modelContext, che qualsiasi pagina web può usare per registrare “tool” strutturati, nello stesso spirito del Model Context Protocol usato da Claude e altri assistenti per esporre funzionalità a un LLM — solo che qui il “server” #MCP è JavaScript in esecuzione lato pagina, e l’host è il browser stesso.

navigator.modelContext.registerTool({
name: "scroll_to_section",
description: "Scorre la pagina fino a una sezione specifica",
inputSchema: {
type: "object",
properties: { id: { type: "string" } },
required: ["id"]
},
async execute({ id }) {
document.getElementById(String(id))?.scrollIntoView({ behavior: "smooth" });
return "ok";
}
});Un agente che visita la pagina può interrogare l’elenco dei tool disponibili in un dato momento — che cambia dinamicamente in base allo stato della pagina — ed eseguirli con parametri tipizzati, invece di simulare interazioni DOM.

Provarlo con Cloudflare Browser RunCloudflare ha aggiunto un pool sperimentale di sessioni browser con Chrome beta (dove WebMCP è disponibile) alla sua piattaforma Browser Run, separato dal pool di produzione che resta su Chrome stabile. Per avviare una sessione di test basta la CLI wrangler:

assicurarsi di avere l'ultima versione di wrangler

npm i -g wrangler@latest

creare una sessione browser "lab" con keep-alive di 5 minuti

wrangler browser create --lab --keepAlive 300Dalla console DevTools della sessione si può interrogare direttamente l’elenco dei tool esposti da un sito che implementa WebMCP (Cloudflare fornisce come demo pubblica una finta catena di hotel):

navigator.modelContextTesting.listTools();
// [
// { "name": "view_hotel", "description": "...", "inputSchema": "..." },
// { "name": "search_location", "description": "...", "inputSchema": "..." },
// { "name": "lookup_amenity", "description": "...", "inputSchema": "..." }
// ]Eseguire un tool è altrettanto diretto:

await navigator.modelContextTesting.executeTool(
"search_location",
JSON.stringify({ query: "Paris" })
);Un dettaglio interessante per chi progetta flussi che coinvolgono azioni sensibili (pagamenti, prenotazioni, conferme): la specifica prevede nativamente lo human-in-the-loop. Un tool come complete_booking può sospendere l’esecuzione in attesa che l’utente confermi manualmente un’azione nell’interfaccia, prima di restituire il risultato all’agente.

Collegare un agente AI realePer far interagire un vero agente con siti WebMCP, Cloudflare consiglia di appoggiarsi a Chrome DevTools MCP, configurabile in client come Claude Code o Cursor puntando al WebSocket endpoint della sessione lab:

{
"browser-rendering-cdp": {
"command": [
"npx", "-y", "chrome-devtools-mcp@latest",
"--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/devtools/browser?keep_alive=600000&lab=true",
"--wsHeaders={"Authorization":"Bearer <CLOUDFLARE_API_TOKEN>"}"
]
}
}Il parametro lab=true è ciò che instrada la connessione verso una sessione con WebMCP abilitato invece che verso il pool di produzione standard.

Il lato server: esporre i tool di un Worker al browserPer chi già costruisce agenti su Cloudflare Workers usando McpAgent, il pacchetto agents include un adapter sperimentale, registerWebMcp, che fa da ponte tra i tool esposti da un server MCP remoto e il registro navigator.modelContext della pagina:

import { registerWebMcp } from "agents/experimental/webmcp";

const handle = await registerWebMcp({
url: "/mcp",
prefix: "remote.",
getHeaders: async () => ({ Authorization: Bearer ${await getToken()} })
});L’adapter scopre i tool del server (tools/list), li registra come shim locali il cui execute inoltra la chiamata al server via client.callTool(), e si mantiene sincronizzato ascoltando le notifiche tools/list_changed. Il risultato pratico è una separazione naturale: tutto ciò che riguarda il DOM (scorrimento, focus, clipboard, stato locale in Zustand o IndexedDB) resta tool in-page; tutto ciò che richiede storage durevole, credenziali segrete o chiamate a API di terze parti resta lato server, ma diventa comunque visibile e invocabile dall’AI del browser attraverso lo stesso registro.

Cosa considerare prima di adottarloVale la pena essere chiari sulla maturità dello standard: le API navigator.modelContext e navigator.modelContextTesting funzionano oggi solo in sessioni Chrome beta o “lab”, non in produzione stabile, e sia la specifica sia l’adapter di Cloudflare sono etichettati esplicitamente come sperimentali, soggetti a modifiche non retrocompatibili. Sul fronte sicurezza, esporre tool strutturati a un agente terzo significa anche esporre una superficie potenzialmente sfruttabile — collisioni di nomi tra tool silenziose, o un agente compromesso che invoca un tool con parametri malevoli, sono scenari da considerare al pari di qualsiasi altra API pubblica. Per chi sviluppa siti pensati per essere “agent-friendly” — e-commerce, prenotazioni, dashboard SaaS — è comunque il momento giusto per iniziare a sperimentare, prima che il pattern diventi lo standard de facto per l’interazione tra agenti AI e web.

ConclusioneWebMCP propone un cambio di paradigma sensato: far dichiarare alle applicazioni web le proprie capacità in modo strutturato, invece di costringere gli agenti AI a reverse-engineering visivo dell’interfaccia. Non è ancora pronto per la produzione, ma la direzione — supportata sia da Google sia da Microsoft, e ora testabile concretamente su Cloudflare Browser Run — merita di essere seguita da chi sviluppa applicazioni web che prima o poi dovranno “parlare” anche con un agente, non solo con un umano davanti a un browser.

Fonte: Cloudflare Browser Run Docs – WebMCP e Cloudflare Agents – WebMCP adapter

My eyes hurt after the eclipse

Searches for “eclipse hurt eyes” jumped 170% in the last 24 hours after the eclipse yesterday evening. Ouch. I hope those people didn’t stare too long and that no permanent damage was done. The sky was cloudy where I live, but I still managed to get a photo, even if it was only with myContinue reading

https://odd.blog/2026/08/13/my-eyes-hurt-after-the-eclipse/
#cloud #eclipse #google #photo #Photography #Sun #Web

A Black Hat #USA 2026 il ricercatore di PortSwigger Gareth Heyes ha presentato una raccolta di tecniche che sfruttano il CSS per rompere il confine di sicurezza tra il contenuto di un’email e l’interfaccia della webmail che lo visualizza. Il lavoro, intitolato “CSS: the bomb inside your inbox”, dimostra catene di attacco funzionanti contro Outlook, #Gmail, Yahoo Mail, AOL Mail, Fastmail e Proton Mail, capaci di catturare #password, rubare token di sessione, dirottare azioni dell’interfaccia e persino manipolare gli assistenti AI collegati alla casella di posta.

Per chi amministra sistemi di posta aziendali, gestisce client webmail personalizzati o integra connettori email in strumenti AI, si tratta di una ricerca da conoscere: non è un singolo bug da patchare, ma una classe di vulnerabilità che nasce da un problema architetturale ricorrente.

Il problema di fondo: un confine che il browser non conosceLe webmail moderne sanificano l’HTML delle email in arrivo per impedire l’esecuzione di script, ma devono comunque permettere una quantità significativa di CSS per preservare la formattazione (colori, layout, media query per la resa su mobile). Il CSS, però, non è “innocuo” quanto sembra: può leggere lo stato del DOM, condizionare la visibilità di elementi in base a selettori d’attributo, generare richieste di rete (per immagini e font) e persino inferire il contenuto testuale di un elemento carattere per carattere.

Heyes distingue due strategie generali:

Abuso diretto di HTML e CSS che la webmail permette esplicitamente (selettori, media query, image-set(), elementi ).

Discrepanza tra sanitizer e #browser: il sanificatore approva un markup ritenendolo sicuro, ma il motore di rendering o il JavaScript dell’applicazione lo trasforma in qualcosa di diverso da quanto previsto.

Entrambe le strade permettono al contenuto di un messaggio non fidato di “uscire” dal proprio confine e interferire con l’interfaccia fidata che lo circonda.

Le catene di attacco dimostrateOutlook: un menu a tendina travestito da campo passwordNella catena più sofisticata, elementi consentiti dal sanitizer vengono usati per attivare controlli esterni al messaggio. Il JavaScript applicativo di Outlook trasforma poi attributi personalizzati “sanificati” in nuovi nodi del DOM che portano con sé CSS fuori dalla lista consentita dal sanitizer, e un trucco nel parsing delle media query fornisce infine CSS arbitrario. Il risultato è un mascherato visivamente da campo password: poiché #Firefox azzera il timer di selezione delle opzioni (circa un secondo) quando il menu esce dallo schermo, l’attacco riesce a catturare quasi in tempo reale ciò che la vittima digita, ricostruendo una schermata di login Microsoft credibile.

Yahoo e AOL: furto di token via race condition sul copia-incollaSu Firefox, l’HTML incollato negli appunti può mantenere per un breve istante il CSS attivo prima che il sanificatore intervenga. Nella dimostrazione, l’attaccante avvia un flusso di login via email su Medium, la vittima copia del CSS fornito dall’attaccante e lo incolla in una bozza Yahoo o AOL: le richieste generate rivelano abbastanza cifre del token di login a 12 caratteri da permettere all’attaccante di ricostruirlo e autenticarsi come la vittima.

Exfiltration via click quando CSP blocca le risorse esterneQuando la Content Security Policy impedisce richieste verso domini esterni, il paper introduce una tecnica alternativa basata sul click: dato un token numerico visualizzato come testo nell’email, il CSS iniettato può determinare quali cifre compaiono e con quale frequenza, nascondere i link che non corrispondono e lasciare visibile solo quello corretto. Un singolo click della vittima invia cifre e frequenza al server dell’attaccante.

Quando il bersaglio è l’AI, non l’utenteLa parte più rilevante per chi lavora con assistenti AI collegati alla posta è la catena su Gmail: il fallback di image-set() genera una richiesta esterna nonostante la sanificazione. Heyes e il collega Pete Hendy l’hanno incatenata a una prompt injection indiretta processata da un assistente AI collegato via connettore Gmail: dopo che l’attaccante ha innescato un’email di conferma token Slack e la vittima ha chiesto all’assistente di processare la posta, le istruzioni iniettate hanno fatto recuperare il token e inserirlo in una bozza HTML, che lo ha esposto alla semplice visualizzazione.

Una dimostrazione su Fastmail ha colpito un browser AI: pseudo-elementi CSS e opacità rendevano visibile all’utente solo testo innocuo, mentre il modello leggeva istruzioni nascoste. Quando l’utente chiedeva di tradurre il testo visibile, il prompt nascosto faceva aprire tab e codificare dati nei frammenti URL.

Cosa è stato corretto (e cosa no)Alla data della pubblicazione della ricerca (6 agosto 2026), Fastmail aveva corretto due bug di mutazione CSS e il bypass del proxy di Proton Mail non funzionava più al retest. Il label-jacking su Outlook e il bypass image-set() su Gmail risultavano invece ancora funzionanti, e il paper non specifica se l’intera catena di cattura password su Outlook sia stata risolta. I proof-of-concept sono pubblici su repository #GitHub del team PortSwigger.

Le contromisure per chi gestisce infrastrutture di postaLe raccomandazioni della ricerca, applicabili sia a chi sviluppa client webmail sia a chi ne valuta la postura di sicurezza, si riassumono in cinque punti:

Isolamento rigoroso: rendere l’HTML delle email in un iframe sandboxed, separato dal contesto dell’applicazione principale.

Allowlist di caratteri per la validazione CSS, non semplici blocklist di proprietà pericolose.

Verifica dei “CSS gadget” prima di permettere attributi personalizzati che il JavaScript applicativo potrebbe trasformare in markup non sanificato.

Blocco di elementi e selettori pericolosi (attributo, sibling, media query complesse) nel contenuto delle email.

Prevenzione delle richieste immagine controllate dall’attaccante, con proxy per le immagini remote e allowlist di domini stretta.

Per chi integra assistenti AI con connettori email (Gmail, Outlook, Slack), vale inoltre la pena trattare ogni contenuto proveniente dalla posta come potenzialmente ostile nei confronti del modello, non solo dell’utente umano: la prompt injection indiretta via CSS dimostra che la superficie di attacco si è spostata anche sull’agente stesso.

ConclusioneQuesta ricerca conferma un pattern che si ripete da anni nella sicurezza web: qualsiasi linguaggio dichiarativo abbastanza espressivo da controllare visibilità, layout e generazione di richieste di rete può essere usato per exfiltrare dati, anche senza esecuzione di JavaScript. Con l’aggiunta di assistenti AI che leggono e agiscono sulla posta, il perimetro da difendere si allarga: non basta più proteggere l’utente dalla pagina, bisogna proteggere anche il modello dal contenuto che gli viene dato in pasto.

Fonte: The Hacker News – “New CSS Attacks Can Break Webmail Defenses to Steal Passwords and Tokens”, ricerca originale di Gareth Heyes su PortSwigger Research.

A Spined micrathena being lovely

#nature #naturephotography #wildlifephotography #michigan #animals #wildlife #photography #spider #spiders #arachnid #arachnids #web

Spider season's here
Summer condo move-in day
Ready for breakfast

#Haiku #OneHaikuADay #WritersCollective #writingcommunity #BackToHaiku #Summer #Spider #Spiders #Arachnids #Web #Fauna #Nature #Ohio #USA #Photography #2026

August 6, 2026

Nessun login richiestoIl 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 breveLe 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 differenzaIl 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 WordPressTrattandosi 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 → AggiornamentiIl ruolo del WAF: difesa in profondità, non sostituto della patchCloudflare, 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:

RegolaCVEAzione predefinitaWordPress – SQL InjectionCVE-2026-60137BlockWordPress – Remote Code ExecutionCVE-2026-63030BlockLa 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 operativaPer 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: