La pregunta que arriba a un equip de sistemes quan surt un CVE gros sempre és la mateixa: «nosaltres estem afectats?». I la resposta que acostuma a bastar per tancar el fil, també: «l'escàner diu que no». Avui hem anat a mirar què té l'escàner sobre la taula per poder dir això amb aquest CVE concret. La resposta curta és que no té res.
Parlem de CVE-2023-54391, la fallada d'autenticació de Proxmox VE de la qual ja vam escriure quan va sortir l'avís. Aquell post anava del forat: a l'endpoint de login de l'API, enviar qualsevol valor al paràmetre tfa-challenge salta sencera la verificació de la contrasenya per a qualsevol compte sense segon factor, root@pam inclòs. Aquest va d'una altra cosa: de per què, tres setmanes després, encara és difícil contestar si tu el tens o no.
El que torna la fitxa, camp a camp
Un escàner de vulnerabilitats no sap res de Proxmox. Sap llegir una llista de versions afectades i comparar-la amb el que troba a la teva màquina. Aquesta llista surt gairebé sempre de dos llocs: la fitxa de NVD i la base d'avisos de GitHub. Aquest matí hem demanat totes dues per API. Aquests són els camps que importen.
- →A NVD,
configurationsval null. No hi ha cap sentència CPE: ni un sol identificador de producte i versió contra el qual contrastar el que es veu a la teva xarxa. - →
vulnStatusés «Deferred». És l'etiqueta amb què NVD diu que no enriquirà aquell registre. El buit de dalt no és un retard: és l'estat final previst. - →A GitHub, l'avís GHSA-m457-grcf-698x existeix, diu critical i porta les dues notes —9,8 a CVSS 3.1 i 9,3 a CVSS 4.0—, però el seu camp
vulnerabilitiesés un array buit. El perquè és dos camps més avall:type: "unreviewed"igithub_reviewed_at: null. Ningú de GitHub hi ha passat a emplenar el rang, i sense revisió no hi ha rang. - →L'únic estructurat el va posar l'assignador del CVE, que no és Proxmox:
defaultStatus«unaffected», i dues entrades afectades,{version: "7.0", lessThanOrEqual: "7.4"}i{version: "8.0"}, totes dues ambversionType: "custom".
Aquest últim camp és el que desmunta la comprovació automàtica. versionType: "custom" significa, literalment, que no es declara cap esquema de comparació. Una eina llegeix «afectat fins a 7.4 inclòs», es troba un node que es presenta com pve-manager/7.4-17 i ha de decidir sola. Amb l'ordre de versions de Debian, que és el que s'aplica a un .deb, 7.4-17 és la revisió 17 de l'upstream 7.4 i queda per sobre d'un «7.4» a seques: fora del rang, node en verd. Amb regles tipus semver sortiria justament el contrari, perquè allà el sufix baixa la precedència i el node hi entraria. Dues eines raonables, dos veredictes oposats sobre la mateixa màquina. Això és exactament el que vol dir no declarar l'esquema.
I hi ha dos silencis més a la mateixa fitxa. El primer ja el vam comprovar el 4 de setembre: aquest CVE no era al catàleg KEV de CISA. L'hem tornat a descarregar avui, versió 2026.09.22, i continua sense ser-hi; tampoc no hi ha cap altra entrada de Proxmox a tot el catàleg. El que és nou no és l'absència, és que duri tres setmanes. El segon és dins del mateix registre del NVD: un bloc SSVC signat per «CISA Coordinator» el 2 de setembre que marca automatable: yes i technicalImpact: total, i alhora exploitation: none. Afegeix-hi l'EPSS que torna GitHub, 1,75 % al percentil 76,8, i tens un 9,8 al qual tots els semàfors automàtics donen ambre.
El pedaç que sí que existeix per a la branca 7
La correcció no és a l'hipervisor, és al paquet libpve-access-control, que es numera en una altra sèrie; i a la branca 7 no hi ha cap versió que la porti, perquè el codi es va tancar dins la 8.0.4 i Proxmox reconeix al seu avís que llavors «no es va reconèixer com a candidat a retroportar-se a la branca de PVE 7». Això ja ho vam explicar a principis de mes i es comprova en dos minuts: la branca stable-7 del repositori públic de pve-access-control mor a la 7.4.3, amb data de febrer de 2024, i els dos commits del pedaç no hi són.
El que gairebé ningú ha explicat, i és la part útil, és que en aquell mateix avís Proxmox va publicar un pedaç per a qui no pugui migrar ara. És un script curt que afegeix la validació que faltava: a partir d'aquí tot tfa-challenge ha de ser un tiquet signat i vàlid, que un atacant no pot fabricar, i ni el login normal ni el de dos factors deixen de funcionar. Aplicar-lo a mà no és migrar, i el node continua estant fora de suport amb tot el que això arrossega. Però tanca aquesta porta avui, i la migració es planifica en fred en comptes de a les dues de la matinada.
Mil cent màquines, dotze hipervisors, disset dies
Tot l'anterior seria una discussió de metadades si no tingués factura. En té, i està publicada. Un proveïdor d'allotjament finlandès, Pulsed Media, va publicar el 20 de setembre un avís explicant que una campanya automatitzada de minat de criptomoneda havia aconseguit root en dotze dels seus hipervisors Proxmox VE. L'entrada va ser aquest CVE. La finestra va del 31 d'agost al 17 de setembre, dia en què ells mateixos la van detectar i la van tallar: disset dies. I donen una dada que no havíem vist enlloc més: «Roughly eleven hundred machines worldwide were in this campaign».
Que ho publiquessin amb aquell detall és més del que fa la majoria, i per això aquest post porta dades en comptes de suposicions. El seu avís enumera el que van fer: van treure el programari maliciós i cada mecanisme de persistència que van identificar, van tancar l'entrada als dotze hosts, van restablir el registre que l'atacant havia apagat, van rotar les contrasenyes d'accés als hosts i van restringir la interfície de gestió de Proxmox a les seves pròpies xarxes. Els sistemes de contacte, facturació i pagaments no es van veure compromesos.
Convé llegir a poc a poc aquell «van restablir el registre»: van tornar a encendre el mecanisme, no van recuperar el que l'atacant ja havia esborrat. D'aquí surt la frase que ens sembla la més important de tot l'avís. No van trobar indicis que les dades de clients fossin llegides, copiades o modificades, i tot seguit escriuen, literal, «the deleted logs mean we cannot prove it either way». Per això van avisar els clients afectats que tractessin les seves dades com a potencialment exposades.
Aquí hi ha el cost real, i no és el de la CPU que algú et va robar per minar. La mineria és el soroll. El que és car és la distància entre «no va passar res» i «no puc demostrar que no passés res», perquè la segona és la que es diu davant d'un client, d'una asseguradora o de qui pregunta per l'article 33. Aquesta distància no la va decidir l'atacant el dia de l'incident; la va decidir, mesos abans, qui va deixar que els registres visquessin només a la màquina que els genera. És el mateix patró del qual ja vam escriure per un altre camí: pedaçar el nucli és reiniciar, i reiniciar esborra la prova.
Quatre comprovacions, deu minuts per node
- Pregunta pel paquet, no pel producte.
dpkg-query -W -f '${Version}\n' libpve-access-controla cada node, que és l'ordre que recomana el mateix avís (pveversion -vtambé serveix i de passada llista la resta). El rang afectat és exacte: >= 7.0-7 i < 8.0.4. No miris si és «de la sèrie 7»: mira si cau dins d'aquest rang. Un node amb 8.0.2 també hi entra, i és justament el que s'escola per la regla mental de «jo ja vaig per la 8». - Mira qui pot arribar a l'API. El requisit de l'atac és assolir el port de gestió, 8006 per defecte.
ss -lntp | grep 8006et diu a quina interfície escolta; el teu tallafoc et diu des d'on s'hi arriba. Si la resposta al segon és «des d'internet», tens una tasca per a avui independentment de la versió. - Compta els comptes sense segon factor. La fallada no afecta els usuaris que tenen un segon factor configurat, però aquesta protecció és per compte i no per node: n'hi ha prou amb un compte vell sense TOTP perquè el clúster sencer sigui assolible. La configuració viu a
/etc/pve/priv/tfa.cfgi a la interfície és a Datacenter → Permissions → Two Factor. Compara-la amb la llista d'usuaris, no amb la d'administradors. - Comprova que els teus registres surten del host. Aquesta no és una comprovació d'aquest CVE: és la que decideix si algun dia podràs contestar què va passar. Si l'
auth.logd'un node només existeix en aquell node, la teva capacitat de demostrar res depèn que l'atacant no el toqui, i ja hem vist a dalt amb quin mètode comença.
Per a un parc de vint nodes això és un matí, i en surt un inventari que serveix per al següent avís i per al de després. Si a més migraràs aquests nodes, les decisions d'accés i tallafoc convé prendre-les durant la migració, no en acabar-la: les tenim ordenades a la nostra guia de hardening de Proxmox per a producció.
El que no et recomanarem
- ✗Canviar d'escàner. El següent llegirà les mateixes dues bases de dades i tornarà el mateix silenci. El problema no és a l'eina, és a la dada que no existeix.
- ✗Migrar de cop «perquè hi ha un 9,8». Una migració amb presses trenca més del que arregla. Si no pots migrar aquesta setmana, aplica el pedaç que va publicar el fabricant i restringeix la interfície de gestió a les teves xarxes. Això es fa avui, amb la migració planificada per quan toqui.
- ✗Donar per bona la neteja i continuar. Si un host va estar compromès amb accés root, «l'hem netejat» és una hipòtesi. Reinstal·lar és més barat que sostenir aquesta hipòtesi durant dos anys, i sens dubte més barat que defensar-la davant d'un client.
Com ho muntem nosaltres
Quan el control preventiu no pot respondre —i avui, amb aquest CVE, no pot—, el que queda és detectar i poder demostrar. Per això el servei d'EDR i detecció gestionada que operem no acaba a l'agent instal·lat: la telemetria i els registres surten del host i es desen fora, amb retenció pròpia, perquè esborrar-los a la màquina no esborri la resposta. I al darrere hi ha gent de guàrdia, perquè la finestra entre que passa alguna cosa i algú mira és la variable sobre la qual de debò es mana. Disset dies és el que arriba a mesurar aquesta finestra; ningú no l'escull, s'hereta del torn que es té.
«Publicat» no és «aplicat», i «no surt a l'escàner» no és «no m'afecta». El primer ho vam explicar amb un pedaç que feia 97 dies que estava disponible; el segon és aquest post. Són la mateixa frase dita dues vegades, i les dues vegades surt cara pel mateix motiu: el sistema que t'avisa no és el mateix que et protegeix.
Fonts (consultades el 23-set-2026): els camps configurations, vulnStatus, affected i el bloc SSVC els hem llegit a la resposta de l'API 2.0 del NVD (marca de temps 2026-09-23T06:32 UTC); el vulnerabilities: [], el type: "unreviewed" i l'EPSS, a l'API de GitHub Advisories; l'absència al catàleg, al KEV de CISA, versió 2026.09.22. El rang >= 7.0-7 i < 8.0.4, l'ordre de comprovació, el pedaç per a qui no pot migrar i la frase sobre el retroport són a l'avís PSA-2026-00043-1 de Proxmox; la branca stable-7 es comprova al repositori públic de pve-access-control. L'incident, les dates, les xifres i les cites literals, a l'avís públic de Pulsed Media del 20-set-2026. El que aquest post NO afirma: no hem reproduït l'atac ni verificat cap indicador tècnic de compromís en un laboratori propi, i la campanya de mil cent màquines l'afirma aquell proveïdor, no una font independent.
Podries demostrar avui què va passar als teus hipervisors el mes passat?
A everyWAN operem Proxmox en producció des de fa anys, amb detecció gestionada i registres que surten del host. Si vols l'inventari de les quatre comprovacions de dalt sobre el teu parc, el fem i te'l lliurem per escrit, amb el que surti.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN