Proxmox VE 7: el pedaç feia tres anys que era publicat i ningú sabia que era un pedaç

Imagina un porter que et demana el DNI i, si li dius «tranquil, que porto també el segon document», deixa de demanar-te el primer. No comprova el segon. Només amb esmentar-lo, s'oblida de l'altre. Això és, literalment, el que feia l'inici de sessió de Proxmox VE 7: n'hi havia prou d'enviar un paràmetre tfa-challenge amb qualsevol valor per entrar com a root@pam sense contrasenya. El codi que ho arregla es va publicar el 20 de juliol del 2023. L'avís va arribar l'1 de setembre del 2026, tres anys i sis setmanes després, quan algú va trobar el seu node xifrat.

Què fa la fallada, sense adorns

L'autenticació de Proxmox VE passa per una única crida: POST /api2/json/access/ticket. Allà s'envien usuari, contrasenya i, si escau, el segon factor mitjançant el paràmetre tfa-challenge. A les versions afectades, per als comptes sense segon factor configurat aquest paràmetre no es validava mai —no hi havia amb què comparar-lo— i, a més, la seva simple presència feia que se saltés la comprovació de la contrasenya. No és que la contrasenya es validés malament: és que no s'arribava a mirar.

El resultat és un accés sense autenticació amb què un atacant es converteix en qualsevol usuari existent i habilitat que no tingui segon factor, root@pam inclòs. El paquet vulnerable és libpve-access-control des de la versió 7.0-7 fins a la 8.0.4 sense incloure-la; l'avís ho tradueix a Proxmox VE 7.0 a 7.4, i el registre del CVE estén el rang fins a la 8.0 inicial. El CVE és CVE-2023-54391 i el mateix assignador li posa 9,8 en CVSS 3.1 i 9,3 en CVSS 4.0, amb el vector complet de xarxa, sense privilegis previs i sense interacció de l'usuari.

L'únic requisit per explotar-lo és arribar a l'API. Per defecte, el port 8006. Qui el tingui publicat a internet té una porta oberta amb el cartell posat.

El segon factor et salvava, i no pel motiu que et penses

Aquí hi ha el detall que li dona la volta a la intuïció. El paràmetre que obria la porta era el del segon factor, però l'avís és taxatiu: «els usuaris amb qualsevol segon factor configurat per a l'inici de sessió no estan afectats». En aquests comptes el tfa-challenge és un tiquet signat pel mateix servidor i la seva signatura sí que es verificava — exactament la comprovació que el pedaç de Proxmox reinsereix. La vulnerabilitat vivia just al buit dels comptes que no en tenien.

Amb una excepció que convé no perdre de vista: protegia cada compte que en tingués, no el node. N'hi havia prou que quedés un sol usuari habilitat sense segon factor —un de servei, un de monitoratge, el que vas crear per a una integració i no vas esborrar mai— perquè la porta continués oberta.

Ens agrada aquest cas perquè tanca una discussió que tenim cada pocs mesos, quan algú pregunta si val la pena posar segon factor a root@pam d'un hipervisor «que només es toca des de dins». L'argument de sempre és el robatori de contrasenyes, i és el més fluix. El bo és aquest: el segon factor és una condició extra que el codi ha d'avaluar, i cada condició extra és una branca menys per on colar-se. Aquí va acabar protegint d'una fallada lògica que ningú havia vist. Per accident, que també compta.

Tres anys entre l'arranjament i l'avís

El que converteix això en alguna cosa més que un CVE del munt és la cronologia, i no l'expliquem nosaltres: és a l'avís. El codi vulnerable va deixar d'existir el 20 de juliol del 2023, a libpve-access-control 8.0.4, com a efecte secundari d'una reelaboració del maneig de la configuració del segon factor. Ningú el va etiquetar com a arranjament de seguretat perquè ningú es va adonar que ho era, i per això —cita literal de l'avís— «no es va considerar candidat a retroportar-se a la branca de PVE 7», que en aquell moment encara tenia suport. Els dos commits d'aquells dies parlen de llegir tfa.cfg i del marcador x a user.cfg. Cap no esmenta contrasenyes.

Això trenca el model mental amb què gairebé tots gestionem pedaços: una fallada greu es descobreix, se li assigna un CVE, s'arregla i l'arranjament baixa a totes les branques vives. Aquí l'ordre va ser el contrari. I entremig la branca 7 va arribar al seu fi de suport el juliol del 2024 —segons la taula de cicle de vida del mateix projecte, alineada amb Debian 11 «Bullseye»—, així que quan l'avís es va publicar ja no hi havia ningú amb l'obligació d'arreglar-ho.

