El divendres 17 de juliol, WordPress va publicar les versions 6.9.5 i 7.0.2 per tapar wp2shell, un forat que permet executar codi en un lloc sense usuari i sense contrasenya. Aquella mateixa tarda ja hi havia qui l'estava explotant. Diumenge, VulnCheck comptava més de vint exploits públics diferents. Si la teva empresa té una web WordPress —i amb més de 500 milions de llocs al món segons Searchlight Cyber, les probabilitats són altes—, la pregunta d'aquesta setmana no és tècnica: és qui l'ha actualitzat? I si la resposta és «no ho sé», aquest post va de tu.
Què és wp2shell i per què no és «un altre avís més»
wp2shell no és una fallada, en són dues d'encadenades, i totes dues viuen al nucli de WordPress, no en un plugin: CVE-2026-63030 (CVSS 9,8), una confusió de rutes a l'endpoint batch de la REST API (/wp-json/batch/v1) introduïda a la versió 6.9, i CVE-2026-60137, una injecció SQL al paràmetre author__not_in de WP_Query que s'arrossegava des de la 6.8. Per separat són lletges; encadenades permeten a un atacant anònim passar d'una petició HTTP a executar codi al servidor.
El que el fa diferent: no necessita res de tu. Ni un plugin vulnerable, ni un usuari descuidat, ni una configuració estranya. Una instal·lació per defecte, acabada de treure de la caixa, era explotable. La immensa majoria dels ensurts de WordPress dels últims anys venien de plugins i temes; les fallades greus de core són rares. Aquesta és de core, és pre-autenticació i és execució de codi. La trilogia completa.
Les versions, clares: la cadena completa (RCE) afecta 6.9.0–6.9.4 i 7.0.0–7.0.1, corregida a 6.9.5 i 7.0.2. A la branca 6.8 hi ha la injecció SQL sola (sense cadena RCE): 6.8.0–6.8.5, corregida a 6.8.6. Si la teva versió no és cap de les tres corregides —o una de posterior—, deixa de llegir i actualitza.
De pedaç a arma en una tarda
La cronologia del cap de setmana mereix mirar-se a poc a poc, perquè és la notícia de debò. El divendres 17 a les 17:45 (hora de l'est dels EUA), Rapid7 publicava que no hi havia explotació confirmada. Abans de les 19:00 del mateix dia, Patchstack ja reportava explotació activa. Entre «no en tenim constància» i «està passant» no va passar ni una hora i mitja. El diumenge 19, VulnCheck havia verificat més de dues dotzenes d'exploits públics únics. Tenable atribueix part d'aquesta velocitat a eines de desenvolupament d'exploits assistides per IA.
Ja ho vam dir arran del Patch Tuesday rècord de juliol: la capacitat de la indústria de fabricar exploits ha escalat amb la IA; la capacitat de les empreses d'aplicar pedaços, no. «Pedaçaré a la finestra de canvis de final de mes» era un pla raonable el 2016. El 2026, la distància entre el pedaç i l'arma es mesura en hores, i la finestra de canvis de final de mes és una eternitat.
La paradoxa del cap de setmana: es van salvar les webs «abandonades»
Aquí ve la part incòmoda. WordPress va forçar l'actualització automàtica a les instal·lacions que la tenien habilitada. Resultat: la web que ningú no mira des del 2022 es va pedaçar sola durant el cap de setmana. I qui es va quedar exposat tot el cap de setmana? Les instal·lacions que tenien les actualitzacions automàtiques desactivades a propòsit: per control de canvis, per un tema molt personalitzat que «es trenca si actualitzes», per un pipeline de staging que valida abans de pujar. És a dir: com més «gestionada» semblava la web, més números tenia de passar-se el cap de setmana explotable, esperant que algú tornés dilluns.
La lliçó no és «activa les auto-updates i resa». És que tenir procés no és el mateix que tenir manteniment. Manteniment és que existeixi algú la feina del qual inclogui assabentar-se un divendres a la tarda que ha sortit un pedaç crític, avaluar-lo i decidir aplicar-lo ja —encara que sigui divendres—. Si el teu procés de canvis converteix un pedaç de seguretat crític en un tiquet que espera dilluns, el teu procés està optimitzat per a un món que ja no existeix.
Qui manté la teva web? (seriosament, posa-hi un nom)
El patró que veiem una vegada i una altra a les empreses: la web la va fer una agència fa quatre anys. El projecte es va lliurar, es va pagar i es va tancar. Des de llavors, la web és un moble: es va estrenar i es va oblidar. Ningú no renova els seus plugins, ningú no llegeix els seus logs, ningú no sap quina versió de PHP corre a sota. Fins que una setmana com aquesta, el moble resulta ser el que sempre va ser: un servidor teu, exposat a Internet les 24 hores, amb la teva marca a la porta.
I un WordPress compromès gairebé mai no «es nota». No t'esborren la portada: et fan servir. Per allotjar pàgines de phishing, per a spam SEO, per distribuir malware des del teu domini. Ho descobreixes quan el teu domini cau en llistes negres, el correu corporatiu deixa d'arribar i qui t'ho diu és un client. El cost no és la web: és tot el que la teva marca arrossega al darrere.
Què fer avui, en aquest ordre
- 1.Mira la versió. Escriptori → Actualitzacions, o
wp core versionamb WP-CLI. Si no ets a la 7.0.2, 6.9.5 o 6.8.6 (o superior), actualitza ara mateix, encara que estiguis llegint això a l'hora de dinar. - 2.No donis per fet que l'auto-update va saltar: comprova-ho. Instal·lacions amb les actualitzacions automàtiques desactivades, amb el core versionat a git o en allotjaments peculiars es van quedar fora de l'actualització forçada. Searchlight Cyber, que va destapar la fallada, va publicar una eina de comprovació a wp2shell.com.
- 3.Si vas estar exposat entre el dia 17 i la teva actualització, revisa. Peticions POST a
/wp-json/batch/v1als logs, administradors nous que ningú no va crear, fitxers PHP recents auploads/. Davant de qualsevol senyal: rota contrasenyes i salts, i tracta el lloc com a compromès fins a demostrar el contrari. - 4.I el de sempre: aquesta vegada va ser el core, però la superfície d'atac real d'un WordPress mitjà continuen sent els seus plugins. Menys plugins, més actualitzats, i fora els que fa un any que no tenen manteniment del seu autor.
La solució estructural no és un plugin: és un propietari
Tot l'anterior és, literalment, un pedaç. L'estructural és que la teva web —i el servidor on viu— tingui un propietari. Propietari significa: pedaços de seguretat aplicats amb criteri i amb pressa quan toca, backups que algú ha provat de restaurar, monitoratge que avisa quan passa alguna cosa estranya, i una persona localitzable un divendres a les set de la tarda. Res d'això no és glamurós. Tampoc no ho és pagar la neteja d'un lloc compromès i explicar-ho als teus clients.
A everyWAN no fem webs; a això no ens hi dediquem. Ens dediquem a la part de sota: manteniment informàtic amb pedaços, backups i monitoratge com a disciplina —sigui un clúster de virtualització o el servidor on viu la teva web— i suport 24/7 perquè un avís de divendres a la tarda no esperi dilluns. És la part de l'IT que no llueix en cap presentació. També és la que va decidir, aquest cap de setmana, quines webs es van llevar dilluns sent seves i quines no.
En curt
wp2shell es corregeix amb un clic. El que no es corregeix amb un clic és no saber qui l'havia de fer. Aquesta setmana el clic era a WordPress; el mes que ve serà en un altre lloc. La pregunta continua sent la mateixa: quan surti el pròxim pedaç crític un divendres a la tarda, qui del teu costat se n'assabentarà?
Fonts (verificades): detall tècnic de la cadena, versions afectades i corregides, i endpoint /wp-json/batch/v1 — Tenable i BleepingComputer; cronologia pedaç (17-jul) → explotació aquella tarda (Rapid7/Patchstack) → més de dues dotzenes d'exploits verificats per VulnCheck el 19-jul — Servola; actualització forçada i avís general — Help Net Security. L'estimació de més de 500 milions de webs WordPress és de Searchlight Cyber (descobridors de la fallada), citada per BleepingComputer.
La teva web (i el servidor de sota) tenen propietari?
A everyWAN mantenim infraestructura des del 1996: pedaços amb criteri, backups provats i monitoratge que avisa abans que ho faci un client. Si el wp2shell t'ha enxampat sense saber a qui trucar, aquesta és la conversa pendent.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN