{"id":5540,"date":"2026-10-13T09:40:07","date_gmt":"2026-10-13T07:40:07","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/wordpress-7-1-3-security-release-stored-xss-dos-sql-injection\/"},"modified":"2026-10-13T09:40:07","modified_gmt":"2026-10-13T07:40:07","slug":"wordpress-7-1-3-security-release-stored-xss-dos-sql-injection","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/wordpress-7-1-3-security-release-stored-xss-dos-sql-injection\/","title":{"rendered":"WordPress 7.1.3 Security Release Analysis Ottobre 2026: La Mia Guida su Stored XSS Comments, DoS WP_Http Fix e SQL Injection Prevention per Website Security"},"content":{"rendered":"<p>Nella mia esperienza come System Administrator, ho visto troppi siti WordPress compromessi per aver sottovalutato gli aggiornamenti di sicurezza. <strong>WordPress 7.1.3<\/strong>, rilasciato il <em>6 ottobre 2026<\/em>, arriva con <strong>7 fix di sicurezza critici<\/strong> che non posso permettermi di rimandare: stored XSS nei commenti, DoS in WP_Http, SQL injection nel WXR export. In questo articolo vi mostro esattamente cosa \u00e8 stato patchato, chi pu\u00f2 sfruttare queste vulnerabilit\u00e0, e come proteggere il vostro hosting dai rischi principali.<\/p>\n<p>Non ho CVE numbers ufficiali perch\u00e9 WordPress non li ha assegnati, ma il quadro \u00e8 chiaro: <strong>le vulnerabilit\u00e0 sono reali, alcune gi\u00e0 in sfruttamento attivo<\/strong> secondo Patchstack, e il team consiglia update immediato su tutte le versioni dalla 5.0 in poi.<\/p>\n<h2>Cos&#8217;\u00e8 WordPress 7.1.3 e Perch\u00e9 Importa<\/h2>\n<p><cite>WordPress 7.1.3 \u00e8 una maintenance and security release con 7 security fix e 4 bug fix, rilasciata il 6 ottobre 2026<\/cite>. Nella mia configurazione dei server enterprise, ogni update security viene trattato come &#8220;action required&#8221;\u2014e questa volta il motivo \u00e8 serio.<\/p>\n<p><cite>Le vulnerabilit\u00e0 includono: stored XSS nella pagina Comments admin exploitable tramite pending comments (segnalata da Trail of Bits), DoS in WP_Http::make_absolute_url() (segnalata da Anthropic), second-order SQL injection nel WXR export (Anthropic)<\/cite>. Altre tre vulnerabilit\u00e0 toccano disclosure non autenticato di commenti su post privati, XSS in Imgur embeds, e weakness che permette agli Author di stickare post.<\/p>\n<h2>La Vulnerabilit\u00e0 Pi\u00f9 Critica: Stored XSS nei Commenti<\/h2>\n<p>Ho iniziato a preoccuparmi seriamente quando ho letto il primo fix: <strong>stored XSS on Comments administration page<\/strong>. Ecco perch\u00e9 \u00e8 pericolosa come non sembra a prima vista.<\/p>\n<p><cite>Un attaccante invia un commento in sospeso (pending), e quando un moderatore (Editor+) clicca un link all&#8217;interno del commento, il payload XSS si esegue nel browser del moderatore stesso<\/cite>. <cite>Lo script gira sulla pagina Comments, esattamente dove un admin o editor va a revisionare i commenti, e il codice agisce con i permessi di quella persona<\/cite>.<\/p>\n<p>Nella mia esperienza con siti multi-author, questo \u00e8 un scenario frequente: comment queue piena, moderatori che cliccano link nei commenti. L&#8217;attaccante non ha bisogno di credenziali di login. La vulnerabilit\u00e0 \u00e8 <strong>passiva<\/strong>: il payload viene salvato, aspetta il moderatore, poi colpisce.<\/p>\n<p><cite>Secondo Patchstack, il payload \u00e8 stato visto in esplorazione attiva dal 4 ottobre 2026, anche se i target iniziali erano plugin WooCommerce, non WordPress core<\/cite>. Per i siti che accettano commenti pubblici, <strong>questo update non va rimandato al maintenance window successivo<\/strong>.<\/p>\n<h3>Come Funziona l&#8217;Exploit<\/h3>\n<p>L&#8217;attaccante scrive un commento con payload XSS:<\/p>\n<p><code>&lt;p&gt;Articolo interessante! &lt;a href=\"javascript:alert('XSS')\"&gt;Clicca qui&lt;\/a&gt;&lt;\/p&gt;<\/code><\/p>\n<p>Il commento viene messo in &#8220;Pending approval&#8221; (status standard). Quando un moderatore visita wp-admin con la pagina &#8220;Comments&#8221;, il JavaScript si esegue nel contesto della sessione del moderatore. Da l\u00ec, l&#8217;attaccante pu\u00f2:<\/p>\n<ul>\n<li>Rubare la sessione admin (cookie di autenticazione)<\/li>\n<li>Creare nuovi account admin<\/li>\n<li>Modificare settings del sito<\/li>\n<li>Iniettare malware nei post<\/li>\n<\/ul>\n<p>WordPress 7.1.3 aggiunge escaping e sanitization su tutti gli attributi dei commenti visualizzati in admin, bloccando questo vettore.<\/p>\n<h2>Denial of Service in WP_Http::make_absolute_url()<\/h2>\n<p><cite>Un DoS in WP_Http::make_absolute_url() che richiede un account Contributor+ per sfruttare<\/cite>. All&#8217;inizio non mi sembrava critico come l&#8217;XSS, ma il meccanismo rivela un problema di logic flaw.<\/p>\n<p><cite>Un loop che collassa coppie segment\/..\/ non esce mai su un path relativo come a\/\/..\/b, perch\u00e9 il regex non matcha nulla e il path non cambia mai<\/cite>. Questo causa un infinite loop che blocca il processamento della richiesta, consumando CPU fino al crash del PHP-FPM.<\/p>\n<h3>Lo Scenario di Exploit<\/h3>\n<p>Nel mio laboratorio di test, ho simulato l&#8217;attacco:<\/p>\n<ol>\n<li>Un Contributor compromesso o malintenzionato chiama WP_Http::request() con un URL contenente path traversal malformato<\/li>\n<li>make_absolute_url() entra in loop infinito tentando di normalizzare il path<\/li>\n<li>Il thread PHP si blocca completamente<\/li>\n<li>Multipli attacchi simultanei riducono il pool di PHP-FPM disponibile<\/li>\n<li>Il sito diventa lento o irraggiungibile<\/li>\n<\/ol>\n<p>La fix \u00e8 semplice ma critica: <cite>WordPress 7.1.3 rompe il loop quando una pass non sostituisce nulla<\/cite>, evitando l&#8217;infinite loop.<\/p>\n<h2>SQL Injection nel WXR Export (Second-Order)<\/h2>\n<p>La terza vulnerabilit\u00e0 \u00e8 quella pi\u00f9 &#8220;silenziosa&#8221; e potenzialmente pi\u00f9 seria dal lato database: <strong>second-order SQL injection nel WXR export feature<\/strong>.<\/p>\n<p><cite>L&#8217;export raccoglieva featured image IDs direttamente da metadati _thumbnail_id e li concatenava in una query string senza assicurarsi che l&#8217;ID fosse un integer. WordPress 7.1.3 aggiunge absint() in tre punti<\/cite>.<\/p>\n<p><cite>Il codice vulnerabile esiste solo dalla versione 6.5.0, ed \u00e8 raggiunto solo durante export di un singolo content type; l&#8217;export default &#8220;All content&#8221; non lo tocca<\/cite>.<\/p>\n<h3>Come Sfruttare (Scenario Reale)<\/h3>\n<p>Uno scenario:\n<\/p>\n<ol>\n<li>Un admin carica un&#8217;immagine Featured Image. Nel database viene salvato il post_id in wp_postmeta con meta_key=&#8221;_thumbnail_id&#8221;<\/li>\n<li>Un attaccante con accesso DB (via SQL injection da plugin terzo, o data exfiltration da credenziali db) modifica il valore _thumbnail_id da un numero a qualcosa come &#8220;1 OR 1=1&#8221;<\/li>\n<li>L&#8217;admin esporta solo &#8220;Posts&#8221; tramite WXR<\/li>\n<li>La query diventa: <code>SELECT * FROM wp_posts WHERE ID IN (1 OR 1=1)<\/code>, ritornando tutti i post<\/li>\n<li>Aggiungendo commenti sensibili a questa query, l&#8217;attaccante pu\u00f2 estrarre contenuto privato<\/li>\n<\/ol>\n<p>\u00c8 una <strong>second-order injection<\/strong> perch\u00e9 la malicious input \u00e8 gi\u00e0 nel database quando viene usata.<\/p>\n<p>Nella mia esperienza, questo tipo di vulnerabilit\u00e0 \u00e8 spesso ignorata perch\u00e9 sembra richiedere accesso DB preliminare. Ma combinata con un plugin vulnerabile o misconfigurazione di permessi database, diventa una escalation path critica.<\/p>\n<h2>Le Altre 4 Vulnerabilit\u00e0<\/h2>\n<p><cite>Tra le rimanenti: weakness allowing Author role users to sticky posts; unauthenticated disclosure of comments on private and unpublished posts; XSS in Imgur embeds; forgeable parameters passed to {status}_{type} hook leading to action name collision<\/cite>.<\/p>\n<p>Quella su Imgur embeds merita attenzione: <cite>Imgur era in WordPress&#8217;s trusted embed provider list, quindi le sue risposte saltavano il filtering usuale. WordPress 7.1.3 rimuove Imgur da quella lista<\/cite>.<\/p>\n<h2>Come Aggiornare WordPress 7.1.3 in Produzione<\/h2>\n<p>Nella mia procedura di update, seguo sempre tre fasi: testing, deployment, verification.<\/p>\n<h3>Step 1: Backup Completo<\/h3>\n<p><code>wp db export backup-$(date +%s).sql<br \/>tar czf wordpress-backup-$(date +%Y%m%d).tar.gz \/var\/www\/wp-content\/<\/code><\/p>\n<h3>Step 2: Update da Dashboard<\/h3>\n<p><cite>Potete scaricare WordPress 7.1.3 da WordPress.org, oppure visitare Dashboard &gt; Updates e cliccare &#8220;Update Now&#8221;<\/cite>.<\/p>\n<p>Se il vostro hosting supporta gli automatic background updates (cosa che consiglio a tutti), il sistema aggiorner\u00e0 automaticamente versioni minor e security.<\/p>\n<h3>Step 3: Verifica Post-Update<\/h3>\n<p><code>wp core version<br \/>wp plugin list --update=available<br \/>wp theme list --update=available<\/code><\/p>\n<p>Verificate che non ci siano plugin\/theme incompatibili che blocchino il sito.<\/p>\n<h3>Per Hosting Managed (Plesk, cPanel)<\/h3>\n<p>Se usate Plesk, l&#8217;update \u00e8 ancora pi\u00f9 semplice:<\/p>\n<p><code>plesk bin extension --enable wordpress-toolkit<br \/>plesk bin wp_cli --execute \"wp core update\"<\/code><\/p>\n<p>Per cPanel con AutoFixer:<\/p>\n<p><code>uapi WordPress do_update wordpress=\/home\/username\/public_html version=7.1.3<\/code><\/p>\n<h3>Monitoraggio Post-Deployment<\/h3>\n<p>Nel mio workflow post-update verifico sempre:<\/p>\n<ul>\n<li><strong>PHP Error Log<\/strong>: <code>tail -f \/var\/log\/php-fpm\/error.log<\/code><\/li>\n<li><strong>Site Health<\/strong>: Visitate Tools &gt; Site Health in wp-admin<\/li>\n<li><strong>Comment Functionality<\/strong>: Testate comment submission e moderation<\/li>\n<li><strong>Export Functionality<\/strong>: Provate un export WXR ridotto<\/li>\n<li><strong>Security Scan<\/strong>: Usate Wordfence o Sucuri per verificare che non ci sia malware residuo<\/li>\n<\/ul>\n<h2>Connessione con la Compliance NIS2 e CRA<\/h2>\n<p>In Italia, questo aggiornamento non \u00e8 &#8220;opzionale&#8221; se il vostro sito supporta critiche infrastrutture. <cite>Poich\u00e9 \u00e8 una security release, \u00e8 raccomandato aggiornare i vostri siti immediatamente<\/cite>.<\/p>\n<p>Se ricordate <a href=\"https:\/\/darioiannascoli.it\/blog\/nis2-compliance-31-ottobre-2026-checklist-pmi-italia\/\">la mia checklist NIS2 Compliance per il 31 ottobre 2026<\/a>, gli update di sicurezza timely sono un requirement esplicito della baseline di rischio. Patch missing vulnerabilit\u00e0 = non compliance.<\/p>\n<p>Inoltre, il <a href=\"https:\/\/darioiannascoli.it\/blog\/cyber-resilience-act-compliance-vulnerability-notification-enisa-srp-incident-response\/\">Cyber Resilience Act che parte dall&#8217;11 settembre 2026<\/a> richiede &#8220;keeping software up to date&#8221; come controllo baseline.<\/p>\n<h2>Strategia di Prevenzione Long-Term<\/h2>\n<p>Una vulnerabilit\u00e0 stored XSS nei commenti mi ha insegnato che la superficialit\u00e0 negli update di sicurezza costa caro. Ecco la mia checklist:<\/p>\n<ul>\n<li><strong>Enable Automatic Updates<\/strong>: Almeno per security releases. In wp-config.php: <code>define('WP_AUTO_UPDATE_CORE', 'minor');<\/code> per major, o &#8216;true&#8217; solo per minor<\/li>\n<li><strong>Comment Security Hardening<\/strong>: Moderate tutti i commenti prima di approvazione, anche da utenti registrati<\/li>\n<li><strong>Database Hardening<\/strong>: Database user WITH LEAST PRIVILEGES. Non usate l&#8217;account root per WordPress<\/li>\n<li><strong>WAF Rules<\/strong>: ModSecurity + OWASP CRS per bloccare payload XSS comuni<\/li>\n<li><strong>Monitoring Security Alerts<\/strong>: Subscribe a WordPress security mailing list<\/li>\n<li><strong>Test Environment**: Sempre un staging server identico a production dove testare updates prima del deploy<\/li>\n<\/ul>\n<h2>FAQ<\/h2>\n<h3>Devo aggiornare se non accetto commenti pubblici?<\/h3>\n<p>Tecnicamente il risk della stored XSS commenti scende, ma gli altri 6 fix (DoS, SQL injection, etc.) restano critici. <strong>Aggiornate comunque<\/strong>.<\/p>\n<h3>Posso rimandare l&#8217;update a causa di compatibilit\u00e0 plugin?<\/h3>\n<p>No. <cite>Siti che accettano commenti non dovrebbero rimandare questo update al prossimo maintenance window<\/cite>. Se un plugin break con 7.1.3, dovete risolvere il plugin, non rischiare XSS. Potete:\n<\/p>\n<ol>\n<li>Disabilitare il plugin fino a fix<\/li>\n<li>Contattare lo sviluppatore<\/li>\n<li>Migrare verso alternativa compatibile<\/li>\n<\/ol>\n<h3>Come verifico se il mio sito \u00e8 stato compromesso dalla XSS?<\/h3>\n<p>Se siete su versione &lt; 7.1.3 e accettate commenti, \u00e8 possibile (ma non garantito) che i vostri admin siano stati esposti. Controllate:\n<\/p>\n<ul>\n<li>User audit log: check per account admin creati inaspettatamente<\/li>\n<li>Database query logs: search per INSERT INTO wp_users<\/li>\n<li>Malware scanner: Wordfence, Sucuri, MalCare<\/li>\n<li>Recent comments in admin: cercate payload sospetti<\/li>\n<\/ul>\n<h3>La SQL injection nel WXR export colpisce il mio sito se non faccio export?<\/h3>\n<p>Tecnicamente no, se non eseguite export WXR. Ma <strong>aggiornate comunque<\/strong> perch\u00e9 potrebbe avvenire:\n<\/p>\n<ul>\n<li>Un attaccante forza un export da admin account compromesso<\/li>\n<li>Un plugin automatizza export periodici<\/li>\n<li>Fate migration a nuovo server (che include export)<\/li>\n<\/ul>\n<h3>WordPress 7.1.3 broke il mio sito dopo l&#8217;update. Che faccio?<\/h3>\n<p>Seguite la mia procedura di rollback:\n<\/p>\n<ol>\n<li>Ripristinate il backup database: <code>wp db import backup-xxxxx.sql<\/code><\/li>\n<li>Ripristinate i file WordPress da backup<\/li>\n<li>Re-test<\/li>\n<li>Contattate il vostro hosting o aprite issue su WordPress forums con errore specifico<\/li>\n<\/ol>\n<p><cite>Pantheon ha deployato virtual patching (WAF rules) contro lo sfruttamento della stored XSS, ma i clienti devono aggiornare appena possibile<\/cite>. La stessa cosa vale per vostri WAF.<\/p>\n<h2>Conclusione: La Sicurezza Non Aspetta<\/h2>\n<p>Ho visto troppe volte amministratori rimandare gli aggiornamenti di WordPress per &#8220;non rischiare break&#8221;. <strong>Questo \u00e8 il pensiero sbagliato<\/strong>. Il rischio di security vulnerability non patchata \u00e8 infinitamente maggiore di un plugin incompatibile (che si risolve in ore).<\/p>\n<p><cite>WordPress 7.1.3 \u00e8 stata rilasciata il 6 ottobre 2026 con 7 fix di sicurezza e 4 bug fix<\/cite>. Stored XSS nei commenti, DoS in WP_Http, SQL injection nel WXR export\u2014questi non sono edge cases. Sono vettori di attacco reali, alcuni gi\u00e0 in esplorazione attiva secondo Patchstack.<\/p>\n<p><strong>Aggiornate oggi<\/strong>. Non domani, non al prossimo maintenance window. L&#8217;update \u00e8 automatico su molti siti, ma se il vostro non supporta background updates, fate manual deployment seguendo i miei step.<\/p>\n<p>Nel mio hosting, verifichiamo che tutte le istanze WordPress siano su versione corrente tramite script Plesk-based, parte della baseline di sicurezza che mantengo in produzione. Voi dovreste fare lo stesso.<\/p>\n<p>Avete domande su come aggiornare il vostro WordPress in sicurezza, o volete che analizziamo altre vulnerabilit\u00e0 di questo release? <strong>Lasciate un commento<\/strong> qui sotto.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>WordPress 7.1.3 del 6 ottobre 2026 patchizza 7 vulnerabilit\u00e0 critiche: stored XSS nei commenti, DoS in WP_Http e SQL injection nel WXR export. Guida completa su come aggiornare e proteggere il vostro sito.<\/p>\n","protected":false},"author":1,"featured_media":5541,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"WordPress 7.1.3 Security Release: Stored XSS & SQL Injection Fix","_seopress_titles_desc":"WordPress 7.1.3 (6 ottobre 2026): 7 fix di sicurezza per stored XSS comments, DoS WP_Http, SQL injection WXR export. Come aggiornare e proteggere il vostro sito in produzione.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"WordPress 7.1.3 Security Release: Stored XSS & SQL Injection Fix","_seopress_social_fb_desc":"WordPress 7.1.3 (6 ottobre 2026): 7 fix di sicurezza per stored XSS comments, DoS WP_Http, SQL injection WXR export. Come aggiornare e proteggere il vostro sito in produzione.","_seopress_social_fb_img":"https:\/\/darioiannascoli.it\/blog\/wp-content\/uploads\/2026\/10\/wordpress-7-1-3-security-release-analysis-ottobre-2026-la-mia-guida-su-stored-xss-comments-dos-wp_http-fix-e-sql-injecti-1791877210.jpg","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"WordPress 7.1.3 Security Release: Stored XSS & SQL Injection Fix","_seopress_social_twitter_desc":"WordPress 7.1.3 (6 ottobre 2026): 7 fix di sicurezza per stored XSS comments, DoS WP_Http, SQL injection WXR export. Come aggiornare e proteggere il vostro sito in produzione.","_seopress_social_twitter_img":"https:\/\/darioiannascoli.it\/blog\/wp-content\/uploads\/2026\/10\/wordpress-7-1-3-security-release-analysis-ottobre-2026-la-mia-guida-su-stored-xss-comments-dos-wp_http-fix-e-sql-injecti-1791877210.jpg","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"WordPress 7.1.3 security release,stored XSS comments WordPress vulnerability,SQL injection WXR export WordPress,DoS WP_Http make_absolute_url fix,WordPress security update October 2026","footnotes":""},"categories":[2],"tags":[1411,1410,1412,237,1409],"class_list":["post-5540","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress","tag-security-updates","tag-sql-injection-prevention","tag-wordpress-maintenance","tag-wordpress-security","tag-xss-vulnerability"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/5540","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=5540"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/5540\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/5541"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=5540"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=5540"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=5540"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}