Ja vam escriure sobre l'altra cara d'això quan li va tocar a la branca 8: Debian et continua pedaçant, l'hipervisor no. Aquell post anava d'una data que passa sense que es trenqui res. Aquest va del dia, mesos o anys després, en què l'absència de mantenidor cobra la factura de cop.

Com se'n va assabentar tothom: per un fil del fòrum

La seqüència també diu alguna cosa. El 31 d'agost un usuari va obrir el fil que va posar el problema al mapa: la seva instal·lació de VE 7 havia aparegut xifrada, amb petició de rescat i els registres esborrats. Ell mateix apuntava a una queixa anterior, en xinès, del dia previ. En qüestió d'hores s'hi van sumar altres amb el mateix quadre. L'1 de setembre Proxmox va publicar l'avís PSA-2026-00043-1, «Authentication bypass in EOL Proxmox VE 7 release», explicant que havia tingut notícia del problema per «múltiples informes independents en els darrers dos dies» que a més reportaven explotació activa. Poc després va aparèixer públicament una prova de concepte.

El descobriment, per tant, va venir de les víctimes. Quan el primer canal de detecció d'una vulnerabilitat és el fòrum de suport, la finestra entre «algú ho està fent servir» i «tu te n'assabentes» ja fa un temps que és oberta, i ningú el pot mesurar.

El que es pot afirmar i el que no

Convé separar tres nivells de certesa, perquè ara mateix s'estan barrejant:

• La fallada i les versions afectades estan confirmades pel fabricant. Això no admet discussió: ho diu l'avís.
• L'explotació activa l'afirma Proxmox a partir dels informes que va rebre. En canvi, CISA no l'ha inclòs al seu catàleg KEV: ho hem comprovat al fitxer d'origen, versió 2026.09.02, i allà no hi figura CVE-2023-54391 ni cap altra entrada de Proxmox. No és una contradicció: són dos llindars d'evidència diferents, i el de CISA és més lent. Que no sigui al KEV no significa que no estigui passant.
• Els indicadors de compromís que circulen vénen de la comunitat, no de l'avís: un fitxer /var/lib/systemd/PVE-1 que va resultar ser el minador, els registres del sistema (auth.log, wtmp, btmp, lastlog, secure) substituïts per enllaços a /dev/null, i connexions sortints a un pool de mineria de Monero. Ens semblen raonables i val la pena buscar-los, però cal tractar-los com el que són: reports d'afectats, no una llista oficial.

Què mirar avui, en aquest ordre

1. Mira la versió del paquet. dpkg -l libpve-access-control. Si el número cau entre 7.0-7 i 8.0.3, aquest node és explotable. Compte amb la drecera de «menor que 8.0.4»: un PVE 6 amb la 6.4-x dona un número més baix i queda fora del rang afectat. pveversion et dona la branca, que ajuda, però la dada que decideix és al paquet.
2. Qui arriba al 8006. ss -tlnp | grep 8006 et diu que escolta; el que importa és des d'on s'hi arriba. Comprova-ho des de fora de la teva xarxa, no des de l'oficina. Si respon des d'internet, tallar aquell accés és el primer, abans que qualsevol altra cosa d'aquesta llista.
3. El registre, amb un advertiment. A /var/log/pveproxy/access.log veuràs les peticions POST /api2/json/access/ticket i la seva IP d'origen, però no el paràmetre: viatja al cos, i pveproxy anota la línia de petició a l'estil Apache, no els cossos. Busca-hi accessos des d'adreces que no reconeguis. I fes també ls -l /var/log/: en els casos reportats, auth.log, wtmp, btmp, lastlog i secure apareixien substituïts per enllaços a /dev/null. Si algun ho és, això ja és una resposta.
4. Usuaris i tokens que no vas posar tu. pveum user list i, per a cada compte, pveum user token list <usuari>@<reialme> — per exemple, pveum user token list root@pam. Un token d'API creat per l'atacant sobreviu al canvi de contrasenya i a l'actualització. És el residu que més vegades es queda enrere.
5. Les còpies, abans de tocar res. Si el node està compromès i cal reconstruir-lo, el primer que necessites és saber si les còpies de seguretat són abastables des d'aquell mateix node. Si ho són, assumeix que l'atacant també hi arribava.

Aquest últim punt no és retòric. A l'informe de ransomware del 2026 vam desgranar per què restaurar no és el mateix que recuperar, i l'ordre de les operacions importa: preservar registres i discos abans de reinstal·lar, perquè un cop formatat ja no hi ha manera de saber què s'han endut.

El pedaç d'emergència i per què el posaríem amb pinces

