La fallada és de WordPress; l'exposició la decideix el teu php.ini

El divendres 25 de setembre CISA va ficar CVE-2026-87902 al catàleg de vulnerabilitats explotades. És un 9.2, és el nucli del WordPress i hi ha prova de concepte pública des del dia 22. Tot això és cert i no contesta l'única pregunta que t'importa aquest matí: si el teu web està exposat o no. Aquesta resposta no és al WordPress. És en un fitxer de configuració de PHP que segurament ningú no ha mirat des que es va muntar el servidor.

Operem infraestructura de tercers des de fa força anys i hem vist el patró prou vegades com per reconèixer-lo de lluny: l'aplicació la va triar algú, la plataforma la va muntar un altre, i quan surt un avís com aquest ningú no és amo de la resposta. Així que separarem les dues coses, perquè aquesta vegada la distància entre «la fallada existeix» i «a tu t'afecta» és més gran del que és habitual.

Què fa la fallada, en una frase

La fitxa de CISA ho resumeix així: el WordPress conté una inclusió remota de fitxers que permet a un atacant no autenticat aconseguir que la resolució de plantilles de pàgina inclogui un fitxer .php local llegible triat per ell, fora dels directoris del tema actiu, i que això acabi en execució remota de codi. L'avís de WordPress assenyala la funció concreta: get_page_template(). La classificació és CWE-98: control indegut del nom de fitxer en un include o require de PHP.

El pedaç va sortir el 22 de setembre. El que convé mirar no és la versió nova, és la llista: el WordPress va publicar arranjament per a vint-i-cinc branques, des de la 7.1.2 fins a la 4.7.37. La 4.7 va sortir el 6 de desembre del 2016. L'avís explica el gest com una cortesia, «as a courtesy to users on older branches»; nosaltres ho llegim també com un reconeixement del que continua encès allà fora, perquè a una branca de fa gairebé deu anys no se li fa un backport per esport.

El 9.2 mesura el dany, no la teva exposició

El vector publicat és CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. La meitat de la dreta explica per què surt 9.2: confidencialitat, integritat i disponibilitat, totes altes. Sense credencials, sense interacció, per xarxa. Però hi ha tres caràcters al mig que gairebé ningú no llegeix i que són els que parlen de tu: AT:P. En CVSS 4.0, Attack Requirements val N quan no cal res especial i P quan sí que calen condicions a l'objectiu. Aquí val P, i això és un advertiment imprès dins del mateix número.

L'investigador que el va reportar, Robert Ressl, va publicar les condicions una per una. Són cinc i s'han de donar totes alhora:

I ara la frase del mateix investigador que més ens agrada de tot l'avís, perquè és la que no surt a cap titular: «I have not measured their prevalence across live sites». No ha mesurat quants webs compleixen aquestes condicions. Nosaltres tampoc, així que no et direm que mig internet està compromès. Et direm com saber si ho estàs tu.

La condició que decideix no és del WordPress

Fixa't en la quarta condició. Perquè una inclusió local acabi en execució de codi cal un .php que l'atacant pugui influir. La demostració pública va fer servir el clàssic: pearcmd.php, l'executable de línia d'ordres del PEAR, amb la directiva register_argc_argv activada al PHP. Aquest fitxer no l'instal·la el WordPress. Aquesta directiva no la configura el WordPress. Totes dues venen de com algú va muntar la plataforma.

register_argc_argv va néixer per a la línia d'ordres: omple $argv i $argc amb els arguments de l'script. El que gairebé ningú no té present és què fa fora de la línia d'ordres, i ho diu el manual de PHP sense embuts en declarar-ho obsolet: en SAPIs que no són CLI, $_SERVER['argv'] es deriva de la cadena de consulta de la petició. És a dir: amb aquesta directiva activa, el que un desconegut escriu després de l'interrogant a l'URL entra en un script que esperava arguments de consola. Aquí hi ha el canal.

I aquí ve l'incòmode. El valor per defecte de register_argc_argv al PHP és 1, és a dir, activada. El fitxer php.ini-production que distribueix el mateix PHP la posa a Off i porta el comentari explícit «Production Value: Off». Però aquest fitxer no s'aplica sol: cal copiar-lo, i la documentació de les imatges oficials de PHP a Docker diu que la imatge «ships with the default php.ini-development and php.ini-production configuration files» i recomana vivament fer servir la de producció. Si ningú no la copia, el PHP arrenca amb els seus valors compilats. Amb la directiva activada. L'avís del WordPress no ho deixa a la interpretació de ningú i dona dos noms propis: «The official php image for Docker is affected, and the default cPanel configuration is affected when PHP prior to 8.5 is in use». La imatge oficial i la configuració per defecte del panell sobre el qual corre bona part de l'hosting compartit d'aquest país.

