Oggi, 21 ottobre, molti advertiser ricevono lo stesso messaggio dallo sviluppatore: il sito deve andare offline per applicare le patch PHP. Le campagne però stanno ancora mandando traffico a pagamento verso quelle landing page. Bisogna decidere se mettere in pausa o lasciar correre, e capire cosa vedranno nel frattempo i crawler di Google. Su quest’ultimo punto c’è un’indicazione chiara: secondo il post di Google Search Central su LinkedIn, servire un codice di stato HTTP 503 (Service Unavailable) fa sì che gli URL già indicizzati vengano preservati in Search mentre si lavora. Resta il fatto che per chi spende il fermo non è solo una questione tecnica. È una questione di allocazione del budget, e va gestita con lo stesso rigore con cui si imposta un’offerta.

Patch uscite oggi, nessuno escluso

Il fermo non è facoltativo. Come riporta l’avviso di sicurezza del CERT-EU, il team PHP ha rilasciato oggi alle 13:30 UTC le correzioni per due vulnerabilità critiche, contenute nelle versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Entrambe le falle possono consentire l’esecuzione di codice remoto senza autenticazione: un attaccante non ha bisogno di credenziali per prendere il controllo del server. Il perimetro è molto ampio. Secondo l’analisi di Help Net Security sulle CVE-2026-109618 e CVE-2026-109619, è coinvolta ogni installazione PHP che serve richieste web, comprese quelle basate su PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Le configurazioni con mod_php sono quelle più esposte. Se il vostro e-commerce o le vostre landing girano su PHP, l’aggiornamento riguarda anche voi.

Davanti a un intervento obbligato, molti sceglieranno la strada più comoda: attivare la modalità manutenzione dal pannello del CMS e considerare il problema risolto. È qui che nascono gli errori.

La modalità manutenzione che non protegge niente

La reazione istintiva di chi gestisce un sito WordPress o Magento è “metto in manutenzione e sono a posto”. Non è così. Secondo la ricerca pubblicata da Sansec, le modalità di manutenzione integrate in Magento e WordPress non aiutano, perché PHP analizza ogni richiesta prima che l’applicazione verifichi il flag di manutenzione. La pagina “torniamo presto” sembra una protezione, ma la vulnerabilità viene raggiunta prima ancora che il CMS decida di mostrarla. Dal punto di vista della sicurezza, quindi, la modalità manutenzione è una falsa protezione.

C’è anche il rischio opposto, sul fronte della ricerca organica. Molte soluzioni di manutenzione improvvisate restituiscono una pagina di cortesia con status 200, oppure un 404 generico. Google Search Central chiede esplicitamente di evitare entrambe le opzioni durante un downtime. Una pagina di errore con status 200 dice al crawler che quel contenuto vuoto è la pagina vera. Un 404 dice che la pagina non esiste più. Il segnale corretto è il 503, l’unico che comunica un’indisponibilità temporanea.

Anche il 503 però ha un limite di tempo. La documentazione di Google sugli errori HTTP e di rete spiega che gli errori server 5xx e i 429 portano i crawler a rallentare temporaneamente la scansione. Gli URL già indicizzati restano nell’indice, ma alla fine vengono rimossi. La guida di Google sul downtime pianificato è altrettanto netta: un 503 che si protrae nel tempo può essere letto come il segnale che il server è diventato indisponibile in modo permanente, con la conseguente rimozione degli URL dall’indice. I tempi sono stretti su due fronti. Bisogna patchare in fretta per chiudere la falla e riaprire in fretta per non perdere posizioni.

Spegnere, filtrare, e cosa fare con il budget

Se la modalità manutenzione non serve e il 503 ha una scadenza, chi ha un livello di protezione davanti al server ha un’alternativa. Secondo il CTO di Cloudflare, Dane Knecht, l’azienda ha distribuito regole WAF la stessa mattina. Una WAF (web application firewall) filtra le richieste malevole prima che raggiungano PHP, cioè agisce proprio nel punto in cui la modalità manutenzione arriva troppo tardi. Per chi è già dietro un servizio di questo tipo, il fermo totale può ridursi al tempo strettamente necessario per installare le nuove versioni, oppure essere pianificato con meno urgenza. Chi non ha una WAF non ha questa opzione e deve mettere in conto uno stop reale.

Lato Search, la ripresa è semplice: quando il server torna a servire risposte 200, la situazione rientra da sola alla normalità. Lato paid, invece, nessuno compensa le ore perse. Ogni ora di 503 è un’ora in cui i clic a pagamento atterrano su una pagina che non converte. Il CPC (costo per clic) lo pagate comunque, mentre le conversioni sono zero. Il risultato è un CPA (costo per acquisizione) più alto e un ROAS (ritorno sulla spesa pubblicitaria) peggiore, che si scaricano sui report e sugli algoritmi di offerta automatica. Ecco i passaggi concreti da concordare oggi con lo sviluppatore:

  • stabilire la finestra esatta della patch;
  • verificare che durante il fermo il server risponda con un vero 503 e non con una pagina di manutenzione in 200;
  • verificare se una WAF già attiva permette di evitare o accorciare lo stop;
  • mettere in pausa, per quella finestra, le campagne e i gruppi di annunci che puntano alle landing coinvolte.

Un fermo per una patch di sicurezza non riguarda più solo lo sviluppatore: è una decisione di allocazione. Chi gestisce campagne deve sapere già oggi quando il sito risponderà 503, per quanto tempo e se una WAF può evitare del tutto lo stop. Altrimenti si ritrova a pagare clic verso pagine che nemmeno Google aspetterà a lungo.