cPanel CVE-2026-58048: a l'allotjament compartit, el risc el posa el veí

El 31 de juliol es van publicar dues fallades de cPanel & WHM. La que s'ha endut els titulars és CVE-2026-58048, un 9,4 sobre 10: canviant el nom d'una base de dades, un client normal del servidor podia acabar executant SQL en el context de root. Però el número que de debò descriu el problema no és el 9,4. És al final del vector, on gairebé ningú no mira: SC:H/SI:H/SA:H.

Escrivim sobre això perquè és un cas de manual d'una cosa que es discuteix poc i es pateix bastant: en una màquina compartida, la teva superfície d'atac inclou gent que tu no has triat. No és una crítica a l'allotjament compartit —després arribem a aquesta pregunta, i la resposta no és la que s'espera—. És que el model d'amenaça és diferent, i aquest parell de CVE ho deixen per escrit amb una precisió poc habitual.

La fallada, en una frase de la mateixa fitxa

La descripció oficial cap en una ratlla: «conservació incorrecta del mode SQL en canviar el nom de bases de dades a cPanel permet l'execució de SQL en el context de root». Està classificat com a CWE-89, injecció SQL, i el crèdit és de Vincent55 Yang.

Canviar el nom d'una base de dades no és una operació atòmica. Segons la documentació de cPanel, recollida per The Hacker News, en canviar el nom el sistema «crea una base de dades de reemplaçament, mou les dades originals, recrea els permisos i el codi emmagatzemat i després elimina l'antiga». És una seqüència llarga de SQL que el panell executa per tu, amb els seus privilegis, a partir d'un nom que tu escrius.

El que cal per arribar-hi és el més interessant. El vector publicat diu PR:L: privilegis baixos, no cap. Cal un compte vàlid al servidor i permís per fer servir la funció de MySQL o MariaDB. Dit d'una altra manera: en un servidor d'allotjament compartit, el requisit previ de l'atac és un formulari d'alta. I UI:N: no cal que ningú faci clic en res.

La cua del vector: on CVSS 4.0 diu «això surt d'aquí»

El vector complet és CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. Els tres primers impactes (VC, VI, VA) parlen del sistema vulnerable. Els tres últims (SC, SI, SA) parlen del sistema posterior: el que hi ha a l'altra banda del component que falla.

Aquesta separació és l'aportació de CVSS 4.0 que menys es fa servir i més diu. L'especificació demana el contrari per defecte: «quan una vulnerabilitat no té impacte fora del sistema vulnerable, qui l'avalua hauria de deixar les mètriques de sistema posterior en CAP». Aquí no hi són en cap, hi són les tres en High. On acaba un sistema i comença el següent és un judici, no un fet —la mateixa especificació posa l'exemple d'una base de dades que només fa servir un altaveu intel·ligent i que, per tant, és part de l'altaveu—, així que el vector sol, en abstracte, no tanca la discussió. Però és que el fabricant la tanca sense mètriques: sobre aquesta fallada diu que «això es pot estendre a un compromís a nivell de sistema operatiu».

I en una màquina compartida, «el sistema posterior» té nom i cognoms. És el CRM de l'assessoria del segon, la botiga del fabricant del costat i la teva web. La paraula «posterior» és molt freda per al que descriu: el sistema posterior és el d'un altre.

El CVE de 5,6 que ho diu encara més clar

El mateix dia, el mateix investigador i la mateixa tanda de pedaços van portar CVE-2026-58047: «HTTP smuggling a cPanel permet una possible filtració de credencials», classificat com a CWE-444, a cpsrvd, el dimoni que serveix les interfícies de cPanel i WHM. Puntua 5,6: mitjà. Ningú no obrirà una finestra d'emergència per un 5,6.

Ara el seu vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:H/SI:H/SA:L. Llegeix-lo sencer, que és del que va aquest article. Sense autenticar (PR:N), però amb dos frens que el mateix vector declara: AT:P, calen condicions del desplegament que l'atacant no controla, i UI:P, algú ha d'estar fent servir el panell en aquell moment. The Hacker News ho resumeix en tres paraules: under limited conditions. I ara els impactes: baix al sistema vulnerable (VC:L/VI:L), alt al posterior (SC:H/SI:H). Traduït: fa poc mal on entra i molt mal a un tercer —a qui se li retorna la resposta contaminada, que és un altre usuari del mateix servidor—.

