{"id":1857,"date":"2026-04-28T19:23:56","date_gmt":"2026-04-28T17:23:56","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/audit-sicurezza-plugin-wordpress-aprile-2026-wordfence-cloudflare-breeze-cache\/"},"modified":"2026-04-28T19:23:56","modified_gmt":"2026-04-28T17:23:56","slug":"audit-sicurezza-plugin-wordpress-aprile-2026-wordfence-cloudflare-breeze-cache","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/audit-sicurezza-plugin-wordpress-aprile-2026-wordfence-cloudflare-breeze-cache\/","title":{"rendered":"Audit Sicurezza Plugin WordPress Aprile 2026: La Mia Procedura con Wordfence, WAF Cloudflare e CVE-2026-3844"},"content":{"rendered":"

Nel corso di questa settimana ad Aprile 2026, il panorama della sicurezza WordPress si \u00e8 fatto ancora pi\u00f9 critico. Dalla scorsa settimana, 216 nuove vulnerabilit\u00e0 sono emerse nell’ecosistema WordPress, inclusi 187 plugin e 29 temi<\/cite>, e voglio condividere con voi il metodo strutturato che uso quotidianamente per fare un audit serio della sicurezza dei plugin<\/strong>. Ho visto agenzie intere paralizzate dalle vulnerabilit\u00e0 critiche, e la differenza tra chi reagisce in poche ore e chi scopre il danno settimane dopo \u00e8 una procedura d’audit ben documentata e automatizzata. In questa guida vi mostro come configurare una catena di protezione a tre livelli: scansione dei plugin vulnerabili, implementazione di Wordfence come firewall intelligente, e un WAF Cloudflare hardened contro exploit come CVE-2026-3844 nel plugin Breeze Cache.<\/p>\n

Da administrator di server con centinaia di WordPress in produzione, la lezione amara che ho imparato \u00e8 che non puoi fidarti dei tempi dei developer per i fix<\/strong>. Il 71% delle vulnerabilit\u00e0 divulgate rimase without patch nella settimana del 7 gennaio 2026<\/cite>. Questo significa che aspettare il patch non \u00e8 una strategia\u2014\u00e8 una scommessa sulla tua sicurezza. Quello che funziona \u00e8: monitoraggio continuo, protezione virtuale mentre attendi il patch, e isolamento dei plugin a rischio.<\/p>\n

Come Faccio l’Audit Manuale: Il Metodo Dario<\/h2>\n

Nel mio setup personale, uso un approccio a fasi parallele. Non spengo un sito per fare un audit\u2014lo faccio in real-time senza rischi. La procedura inizia con una scansione del database Wordfence Intelligence, che \u00e8 libero di usare via API<\/strong> anche per deployment automatici.<\/p>\n

Nel wp-admin di ogni WordPress, vado in Strumenti > Wordfence > Scansione Vulnerabilit\u00e0<\/em>. Ma non mi affido solo a questo. Ho creato un script in bash che ogni mattina alle 6:00 scarica il feed del database delle vulnerabilit\u00e0 Wordfence via API e lo incrocia con i plugin installati sui miei siti. Se qualcosa non ha patch, mi arriva una mail con priorit\u00e0 alta.<\/p>\n

Questo \u00e8 il comando che uso (testato in produzione):<\/p>\n

curl -s \"https:\/\/www.wordfence.com\/api\/v1\/vulnerabilities?format=json\" | jq '.vulnerabilities[] | select(.affected_software == \"PLUGIN_NAME\")' | mail -s \"VULNERABILIT\u00c0 CRITICA\" admin@tuodominio.it<\/code><\/p>\n

Non \u00e8 sofisticato, ma funziona. L’alternativa enterprise \u00e8 integrarsi con il Wordfence CLI Vulnerability Scanner<\/strong>, che fa esattamente questo ma con output strutturato che posso canalizzare verso un ticketing system.<\/p>\n

Il Caso CVE-2026-3844: Breeze Cache sotto Attacco<\/h2>\n

La vulnerabilit\u00e0 di questa settimana che ha tenuto tutti svegli \u00e8 CVE-2026-3844 nel plugin Breeze Cache<\/strong> di Cloudways. Threat actor stanno attivamente sfruttando una falla critica, tracciata come CVE-2026-3844 (CVSS 9.8), nel plugin Breeze Cache di WordPress, permettendogli di caricare file sul server senza autenticazione<\/cite>. Cos’\u00e8 successo?<\/p>\n

Il plugin Breeze Cache per WordPress \u00e8 vulnerabile a caricamenti di file arbitrari dovuto alla mancanza di validazione del tipo di file nella funzione ‘fetch_gravatar_from_remote’ in tutte le versioni fino alla 2.4.4. Questo rende possibile per attacker non autenticati caricare file arbitrari sul server del sito interessato<\/cite>.<\/p>\n

Ho un client che usa Breeze Cache (400mila+ installazioni attive). Non appena ho letto del CVSS 9.8, ho fatto la verifica immediata:<\/p>\n

    \n
  1. SSH nel server: grep -r \"breeze\" wp-content\/plugins\/<\/code><\/li>\n
  2. Controllo della versione: grep \"Version:\" wp-content\/plugins\/breeze\/breeze.php<\/code><\/li>\n
  3. Verifica della feature a rischio: login in wp-admin, Breeze > Advanced > Host Files Locally \u2013 Gravatars<\/li>\n<\/ol>\n

    Nel caso del mio client, quella feature era attivata<\/strong>. CVE-2026-3844 interessa tutte le versioni di Breeze Cache fino alla 2.4.4 inclusa. Cloudways ha corretto il difetto nella versione 2.4.5, rilasciata all’inizio della settimana<\/cite>. Ho fatto l’upgrade immediato e monitorato i log per segni di sfruttamento\u2014la CVE \u00e8 attivamente sfruttata, e ha generato oltre 170 tentativi di sfruttamento secondo la soluzione di sicurezza Wordfence<\/cite>.<\/p>\n

    Setup Wordfence: il Mio Flusso Operativo<\/h2>\n

    Wordfence \u00e8 il cuore del mio sistema<\/strong>. Non per il plugin stesso\u2014quello \u00e8 buono ma non \u00e8 una magia. Lo uso per la combinazione di tre cose: (1) la scansione vulnerabilit\u00e0 plugin\/tema che \u00e8 sempre aggiornata e free<\/strong>, (2) il firewall WAF a livello applicazione che catchizza exploit che Cloudflare non vede, e (3) l’integrazione centralizzata che mi permette di gestire 60+ siti da un dashboard.<\/p>\n

    La mia procedura di setup \u00e8 questa:<\/p>\n

    1. Installazione e Configurazione di Base<\/h3>\n

    Installo dal repo ufficiale WordPress, attivo, e vado subito in Wordfence > All Options:<\/p>\n

      \n
    • Firewall Status:<\/strong> Attivo (Learning Mode per i primi 7 giorni su siti nuovi)<\/li>\n
    • Attack Traffic Rate:<\/strong> 4 requests al secondo prima del throttle<\/li>\n
    • Brute Force Protection:<\/strong> Limit 20 failed login per IP prima del blocco di 15 minuti<\/li>\n
    • Two Factor Auth:<\/strong> Obbligatorio per tutti gli admin<\/li>\n<\/ul>\n

      2. Scansione Vulnerabilit\u00e0 Plugin e Tema<\/h3>\n

      Accedo a Wordfence > Scansioni<\/em> e avvio una scansione completa. Nella vista “Vulnerabilit\u00e0 Plugin e Tema” vedo subito tutto quello che non \u00e8 al patch. Wordfence mi dice non solo “hai CVE X”, ma anche “\u00e8 attualmente sfruttato” o “il vendor non ha rilasciato un patch”\u2014informazioni critiche.<\/p>\n

      Se la CVE \u00e8 critica e il patch non c’\u00e8, applico immediatamente una regola di protezione virtuale nel firewall:<\/p>\n

      Se (wp-json\/plugin-name\/vulnerable-endpoint) { Blocca con status 403 }<\/code><\/p>\n

      3. Configurazione del Firewall Applicativo<\/h3>\n

      Nel tab Firewall > Firewall Rules, imposto queste regole custom:<\/p>\n

        \n
      • XML-RPC Blocking:<\/strong> Blocca tutti i POST verso xmlrpc.php (0 legittime ragioni su WordPress moderno)<\/li>\n
      • Admin Directory Protection:<\/strong> Nega accesso a wp-admin da IP che non sono nella whitelist<\/li>\n
      • Plugin Exploit Patterns:<\/strong> Regole specifiche per CVE note (es. Elementor RCE patterns, WooCommerce auth bypass)<\/li>\n
      • File Upload Validation:<\/strong> Blocca upload di .php, .phtml, .phar in \/uploads\/ (che \u00e8 dove Breeze Cache cacherebbe)<\/li>\n<\/ul>\n

        Wordfence aggiorna automaticamente queste regole quando emerge una nuova CVE. Wordfence Security v8.1.4 fornisce uno stack completo di sicurezza per WordPress\u2014firewall endpoint, rilevamento malware, sicurezza login (incluso 2FA), auditing, e operazioni centralizzate<\/cite>.<\/p>\n

        4. Monitoraggio Live e Alerting<\/h3>\n

        Nel tab Live Traffic di Wordfence, vedo in real-time ogni richiesta al sito. Imposto alerting per:<\/p>\n

          \n
        • Picco di failed login (>10 in 5 minuti)<\/li>\n
        • Accesso non autorizzato a file sensibili (wp-config.php, .env, database.sql)<\/li>\n
        • File upload sospetti (exe, zip in \/uploads\/)<\/li>\n
        • Plugin attivazione da account non admin<\/li>\n<\/ul>\n

          Questi alert vanno su Slack via webhook. Non aspetto la mail\u2014Slack mi avverte in tempo reale.<\/p>\n

          WAF Cloudflare: la Protezione al Bordo della Rete<\/h2>\n

          Wordfence \u00e8 a livello applicazione. Cloudflare \u00e8 al bordo della rete\u2014bloccato tutto prima ancora che arrivi al mio server<\/strong>. Cloudflare WAF dovrebbe complementare, non sostituire, i plugin di sicurezza WordPress. Un WAF protegge il tuo sito dal bordo della rete, bloccando il traffico malevolo prima che raggiunga il tuo server<\/cite>.<\/p>\n

          La mia config Cloudflare per WordPress \u00e8 questa:<\/p>\n

          Regole Cloudflare WAF Essenziali<\/h3>\n

          Il WAF di Cloudflare, disponibile su tutti i piani a pagamento di Cloudflare, ha rulesets built-in specificamente costruiti per mitigare le minacce e vulnerabilit\u00e0 di WordPress<\/cite>.<\/p>\n

            \n
          • OWASP ModSecurity Core Ruleset:<\/strong> Abilitato con paranoia level 2 (filtra XSS, SQLi, RFI)<\/li>\n
          • Managed Rulesets per WordPress:<\/strong> Rate limiting su wp-login.php (5 richieste per minuto per IP)<\/li>\n
          • Custom Rules per CVE-2026-3844:<\/strong> Blocco di qualsiasi POST verso \/wp-json\/breeze\/v1\/fetch_gravatar che non abbia un nonce valido<\/li>\n<\/ul>\n

            Ecco la regola che ho creato specificamente per Breeze Cache:<\/p>\n

            (cf.threat_score >= 50) or (http.request.method eq \"POST\" and http.request.uri.query contains \"gravatar\" and http.request.headers[\"x-wp-nonce\"] eq \"\")<\/code><\/p>\n

            Azione:<\/strong> Challenge (non Block), cos\u00ec i visitor legittimi possono verificarsi via Cloudflare Managed Challenge.<\/p>\n

            Rate Limiting su Endpoint Critici<\/h3>\n

            Nel Cloudflare Rules > Rate limiting:<\/p>\n

              \n
            • wp-login.php: 5 requests per minuto per IP \u2192 Blocca 10 minuti<\/li>\n
            • wp-admin\/: 20 requests per minuto per IP \u2192 Challenge<\/li>\n
            • wp-json\/*: 100 requests al minuto per IP \u2192 Challenge se > 100<\/li>\n<\/ul>\n

              Rate limiting ferma il 90% dei brute force e bot scan che cercano plugin noti. Non costa extra\u2014\u00e8 incluso nel piano Cloudflare Pro.<\/p>\n

              Allowlist Essenziale<\/h3>\n

              Non voglio bloccare me stesso. Prima di abilitare qualsiasi rule aggressiva, creo allowlist per:<\/p>\n

                \n
              • Il mio IP statico (wp-admin access)<\/li>\n
              • I data center di WP-CLI se faccio deploy via CI\/CD<\/li>\n
              • I bot legittimi (Googlebot, Bingbot, monitoring tools)<\/li>\n<\/ul>\n

                Uno degli errori pi\u00f9 comuni \u00e8 abilitare strict WAF rules senza prima allowlistare il tuo stesso indirizzo IP. Se la tua regola blocca \/wp-admin\/ o \/wp-login.php, potresti bloccare l’accesso al tuo dashboard WordPress. Best practice: crea una regola Allow per il tuo IP address prima di applicare restrizioni strict su login o admin<\/cite>.<\/p>\n

                Integrazione Wordfence + Cloudflare: Defense in Depth<\/h2>\n

                La vera forza non \u00e8 uno strumento, ma la sovrapposizione difensiva<\/strong>. Ecco come i due si completano:<\/p>\n

                  \n
                • Cloudflare WAF (livello rete):<\/strong> Blocca pattern attack noti (XSS, SQLi, RFI) prima che raggiungano il server<\/li>\n
                • Wordfence Firewall (livello applicazione):<\/strong> Vede il contesto WordPress (chi \u00e8 loggato, quali plugin sono attivi, file integrity)<\/li>\n
                • Wordfence Malware Scanner:<\/strong> Rivela anche cosa Cloudflare non pu\u00f2 vedere\u2014backdoor nascosti in file PHP, malware in tema<\/li>\n<\/ul>\n

                  Se un attacker bypassa Cloudflare (es. attacco da botnet distribuito), Wordfence catchizza il payload a livello PHP. Se un attacker bypassa Wordfence (es. file upload diretto via SFTP), l’integrit\u00e0 file di Wordfence lo rivela.<\/p>\n

                  Nel caso specifico di CVE-2026-3844 Breeze Cache:<\/p>\n

                    \n
                  1. Cloudflare WAF<\/strong> blocca POST verso gravatar endpoints con parametri sospetti<\/li>\n
                  2. Wordfence Firewall<\/strong> aggiunge una regola per bloccarespecificamente \/wp-content\/uploads\/breeze-gravatar\/ con estensioni dangerose<\/li>\n
                  3. Wordfence Malware Scanner<\/strong> fa una scansione oraria di quel directory per rilevare file upload sospetti<\/li>\n<\/ol>\n

                    Automatizzazione: Come Non Mi Dimentico Nulla<\/h2>\n

                    Fatto a mano, un audit diventa uno chore. Da impazzire gestendo 60+ siti. La soluzione \u00e8 automazione. Ecco lo script che uso:<\/p>\n

                    #!\/bin\/bash
                    #!\/bin\/bash
                    # Plugin Security Audit Automation
                    SITES=(\"site1.com\" \"site2.com\" \"site3.com\")<\/p>\n

                    for SITE in \"${SITES[@]}\"; do
                    WP_PATH=\"\/var\/www\/$SITE\/html\"

                    \n # 1. Scarica vulnerabilit\u00e0 da Wordfence API
                    VULNS=$(curl -s \"https:\/\/www.wordfence.com\/api\/v1\/vulnerabilities?format=json\")

                    \n # 2. Estrai plugin installati
                    cd $WP_PATH
                    PLUGINS=$(wp plugin list --field=name --allow-root)

                    \n # 3. Incrocia e identifica vulnerabilit\u00e0
                    for PLUGIN in $PLUGINS; do
                    VULN=$(echo $VULNS | jq \".vulnerabilities[] | select(.affected_software == \"$PLUGIN\")\")
                    if [ ! -z \"$VULN\" ]; then
                    echo \"[ALERT] $SITE ha plugin vulnerabile: $PLUGIN\"
                    \n echo \"Dettagli: $VULN\" | mail -s \"VULNERABILIT\u00c0 RILEVATA\" admin@$SITE
                    fi
                    done
                    done<\/code><\/p>\n

                    Questo script corre ogni mattina via cron alle 06:00. Se trova qualcosa, mi arriva una notifica prima che io abbia anche il caff\u00e8.<\/p>\n

                    La Realt\u00e0 dell’Audit nel Contesto della Supply Chain<\/h2>\n

                    Qui sta la cosa che preoccupa di pi\u00f9. WordPress.org ha rimosso l’intero portfolio “Essential Plugin” dopo che i ricercatori hanno confermato che una backdoor di deserializzazione PHP era stata iniettata in ogni singuno di essi, esponendo potenzialmente fino a 400.000 siti<\/cite>. Questo non era una vulnerabilit\u00e0\u2014era un cambio di ownership non comunicato<\/strong>. Un attacker ha comprato i plugin su Flippa, e ha spinto un update malevolo.<\/p>\n

                    I proprietari di siti e gli amministratori dovrebbero continuamente fare audit sui loro siti, incluso il controllo dei plugin installati almeno una volta al mese<\/cite>.<\/p>\n

                    Nel mio flusso, ho aggiunto un check manuale al mio audit mensile: vado su WordPress.org per ogni plugin critico e verifico se l’autore \u00e8 cambiato. Se \u00e8 cambiato, faccio una code review del plugin prima di un’attivazione su produzione. Non \u00e8 automatizzabile completamente\u2014\u00e8 dovuta diligenza manuale<\/strong>.<\/p>\n

                    FAQ<\/h2>\n

                    CVE-2026-3844 mi interessa se non uso Breeze Cache?<\/h3>\n

                    No, ma il pattern s\u00ec. Il fatto che 400k+ siti usassero Breeze Cache in modo insicuro (con Gravatar locali abilitati) mostra che le feature sono spesso lasciate di default insicuro. Il tuo audit deve includere: per ogni plugin, ho veramente bisogno di questa feature? Se no, disattivala. Meno superficie di attacco = meno problemi.<\/p>\n

                    Wordfence Free \u00e8 abbastanza o devo pagare Premium?<\/h3>\n

                    La versione Free ti d\u00e0 il 90% di quello che serve: scansione vulnerabilit\u00e0, firewall di base, malware scanner. Premium ti d\u00e0 protezione WAF prioritaria e Wordfence Central per gestire multi-siti. Se gestisci 1-5 siti, Free \u00e8 pi\u00f9 che sufficiente. Se ne gestisci 50+, Premium paga da s\u00e9 perch\u00e9 risparmi ore di management. Nel mio caso, pago Premium su siti client critici, Free su siti interni.<\/p>\n

                    Quanto spesso devo fare un audit completo della sicurezza?<\/h3>\n

                    Dipende dal criticit\u00e0 del sito. Per un blog personale: mensile. Per un e-commerce o sito di una PMI: settimanale. Per un sito con dati sensibili (healthcare, finanza): giornaliero (automatizzato, non manuale). Nel mio setup, il check automatico corre ogni giorno; il check manuale manuale di ownership change e file integrity lo faccio settimanalmente su siti critici.<\/p>\n

                    Se un plugin non ha patch, devo disattivarlo immediatamente?<\/h3>\n

                    Dipende dalla CVE. Se \u00e8 CVSS 9.0+, s\u00ec, disattivalo immediatamente. Se \u00e8 CVSS 5-6, applica il WAF di Wordfence\/Cloudflare prima, poi disattiva nei giorni seguenti. Se \u00e8 CVSS < 5 e il vendor \u00e8 attivo (ma non ha ancora rilasciato), dai 30 giorni per il patch. Se nessun patch arriva dal vendor o il software vulnerabile \u00e8 stato marcato “chiuso” e abbandonato dal repository WordPress ufficiale, disattivalo e cerca alternative<\/cite>.<\/p>\n

                    Wordfence + Cloudflare WAF insieme non creano conflitti?<\/h3>\n

                    No, anzi si completano. Cloudflare lavora al livello rete (Layer 3-4), Wordfence al livello applicazione (Layer 7). Non competono, cooperano. L’unica cosa da verificare: se Cloudflare blocca un IP, Wordfence non lo vedra nemmeno. Se Wordfence blocca una richiesta, Cloudflare l’ha gi\u00e0 vista. Non c’\u00e8 duplicazione. L’unica cosa sconsigliata: non usare due WAF di applicazione insieme (es. Wordfence + Sucuri)\u2014quello s\u00ec crea conflitti.<\/p>\n

                    Conclusione: L’Audit di Sicurezza \u00e8 un Processo, Non un Evento<\/h2>\n

                    La sicurezza dei plugin WordPress nel 2026 non \u00e8 pi\u00f9 una lista di checklist\u2014\u00e8 un flusso continuo di monitoraggio, protezione e incident response<\/strong>. Dalla scorsa settimana, 216 nuove vulnerabilit\u00e0 hanno impattato l’ecosistema WordPress, e molte rimangono without patch<\/cite>. Se aspetti il patch, sei gi\u00e0 dietro.<\/p>\n

                    Nel mio setup personale, uso: (1) Wordfence per la visibilit\u00e0 e il firewall applicativo, (2) Cloudflare WAF per la protezione al bordo della rete, (3) automazione per non dimenticare alcun sito, (4) diligenza manuale per verificare il codice e i cambi di ownership. Non \u00e8 perfectness\u2014\u00e8 defense in depth<\/strong>.<\/p>\n

                    La vulnerabilit\u00e0 CVE-2026-3844 in Breeze Cache \u00e8 stata un buon promemoria: sempre verificare quale feature hai realmente attivo (spesso il default \u00e8 insicuro), sempre aggiornare immediatamente se la CVE \u00e8 attivamente sfruttata, e sempre sovrapporre le difese. Una singola linea di protezione fallisce; tre linee sovrapposte rendono un sito praticamente inattaccabile.<\/p>\n

                    Avete domande sul vostro setup di sicurezza WordPress? Commentate sotto\u2014mi piace discussioni concrete su questo.<\/p>\n","protected":false},"excerpt":{"rendered":"

                    Come audit dei plugin WordPress con 216 nuove vulnerabilit\u00e0 ogni settimana ad Aprile 2026. La mia procedura con Wordfence, Cloudflare WAF e protezione contro CVE-2026-3844 Breeze Cache.<\/p>\n","protected":false},"author":1,"featured_media":1858,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Audit Plugin WordPress Aprile 2026 | Wordfence + Cloudflare","_seopress_titles_desc":"Scopri come fare un audit serio della sicurezza dei plugin WordPress: Wordfence, Cloudflare WAF e protezione contro CVE-2026-3844. Procedura step-by-step.","_seopress_robots_index":"","footnotes":""},"categories":[2],"tags":[643,644,641,642,237],"class_list":["post-1857","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress","tag-cloudflare-waf","tag-cve-2026-3844","tag-plugin-vulnerabilities","tag-wordfence","tag-wordpress-security"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/1857","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=1857"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/1857\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/1858"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=1857"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=1857"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=1857"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}