Proxmox publica en el mateix avís un remei provisional: un sed sobre /usr/share/perl5/PVE/AccessControl.pm que reinsereix la verificació del tiquet del segon factor, seguit del reinici de pvedaemon i pveproxy. És del fabricant, no un apedaçat de fòrum, i en un node que no pots actualitzar avui fa la seva feina. Però qui l'apliqui hauria de tenir clares tres coses: és una modificació local d'un fitxer d'un paquet, que no és sota /etc i per tant qualsevol reinstal·lació o salt de branca el sobreescriu sense preguntar; i no arregla la resta de fallades que la branca 7 no ha rebut des del juliol del 2024.

El nostre ordre seria aquest: primer tancar el 8006 a internet, que es fa en minuts i elimina el vector; després verificar si el node ja està compromès; i només llavors planificar la pujada de branca. El sed encaixa en el buit entre la segona cosa i la tercera, no en lloc de cap de les dues. I si acabes a la 9, el pas següent és deixar-la decent: això ho vam escriure sencer a hardening de Proxmox 9.2 en producció.

El que aquest cas diu del teu inventari

Muntem i mantenim aquesta infraestructura, així que direm la part incòmoda. Ningú deixa un hipervisor cinc anys sense tocar per deixadesa. El deixa perquè funciona, perquè a dins hi ha tres màquines virtuals que no es poden aturar, perquè la persona que el va muntar ja no hi és, o perquè cada vegada que s'obre el tema algú pregunta quant costa i la conversa s'acaba allà. Aquell node no és al pla de ningú precisament perquè no dona guerra.

És el mateix patró que vam explicar amb els BMC i IPMI exposats, l'ordinador que ningú manté: la peça que no apareix a l'inventari perquè no genera tiquets. I és on insistim amb una idea que repetim fins que cansa: la fallada és inevitable, l'avaria és una decisió de disseny. Que hi hagués una fallada lògica a l'inici de sessió del 2021 no ho vas decidir tu. Que aquella fallada arribés a producció tres anys després d'estar arreglada, amb la interfície publicada a internet i sense segon factor a root@pam, sí que és una cadena de decisions. Totes raonables per separat. Cap revisada mai junta.

Al gra

Entra a cada node i executa dpkg -l libpve-access-control. Si en surt un número entre 7.0-7 i 8.0.3, això és feina per a aquest matí. Després comprova des de fora si el 8006 contesta. Amb aquestes dues respostes ja saps si això és una tasca de manteniment o un incident.

I si el número surt bé, aprofita l'ensurt per fer la pregunta que de debò importa, que no va d'aquest CVE: quantes màquines tens funcionant la versió de les quals no sabries dir sense connectar-t'hi a mirar? Aquestes són les que sortiran al pròxim avís.

Fonts (consultades el 4 de setembre del 2026): la font principal és l'avís PSA-2026-00043-1, «Authentication bypass in EOL Proxmox VE 7 release», de l'1 de setembre del 2026, publicat al fil d'avisos de seguretat de Proxmox VE. D'allà surten, literalment: el rang del paquet libpve-access-control (de 7.0-7 a abans de 8.0.4) i la seva traducció a «Proxmox VE 7.0 through 7.4»; que la presència del paràmetre «feia que la verificació de la contrasenya enviada se saltés del tot»; que «els usuaris amb qualsevol segon factor configurat per a l'inici de sessió no estan afectats»; que la fallada es va tancar a la 8.0.4, publicada el 2023-07-20, com a «efecte secundari d'una reelaboració del maneig de la configuració TFA» i que «per tant no es va reconèixer com a candidat a retroportar-se a la branca de PVE 7»; els «múltiples informes independents en els darrers dos dies» amb explotació activa; i el remei provisional amb sed sobre AccessControl.pm més el reinici de pvedaemon i pveproxy. El fil d'usuaris del 31 d'agost és Proxmox VE 7 is vulnerable to some type of 0day/RCE non auth. La prova de concepte pública i el resum d'explotació — securityonline.info. Els indicadors de compromís (/var/lib/systemd/PVE-1, els registres del sistema enllaçats a /dev/null i el pool de mineria) procedeixen només de l'anàlisi de prepaid-host sobre casos reportats. Puntuacions CVSS 3.1 de 9,8 i CVSS 4.0 de 9,3, del mateix assignador, i el vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — registre del CVE i IONIX Threat Center. Que CVE-2023-54391 no figura al catàleg KEV de CISA ho hem comprovat nosaltres descarregant known_exploited_vulnerabilities.json de cisa.gov, versió de catàleg 2026.09.02: no hi apareix aquesta entrada ni cap altra de Proxmox; també ho assenyala BlackTree. Fi de suport de Proxmox VE 7 el juliol del 2024, alineat amb Debian 11 «Bullseye» — taula de cicle de vida de Proxmox VE. Matís important: els indicadors de compromís no són a l'avís oficial; convé fer-los servir com a pistes, no com a veredicte.