Aquí el fabricant ens va estalviar la decisió: els dos registres llisten exactament les mateixes versions i la mateixa tanda de builds tanca les dues fallades. Però arriben per separat molt sovint, i aleshores un criteri de pedaçat que filtra per «crítics» s'endú el 9,4 i deixa el 5,6 per al mes que ve —i el 5,6 és el que no demana compte de client—. La severitat global barreja en un sol número «quant costa arribar-hi» i «quant mal fa»; en multi-tenant aquestes dues coses no van juntes, i ordenar la cua de pedaçat pel número gran és ordenar-la per la primera quan el que et preocupa és la segona.

El que l'avís NO diu (i convé no inventar-se)

Toca abaixar el pols. L'enriquiment de CISA sobre tots dos CVE, amb data del 31 de juliol, registra explotació: cap i automatitzable: no. Cap dels dos no és, a data d'avui, al catàleg de vulnerabilitats explotades. No hi ha una campanya en marxa.

Amb un matís que sovint es malinterpreta: «automatitzable: no» no vol dir «difícil». Vol dir que l'atacant no pot recórrer internet llançant el mateix payload a cegues, perquè abans necessita un compte en aquest servidor. En un panell d'allotjament, aquest pas previ té un preu de tarifa. És una barrera econòmica, no tècnica, i les barreres econòmiques baixen quan l'objectiu puja de valor. Sobre l'impacte tècnic, en canvi, el registre de CISA no matisa res: el classifica com a total per al 9,4.

Què cal comprovar aquesta setmana

• En quina build estàs. Les versions corregides són 11.110.0.137, 11.118.0.71, 11.126.0.78, 11.134.0.48 i 11.136.0.32, més 11.138.1.6 per a WP Squared. Cinc branques vives de cPanel alhora, i la mateixa tanda tanca els dos CVE: així de repartit està el parc entre els tiers LTS, STABLE, RELEASE i CURRENT.
• Que el rellotge de seguretat estigui corrent. La bona notícia primer: per defecte, el sistema aplica cada hora, mitjançant una tasca programada, les actualitzacions de seguretat de la teva versió major, i ho fa fins i tot si has desactivat les actualitzacions de versió o les has posat en manual. La lletra petita, a la mateixa frase de la documentació de WHM, és la que importa: aquest cron no s'executa si el servidor està fixat a una versió concreta. És a dir, la màquina que algú va clavar en una build fa anys perquè «no es trenqués res» és exactament la que no s'està pedaçant sola. Comprovar-ho costa un minut.
• Si no pots actualitzar avui, la mitigació del 9,4. Revocar la funcionalitat «MySQL» als comptes de cPanel. La mateixa nota ho acota amb honestedat: «això no deshabilita les bases de dades existents, només impedeix afegir-les o eliminar-les». Els llocs continuen funcionant i desapareix el camí de l'atac.
• I la del 5,6, que gairebé ningú no esmenta. Desactivar la reutilització de connexions de backend amb cpsrvd_keepalives_disabled=1 a /var/cpanel/cpanel.config. No és gratis: obliga a una connexió TCP i TLS nova per petició als ports 2083, 2087 i 2096, amb més latència i més CPU en servidors carregats. Si el post t'ha convençut que el 5,6 és el que més t'afecta com a veí, aquesta és la casella que ho demostra.
• La pregunta que gairebé ningú no sap respondre. En quin servidor és la teva web i qui més hi ha? No és una pregunta retòrica: a moltes empreses, l'allotjament es va contractar fa vuit anys, el gestiona l'agència que va fer el disseny i ningú de dins no té accés al panell. Si ningú no sap contestar, aquesta és la troballa del dia, i no el CVE.

Aquesta última pregunta ja l'hem feta aquí des d'un altre angle, quan vam parlar de qui manté de debò el teu WordPress. Canvia el producte, no canvia el buit: la web de l'empresa és, a moltes organitzacions, l'únic sistema de producció sense amo intern.

La part incòmoda: cal sortir del compartit?

Aquí és on tocaria el paràgraf de vendre. No l'escriurem, perquè seria fals. Per a moltíssims llocs, l'allotjament compartit és la decisió correcta, i ho continuaria sent demà: una web corporativa estàtica, un blog, una landing. Treure'ls d'allà és pagar més per gestionar més i dormir exactament igual de bé.

El que sí que canvia és què pots prometre. En compartit no controles el veïnat: no tries qui més té compte, no audites el seu codi i no decideixes quan es pedaça la màquina. Això no és una anomalia ni un defecte del proveïdor; és literalment el que estàs comprant quan el preu es divideix entre tres-cents. L'error no és contractar-ho: l'error és contractar-ho i després prometre a un client, o a un auditor, un aïllament que aquest model no va oferir mai.