Dos WordPress idèntics, mateixa versió, mateix tema, mateixa pàgina publicada: un acaba en execució de codi i l'altre en un error. La diferència no és a l'aplicació. És en si algú va copiar un fitxer de configuració el dia que va construir la imatge. Això és, literalment, la forma de la frase que vam escriure amb allò del PNG que per dins era PostScript: l'opinió que compta és la de l'últim programa de la cadena, i aquest programa gairebé mai no és el que et penses que estàs auditant.

Ressl és honest amb l'abast d'això i convé repetir-ho tal qual, perquè és la part que es perd així que algú ho resumeix: desactivar la directiva o treure el PEAR «breaks this demonstrated route. It does not repair WordPress's underlying file-inclusion flaw». Trenca aquella ruta. El forat continua on era.

La comprovació que et mentirà

Si has arribat fins aquí, el següent que faràs és entrar per SSH al servidor i escriure php -i | grep register_argc_argv. És el que faríem tots. I et tornarà una resposta falsa.

Ho acabem de mesurar en una màquina amb PHP 8.3.6 mentre escrivíem això, i surt així de clar:

$ grep -n '^register_argc_argv' /etc/php/8.3/cli/php.ini
690:register_argc_argv = Off

$ php -i | grep register_argc_argv
register_argc_argv => On => On

El fitxer de configuració diu Off, a la línia 690, i el PHP contesta On. No és un error de ningú: el mateix php.ini-production porta l'explicació escrita cinc línies més amunt de la directiva — «Note: This directive is hardcoded to On for the CLI SAPI». La documentació del PHP ho confirma per l'altre costat: la llista de directives que el SAPI de consola imposa no es pot canviar des del php.ini, i register_argc_argv hi és.

La conseqüència pràctica és més gran que aquesta CVE, i per això l'escrivim a part: una auditoria de configuració feta des de la shell no descriu el que fa el teu web. El SAPI de consola i el d'FPM carreguen fitxers diferents —a l'empaquetat de Debian i Ubuntu cada SAPI té el seu propi directori: /etc/php/8.3/cli/, /etc/php/8.3/fpm/— i a més hi ha directives que la consola imposa per sobre del que digui el fitxer. L'única comprovació vàlida és la que passa pel servidor web: un fitxer d'una línia servit pel mateix intèrpret que serveix el teu WordPress.

Les quatre comprovacions que sí que contesten

No van per gravetat, van per l'ordre en què es poden fer. Cap no necessita eines nostres i totes quatre es fan en un matí:

Hi ha una cinquena pregunta que no és una comprovació i que és la que de debò decideix la mida del dia dolent: què abasta aquest host? Una inclusió de fitxers et dona execució amb l'usuari del servidor web, i aquest usuari ja pot llegir wp-config.php, on viu la contrasenya de la base de dades. I amb la base de dades venen les credencials que guardin els connectors, les d'SMTP incloses. La pregunta no és si l'atacant entra al web. És a què arriba des del web. Si la resposta inclou la xarxa de l'oficina, el problema d'avui no és el WordPress.

Per què es pedaça igual encara que no compleixis les condicions

Ens podríem haver estalviat aquest apartat i quedaríem igual de bé, però seria deshonest. Tot l'anterior serveix per decidir amb quina pressa, no per decidir si. I la raó és que cap de les cinc condicions no és estable. La tercera depèn del tema, i un tema es canvia un dijous a la tarda sense avisar sistemes. La quarta depèn de quins fitxers hi ha al disc, i això canvia cada vegada que algú instal·la un paquet. Pots complir zero condicions avui i tres el mes vinent sense haver tocat una línia de WordPress. La fallada, mentrestant, continua a get_page_template().

Dit això, la pressa també és una dada, i aquest cas la porta: Ressl publica la cronologia completa. Va reportar la fallada per HackerOne el 20 de juliol, li van confirmar recepció l'endemà, el van avisar de l'arranjament el 15 de setembre i l'avís i la prova de concepte van sortir el 22. Seixanta-quatre dies de silenci ordenat. I després, tres: del 22 al 25 de setembre, de «hi ha prova de concepte» a «CISA ho fica al catàleg per explotació activa». Aquest és el rellotge real. No el marques tu.

