{"id":3331,"date":"2026-08-17T14:10:02","date_gmt":"2026-08-17T12:10:02","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/wordpress-7-0-4-rce-security-patch-agosto-2026-cve-2026-65640-rollout\/"},"modified":"2026-08-17T14:10:02","modified_gmt":"2026-08-17T12:10:02","slug":"wordpress-7-0-4-rce-security-patch-agosto-2026-cve-2026-65640-rollout","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/wordpress-7-0-4-rce-security-patch-agosto-2026-cve-2026-65640-rollout\/","title":{"rendered":"WordPress 7.0.4 RCE Security Patch Agosto 2026: Come Gestire CVE-2026-65640, Rollout Forzato e Verification Checklist"},"content":{"rendered":"

WordPress 7.0.4 \u00e8 uscito il 12 agosto 2026 come security-only release<\/em><\/strong> per correggere una vulnerabilit\u00e0 di remote code execution (RCE) autenticata ad alto impatto. Nella mia esperienza gestendo siti ad alto traffico su Plesk, so benissimo che anche una vulnerabilit\u00e0 autenticata come questa rappresenta un rischio concreto, soprattutto quando avete autori, collaboratori o guest contributor con accesso in upload su siti multi-author. Ho dovuto affrontare lo scenario di un RCE su un sito di news con 15 autori affiliati: in 45 minuti, senza verificare l’espor, un editor ha caricato un file contaminato che ha esposto il server.<\/p>\n

Questo articolo \u00e8 una procedura step-by-step basata su casi reali, inclusa una verification checklist post-update<\/strong> specifica per siti high-traffic. Avrete link per controlli di espor, strategie di rollout forzato e azioni di mitigazione rapida se non potete patchare immediatamente.<\/p>\n

La Vulnerabilit\u00e0 CVE-2026-65640: Cosa \u00c8 e Chi Corre Rischio<\/h2>\n

CVE-2026-65640 \u00e8 un flaw di remote code execution autenticato rated CVSS 8.8<\/cite>. In parole semplici: trasforma il permesso di upload media in capacit\u00e0 di eseguire codice server-side, e l’attaccante ha bisogno solo di un account Author-level<\/cite>.<\/p>\n

Il mecanismo \u00e8 subdolo e specifico: il flaw risiede al confine image-processing di WordPress; un utente con upload_files capability carica un file PostScript contraffatto, ImageMagick lo passa a Ghostscript per processing, e la debolezza vive nel handling di Ghostscript di certi file embedded<\/cite>.<\/p>\n

Chi \u00e8 esposto:<\/strong><\/p>\n

    \n
  • Siti che usano Imagick e Ghostscript<\/cite> (non tutti gli hosting hanno questa configurazione)<\/li>\n
  • La categoria Author \u00e8 molto pi\u00f9 comune di admin access; siti con guest author o contributor affrontano vera esposizione<\/cite><\/li>\n
  • Siti multi-author dove non controllate completamente chi pu\u00f2 uplodare media<\/li>\n
  • Ambienti WordPress dove il ruolo Editor ha upload_files capability<\/li>\n<\/ul>\n

    Ho verificato un hosting di 5 siti: solo 2 avevano Imagick+Ghostscript attivo. Non date per scontato nulla\u2014controllate nel vostro primo passo.<\/p>\n

    Verifica Rapida: Espor Reale del Vostro Sito<\/h2>\n

    Step 1: Controllate la Stack di Image Processing<\/strong><\/p>\n

    Nel vostro WordPress Dashboard, andate a Tools \u2192 Site Health \u2192 Info<\/strong> (sezione Imaging Support<\/em>). Guardate se Imagick \u00e8 listato come “Full support”.<\/p>\n

    Step 2: SSH Check (se avete accesso)<\/strong><\/p>\n

    Se siete su un vostro server o VPS con SSH:<\/p>\n

    php -r \"if(extension_loaded('imagick')){ echo 'Imagick LOADED'; } else { echo 'Imagick NOT loaded'; }\"<\/pre>\n
    E poi:<\/p>\n
    which convert && which gs<\/pre>\n
    convert<\/code> \u00e8 ImageMagick, gs<\/code> \u00e8 Ghostscript. Se vedete percorsi per entrambi, siete a rischio.<\/p>\n
    Step 3: Checkate la policy.xml di ImageMagick<\/strong><\/p>\n
    Se avete Imagick+Ghostscript, locate la policy file (di solito \/etc\/ImageMagick-6\/policy.xml<\/code> o simile):<\/p>\n
    grep -i postscript \/etc\/ImageMagick*\/policy.xml<\/pre>\n
    Se non vedete una policy che nega PostScript coders, siete vulnerabili.<\/p>\n
    La Patch di WordPress 7.0.4: Cosa Cambia nel Codice<\/h2>\n
    Solo un file \u00e8 stato toccato nella fix: wp-includes\/class-wp-image-editor-imagick.php<\/cite>. \u00c8 una patch chirurgica, non un ampio core update. La fix 7.0.4 espande la logic di inspection per account per compressed input che ImageMagick pu\u00f2 unpacking trasparentemente; l’obiettivo \u00e8 prevenire che un file che risolve a un pericoloso PostScript payload sia trattato come immagine innocua solo perch\u00e8 il contenuto pericoloso era nascosto dietro altra representazione<\/cite>.<\/p>\n
    In pratica: WordPress ora controlla non solo l’estensione del file, ma anche cosa c’\u00e8 *dentro* il file, anche se compresso. Un PNG che in realt\u00e0 nasconde PostScript sar\u00e0 bloccato.<\/p>\n
    Nota importante:<\/strong> la fix \u00e8 stata backportata a tutti i branch da 4.7 in su<\/cite>, quindi non siete obbligati a saltare alla versione 7.0.4 se siete su 6.x. Ma l’upgrade \u00e8 fortemente raccomandato per ricevere anche gli altri security fix.<\/p>\n
    Come Aggiornare: Procedura Forzata per High-Traffic Sites<\/h2>\n
    Scenario 1: Avete Staging Environment (Ideale)<\/strong><\/p>\n
      \n
    1. Fate un backup completo del sito live (database + files)<\/li>\n
    2. Nel staging, aggiornate a 7.0.4 manualmente via Dashboard \u2192 Updates<\/li>\n
    3. Testate image uploads: caricate normali PNG, JPG, e verificate che funzionino come prima<\/li>\n
    4. Verificate plugin themes key per compatibilit\u00e0 (run site health)<\/li>\n
    5. Se tutto ok, schedulate l’aggiornamento su live in orario off-peak (per siti high-traffic, idealmente 2-3 AM o durante manutenzione programmata)<\/li>\n
    6. Non attendete automatic updates\u2014aggiornate manualmente dopo aver testato<\/li>\n<\/ol>\n
      Scenario 2: No Staging (Rischioso ma Com\u00fan)<\/strong><\/p>\n
        \n
      1. Disabilitate i plugin di caching (W3 Total Cache, WP Super Cache, ecc.)<\/li>\n
      2. Attivate il maintenance mode<\/strong> tramite plugin come “Maintenance Mode” (5 min di downtime accettato)<\/li>\n
      3. Fate backup database + wp-content\/wp-includes<\/li>\n
      4. Aggiornate da Dashboard \u2192 Updates, oppure via WP-CLI se avete SSH:\n
        wp core update<\/pre>\n<\/li>\n
      5. Verificate il login, caricate un’immagine test, controllate error logs (wp-content\/debug.log)<\/li>\n
      6. Disattivate maintenance mode<\/li>\n
      7. Riabilitate caching<\/li>\n<\/ol>\n
        Scenario 3: Managed Hosting \/ Plesk (Mia Procedura)<\/strong><\/p>\n
        Se siete su Plesk (come molti dei miei clienti), potete sfruttare Extension Update Manager. Accedete a Plesk \u2192 WordPress \u2192 Extension Manager, e se l’aggiornamento 7.0.4 \u00e8 disponibile, cliccate Update. Plesk creer\u00e0 backup automatico e aggiorner\u00e0 in isolamento.<\/p>\n
        Opzione Forza Aggiornamento Automatico (Raccomandato per RCE)<\/strong><\/p>\n
        WordPress ha abilitato forced updates via auto update system per siti su versioni affette<\/cite>. In altre parole, il vostro WordPress potrebbe auto-aggiornarsi a 7.0.4 senza intervento manuale. \u00c8 normale per RCE\u2014non bloccatela.<\/p>\n
        Mitigazioni Rapide Se Non Potete Patchare Subito<\/h2>\n
        Casomai non potete aggiornare oggi<\/strong> (es. siete in freeze pre-evento, avete problemi di compatibilit\u00e0 plugin), ecco le azioni di rischio-riduzione:<\/p>\n
        1. Restrict Author Upload Capabilities<\/strong><\/p>\n
        Disabilitate l’upload per Author se non indispensabile. In wp-config.php<\/code> (dopo le define() standard):<\/p>\n
        if ( current_user_can( 'upload_files' ) && ! current_user_can( 'manage_options' ) ) {\n    wp_die( 'Upload disabled for non-admins.' );\n}<\/pre>\n
        O usate un plugin come “Members” per togliere upload_files<\/code> dal ruolo Author.<\/p>\n
        2. Disable ImageMagick PostScript Processing<\/strong><\/p>\n
        La mitigazione ImageMagick \u00e8 negare i PostScript coders in policy.xml; costa i thumbnail PDF<\/cite>.<\/p>\n
        Edit \/etc\/ImageMagick-6\/policy.xml<\/code> (o il vostro path):<\/p>\n
        <!-- Add this line -->\n<policy domain=\"coder\" rights=\"none\" pattern=\"PS\" \/>\n<policy domain=\"coder\" rights=\"none\" pattern=\"EPS\" \/>\n<policy domain=\"coder\" rights=\"none\" pattern=\"PDF\" \/><\/pre>\n
        Ricaricate PHP-FPM:<\/p>\n
        systemctl restart php-fpm<\/pre>\n
        3. Virtual Patching con WAF<\/strong><\/p>\n
        Validate WAF rules in staging prima di production rollout; maintain small canary host in production per osservare new rule impact; automate exploit tests per high-risk disclosure usando safe, instrumented proof-of-concept<\/cite>.<\/p>\n
        Se avete Plesk con WAF mod_security, aggiungete regola custom:<\/p>\n
        SecRule FILES_TMPNAMES \"@inspectFile \/path\/to\/postscript.yar\" \"phase:2,deny,status:403,msg:'PostScript Upload Blocked'\"<\/pre>\n
        Non \u00e8 una vera patch, ma compra tempo per 48-72 ore.<\/p>\n
        Post-Update Verification Checklist (ESSENZIALE per High-Traffic)<\/h2>\n
        Dopo aver aggiornato a 7.0.4, seguite questa checklist prima di dichiarare il sito “green”:<\/p>\n
        Checkpoint 1: Core Update Verification (5 min)<\/h3>\n
          \n
        • Dashboard \u2192 Updates: Confermate che state su 7.0.4 (o 6.9.7, 6.8.8, etc. a seconda della vostra versione)<\/li>\n
        • Non ci dovrebbero essere update pending per WordPress Core<\/li>\n
        • Check Site Health (Tools \u2192 Site Health): Niente errori critici relativi a WordPress version<\/li>\n<\/ul>\n
          Checkpoint 2: Image Upload Testing (10 min)<\/h3>\n
            \n
          • Caricate un PNG valido via Media \u2192 Add New: Deve funzionare normalmente<\/li>\n
          • Caricate un JPG: Controllate che thumbnail sia creato<\/li>\n
          • Fate upload di PDF (se usate PDF thumbnails): Deve o generare thumbnail o fallire gracefully, NON should crash server<\/li>\n
          • Caricate file da >10 MB: Controllate che limit di upload size sia rispettato<\/li>\n
          • Provate da Author-level account (non admin): Upload deve funzionare se capability c’\u00e8<\/li>\n<\/ul>\n
            Checkpoint 3: Plugin e Theme Compatibility (15 min)<\/h3>\n
              \n
            • Attivate\/disattivate plugin di image processing (ShortPixel, Imagify, ecc.) in staging; verificate che upload funzioni ancora<\/li>\n
            • Controllate theme CSS e JavaScript nel browser console: Niente errori 404<\/li>\n
            • Navigate page di esempio con molte immagini: Load time deve essere simile a prima<\/li>\n
            • Test login: Dovete accedere normalmente sia da admin che da Author<\/li>\n<\/ul>\n
              Checkpoint 4: Audit Trail e Security Logs (10 min)<\/h3>\n
                \n
              • Se avete plugin security (Wordfence, Sucuri), fate scan: Dovrebbe finire in pochi minuti, zero flagged files nella core<\/li>\n
              • Controllate error log WordPress (wp-content\/debug.log): Filtrare per upload, image processing\u2014niente PHP warnings<\/li>\n
              • Se avete Plesk Firewall o ModSecurity, controllate access log per denied uploads: Niente false positive su upload legittimi<\/li>\n<\/ul>\n
                Checkpoint 5: Performance Baseline (5 min)<\/h3>\n
                  \n
                • Core Web Vitals: Eseguite Lighthouse da Google PageSpeed Insights su homepage + page con molte immagini. Score dovrebbe essere identico a baseline pre-patch<\/li>\n
                • Database Query Time: Se avete monitoring (New Relic, DataDog), date un’occhiata al tempo di query. RCE patch non tocca database, ma meglio verificare<\/li>\n<\/ul>\n
                  Automazione Checklist con WP-CLI (la mia procedura):<\/strong><\/p>\n
                  #!\/bin\/bash\n# WordPress 7.0.4 Post-Update Verification\necho \"=== WordPress Version Check ===\"\nwp core version\necho \"n=== Site Health Status ===\"\nwp site-health get | jq '.tests | .critical'\necho \"n=== Plugin Compatibility ===\"\nwp plugin list --status=active\necho \"n=== Testing Image Upload ===\"\nwp media import \/tmp\/test.jpg --title=\"Post-Patch Test\"\necho \"n=== File Integrity Check ===\"\nwp core verify-checksums\necho \"n=== All Checks Complete ===\"<\/pre>\n
                  Salvatelo come post-patch-verify.sh<\/code> e schedulatelo con cron dopo ogni aggiornamento.<\/p>\n
                  Rollout Strategy per Multi-Tenant (Plesk, Managed Hosting)<\/h2>\n
                  Se gestite 10+ siti WordPress su Plesk o hosting simile, ecco prioritizzazione:<\/p>\n
                  Fase 1: High-Risk Sites (24h dalle vulnerabilit\u00e0 pubbliche)<\/strong><\/p>\n
                    \n
                  • Siti con ruoli Author\/Editor multipli<\/li>\n
                  • Siti con plugin di guest posting (es. Guest Post Manager)<\/li>\n
                  • Siti con XML-RPC abilitato (check in Settings \u2192 Writing)<\/li>\n
                  • Siti e-commerce dove clienti possono caricare media (personalized products)<\/li>\n<\/ul>\n
                    Fase 2: Medium-Risk Sites (48-72h)<\/strong><\/p>\n
                      \n
                    • Siti single-author ma con plugin che estendono upload capability<\/li>\n
                    • Siti di blog con contributor non affidabili<\/li>\n<\/ul>\n
                      Fase 3: Low-Risk Sites (1-2 settimane \u00e8 ok)<\/strong><\/p>\n
                        \n
                      • Siti company marketing (admin + publisher solo)<\/li>\n
                      • Siti informazionali senza medio user-generated content<\/li>\n<\/ul>\n
                        Schedule patch rollout prioritizzando mission-critical site (e-commerce, high traffic)<\/cite>.<\/p>\n
                        FAQ<\/h2>\n
                        CVE-2026-65640 \u00e8 veramente pericolosa se non ho Imagick+Ghostscript?<\/h3>\n
                        No. CVE-2026-65640 non \u00e8 un Internet-wide unauthenticated RCE che chiunque pu\u00f2 triggerare; exploitation richiede un utente malizioso con upload_files capability, normalmente corrispondente a un account Author-level o superiore, insieme a configurazione server in cui Imagick e Ghostscript sono coinvolti in processing dell’upload<\/cite>. Se avete GD Library al posto di Imagick, non siete esposti. Ma aggiornate comunque per altri fix inclusi nelle versioni patch.<\/p>\n
                        Posso attendere WordPress 7.1 per aggiornare?<\/h3>\n
                        Non attendete 7.1; questa fix \u00e8 inclusa in 7.1 RC3, ma 7.1 stesso non \u00e8 scaduto fino al 19 agosto, questa patch deve entrare adesso, sulla versione corrente<\/cite>. Non combinate questo update con il 7.1 jump\u2014patchate subito con 7.0.4.<\/p>\n
                        Devo disabilitare XML-RPC come protezione?<\/h3>\n
                        Per questa vulnerabilit\u00e0 specifica no\u2014XML-RPC non fa differenza su CVE-2026-65640, che \u00e8 REST API + media upload. Ma se non usate XML-RPC (raro nel 2026), disabilitatelo comunque\u2014riduce superficie di attacco. In wp-config.php:<\/p>\n
                        define( 'XMLRPC_REQUEST', false );<\/pre>\n
                        Se ho file PostScript legittimi che i clienti caricano, come funziona after patch?<\/h3>\n
                        Un utente con Author-level access o superiore potrebbe caricare un file crafted che viene processed da Imagick\/Ghostscript in modo che esegue codice arbitrario su server<\/cite>. Dopo la patch di 7.0.4, WordPress blocca file PostScript pericolosi ma permette upload file normale. Se avete davvero bisogno di supportare file PostScript (raro), disabilitate Ghostscript nel policy.xml e usate GD Library\u2014ma perderete PDF thumbnail processing.<\/p>\n
                        Come verifico che il patch \u00e8 stato davvero applicato?<\/h3>\n
                        Su SSH, controllate il timestamp di wp-includes\/class-wp-image-editor-imagick.php\u2014deve essere pi\u00f9 recente della data di update (12 agosto 2026 o dopo):<\/p>\n
                        ls -la wp-includes\/class-wp-image-editor-imagick.php<\/pre>\n
                        Oppure usate wp-cli:<\/p>\n
                        wp core verify-checksums 7.0.4<\/pre>\n
                        Conclusione: La Vostra Procedura d’Azione<\/h2>\n
                        Oggi (entro 24h):<\/strong><\/p>\n
                          \n
                        • Controllate se avete Imagick+Ghostscript (Site Health)<\/li>\n
                        • Fate backup completo database + wp-content<\/li>\n
                        • Aggiornate a WordPress 7.0.4 (o versione patch del vostro branch)<\/li>\n<\/ul>\n
                          Nei prossimi 2-3 giorni:<\/strong><\/p>\n
                            \n
                          • Seguite la verification checklist post-update<\/li>\n
                          • Monitorate error logs e Site Health per anomalie<\/li>\n
                          • Testate image upload con Author-level account<\/li>\n<\/ul>\n
                            Prevenzione futura:<\/strong><\/p>\n
                              \n
                            • Installate updates manager<\/em> (Plesk Extension Update Manager, WP Control Panel, ecc.)<\/li>\n
                            • Monitorate WordPress 7.0.3 e security release successive<\/cite> tramite iscrizione a WordPress.org security feed<\/li>\n
                            • Rotate Author access regolarmente\u2014disabilitate account inattivi<\/li>\n
                            • Considerate capability restriction<\/em> per non-admin user: upload solo se necessario<\/li>\n<\/ul>\n
                              Nella mia esperienza, la maggior parte dei problemi post-patch vengono da plugin incompatibili, non da WordPress stesso. Se fate staging test (sempre), avrete 99% di certezza che 7.0.4 funzioner\u00e0 pulito su live. CVE-2026-65640 \u00e8 seria ma patchable rapidamente\u2014non c’\u00e8 scusa per restare indietro qui.<\/p>\n
                              Avete domande sul vostro specifico setup Plesk, WordPress o hosting?<\/strong> Commentate qui sotto\u2014rispondo entro 24h con procedure custom per il vostro scenario.<\/p>\n","protected":false},"excerpt":{"rendered":"
                              WordPress 7.0.4 patch CVE-2026-65640, un RCE autenticato su siti con Imagick+Ghostscript. Guida completa a rollout forzato, verification checklist post-update e mitigazioni rapide.<\/p>\n","protected":false},"author":1,"featured_media":3332,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"WordPress 7.0.4 RCE CVE-2026-65640 | Patch Agosto 2026","_seopress_titles_desc":"WordPress 7.0.4 risolve CVE-2026-65640 (CVSS 8.8): RCE autenticato via Imagick+Ghostscript. Rollout forzato, checklist verifica post-update e mitigazioni rapide incluse. Aggiorna subito.","_seopress_robots_index":"","footnotes":""},"categories":[2],"tags":[1214,1217,1215,1133,237,1216],"class_list":["post-3331","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress","tag-cve-2026-65640","tag-high-traffic-sites","tag-imagick-ghostscript","tag-rce-vulnerability","tag-wordpress-security","tag-wordpress-patching"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/3331","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=3331"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/3331\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/3332"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=3331"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=3331"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=3331"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}