El nostre criteri, després d'anys muntant infraestructura per a aplicacions de negoci, cap en una pregunta: què hi ha dins de la base de dades? Si són entrades de blog, endavant. Si són dades personals de clients, comandes, historial mèdic o el catàleg amb preus de compra, l'aïllament deixa de ser una qüestió de rendiment i passa a ser una qüestió de a qui has de respondre. Quan hi entren obligacions pel mig —i la llista de qui queda dins s'ha ampliat bastant—, «estava en un compartit» no és una resposta que se sostingui en un qüestionari de proveïdor.

El patró que es repeteix: la superfície que no vas triar

Fa uns dies vam escriure sobre una fallada de Rails que en realitat era en una biblioteca d'imatges que ningú no havia triat conscientment. Aquest és el mateix animal, un pis més avall: el risc no entra pel codi que vas encarregar, sinó pel que va venir a sota. Allà era una dependència; aquí és un veí.

I en tots dos casos la defensa útil és la mateixa, i és avorrida: saber què tens a sota abans que algú publiqui un CVE sobre allò. No hi ha eina que ho resolgui. Hi ha un inventari i hi ha un responsable.

Si vols que mirem on viu de debò la teva aplicació, què hi ha a la seva base de dades i quin aïllament necessita —o si no en necessita cap, que també passa—, això és part del que fem a dades i aplicacions; i quan la resposta passa per maquinari propi al centre de dades, a colocation.

Fonts (verificades el 7 d'agost de 2026): l'identificador, la descripció literal («conservació incorrecta del mode SQL en canviar el nom de bases de dades a cPanel permet l'execució de SQL en el context de root»), la classificació CWE-89, el vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H amb puntuació 9,4 CRÍTICA, la data de publicació (31 de juliol de 2026), el crèdit a Vincent55 Yang, les versions afectades i les corregides (11.110.0.137, 11.118.0.71, 11.126.0.78, 11.134.0.48, 11.136.0.32 i WP Squared 11.138.1.6) i l'enriquiment SSVC de CISA (explotació: cap; automatitzable: no; impacte tècnic: total) provenen del registre oficial de CVE-2026-58048, assignat per HackerOne com a CNA, consultat a l'API de MITRE. Les mateixes dades per a CVE-2026-58047 («HTTP smuggling a cPanel permet una possible filtració de credencials», CWE-444, vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:H/SI:H/SA:L, 5,6 MITJÀ, impacte tècnic: parcial). Que cpsrvd és el dimoni que serveix les interfícies de cPanel i WHM, la descripció del procés de canvi de nom atribuïda a la documentació de cPanel («crea una base de dades de reemplaçament, mou les dades originals, recrea els permisos i el codi emmagatzemat i després elimina l'antiga»), la frase del fabricant «això es pot estendre a un compromís a nivell de sistema operatiu», el «under limited conditions» de la segona fallada i la seva mitigació (cpsrvd_keepalives_disabled=1 a /var/cpanel/cpanel.config, que força connexió TCP i TLS nova per petició als ports 2083, 2087 i 2096, amb el seu cost en latència i CPU) provenen de la cobertura de The Hacker News. La mitigació temporal de revocar la funcionalitat MySQL («no deshabilita les bases de dades existents, només impedeix afegir-les o eliminar-les») consta allà i a Security Affairs. La distinció entre sistema vulnerable i sistema posterior, la frase «quan una vulnerabilitat no té impacte fora del sistema vulnerable, qui l'avalua hauria de deixar les mètriques de sistema posterior en CAP» i l'exemple de la base de dades que només fa servir un altaveu intel·ligent, del document d'especificació de CVSS v4.0 de FIRST. Que per defecte el sistema aplica cada hora, mitjançant una tasca programada, les actualitzacions de seguretat de la versió major actual, que aquest cron s'executa encara que es desactivin les actualitzacions de versió o es posin en manual, i que no s'executa si el servidor està fixat a una versió concreta, de la documentació de preferències d'actualització de WHM, d'on surten també els noms dels tiers. No hem reproduït cap de les dues fallades: aquest article és una lectura de les fitxes públiques, de la documentació del fabricant i de la cobertura citada, i així es diu. Fotografia de la imatge social: façana d'edifici residencial amb balcons, rawpixel, domini públic (CC0).