I si sospites que ja ha passat: no reinstal·lis primer

La fitxa del catàleg porta un camp que gairebé ningú no mira i que en aquesta entrada val Yes: forensicTriage. CISA demana recollir evidència abans de remeiar. I el reflex del sector davant d'un web tocat és exactament el contrari: esborrar el directori, restaurar la còpia d'ahir a la nit i respirar. Això fa dues coses dolentes alhora. Destrueix l'única cosa que contestava «què s'han endut i des de quan?», i restaura un WordPress amb el mateix forat i, si la còpia és d'abans que te n'adonessis, possiblement amb el mateix intrús a dins.

És el mateix parany que vam explicar amb el pedaç del nucli que és un reinici, només que aquí encara és més fàcil caure-hi, perquè restaurar un web sembla gratis. L'ordre que defensem és avorrit i funciona: còpia en fred del sistema de fitxers i de la base de dades abans de tocar res, els registres d'accés del servidor web a un lloc on ningú no els roti, i només llavors pedaçar. El que no estiguessis enviant a fora ja, no ho podràs mirar després.

El web de l'empresa és un servidor en producció

El que fa interessant aquesta vulnerabilitat no és el 9.2. És que posa per escrit una cosa que diem a cada reunió i que sona a sermó fins que apareix un cas: el web corporatiu és un servidor en producció, no una peça de màrqueting. Té versió, té dependències, té una configuració que algú va triar fa anys i té un camí cap a dins. La diferència amb l'ERP és que de l'ERP algú n'és amo.

Si avui haguessis de contestar en deu minuts quants WordPress té publicats la teva empresa, en quina versió, amb quin tema i sobre quin PHP, i la resposta honesta és «caldria preguntar-ho a l'agència», el problema no l'ha creat la CVE-2026-87902. L'ha ensenyat. La fallada era inevitable; que es converteixi en avaria és una decisió de disseny, i aquesta decisió es pren molt abans del dia de l'avís.

Fonts (verificades el 26-09-2026): fitxa de CVE-2026-87902 —descripció, dateAdded 2026-09-25, dueDate 2026-09-28, forensicTriage «Yes», knownRansomwareCampaignUse «Unknown» i CWE-98— llegida del fitxer JSON primari del catàleg KEV de CISA, versió 2026.09.25, 1.726 entrades. Versions afectades (4.7.0–7.1.1), les 25 branques amb pedaç, CVSS 4.0 de 9.2, vector complet, descripció de get_page_template(), data de publicació (22-09-2026), la llista de temes afectats, l'afectació de la imatge oficial de Docker i de la configuració per defecte de cPanel amb PHP anterior a 8.5, i el backport a les branques antigues «as a courtesy to users on older branches» — GHSA-7hp8-65ch-5whp. Les cinc precondicions, l'observació que els Twenty Twenty-Three, Twenty Twenty-Four i Twenty Twenty-Five revisats no portaven directori page- de primer nivell, el paper de pearcmd.php, la cronologia de divulgació i les dues cites entre cometes de l'investigador — anàlisi de Robert Ressl. Valor per defecte («1»), condició d'INI_PERDIR, deprecació al PHP 8.5 i derivació de $_SERVER['argv'] des de la cadena de consulta en SAPIs no CLI — manual del PHP; el SAPI de consola imposa la directiva i no es pot canviar des del fitxer — diferències del CLI; «Production Value: Off» i la nota del hardcoded to On for the CLI SAPI, llegides al php.ini-production de la branca PHP-8.3 del repositori del PHP i al fitxer distribuït amb el paquet de PHP 8.3 d'Ubuntu. Imatges oficials del PHP: documentació a Docker Hub. Actualitzacions automàtiques per defecte — documentació del WordPress. La sortida de consola que reproduïm és d'una màquina pròpia amb PHP 8.3.6 i paquets d'Ubuntu; en una altra distribució o amb un altre paquet la línia 690 no ha de ser la mateixa, però el comportament del SAPI de consola sí que ho és. No hem mesurat quants llocs compleixen les cinc condicions i no n'afirmem res: el mateix investigador diu explícitament que ell tampoc no ho ha fet. Foto de portada: WordPress Photo Directory (CC0).