Veeam: dos crítics en 21 dies, i cadascun salva la branca que l'altre enfonsa

El 7 d'octubre vam escriure aquí sobre un avís de Veeam i vam repetir, perquè ho deia el fabricant, que la branca 13 no estava afectada. Aquella frase va durar vint dies. El 27 d'octubre Veeam va publicar KB4948 amb un crític de 9,1 que afecta 13.0 i 13.1, i que repeteix la mateixa nota sota cada CVE: «Older versions (e.g., 12.x) are not affected». Dos avisos, vint-i-un dies de diferència, i la clàusula tranquil·litzadora de cadascun apunta exactament a la branca que l'altre enfonsa.

No ho expliquem com una anècdota. Ho expliquem perquè la lectura habitual d'un avís és «em toca o no em toca?», i a l'octubre la resposta correcta per a un parc de Veeam va ser «et toca dues vegades, amb tres setmanes de marge, i per motius diferents». Qui es va quedar a la branca 12 per no empassar-se els canvis de la 13 es va escapar del segon i es va menjar el primer. Qui va pujar a la 13 va fer el recorregut invers. No hi havia cap branca on quedar-se quiet.

Els dos avisos, l'un al costat de l'altre

La fila de «mitigació provisional» és la que marca el ritme. Cap dels dos avisos no publica un apedaçament temporal: l'única resposta que ofereix el fabricant és pujar de build. Això converteix un servidor de còpies en una peça que cal poder aturar i actualitzar en calent, dues vegades en tres setmanes, sense que ningú hagi de demanar permís per correu a tres departaments. Si la teva finestra de canvis per a aquella màquina és trimestral, el calendari d'octubre no t'hi cap.

El 9,1 corre més que el 9,4, i el número no ho diu

Si els ordenes per puntuació, el del 6 d'octubre va primer. Si els ordenes per allò que cal per disparar-los, l'ordre es gira. Els vectors, copiats tal qual:

CVE-2025-64393  (9,4)  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
CVE-2026-108142 (9,1)  CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H

Les dues lletres que importen són PR i AT. PR:L al de 9,4 vol dir que l'atacant necessita un compte amb algun privilegi; en aquell cas concret, el rol Backup Viewer, que és el que es reparteix perquè algú miri si els treballs van sortir en verd. PR:N al de 9,1 vol dir que no en necessita cap. A canvi, el de 9,1 porta AT:P: hi ha una condició prèvia que l'atacant no controla. El de 9,4 porta AT:N, sense condicions.

Del rol Backup Viewer ja en vam escriure llargament al seu moment, quan vam sostenir que només lectura a la consola de còpies no era només lectura: el peatge d'aquell 9,4 era justament el permís que més es reparteix sense pensar-hi. La novetat d'aquest mes és que el 9,1 ni tan sols cobra peatge.

On viu la fallada nova: el servei de CDP

El component afectat és el Veeam CDP Coordinator Service, que corre al mateix servidor de còpies. La seva feina és parlar amb vCenter, repartir les tasques de protecció contínua i governar les peces que hi intervenen. A la taula de ports de Veeam apareix amb dues entrades que convé distingir: el 9509 és local, perquè el servei de backup parli amb el coordinador dins de la mateixa màquina; el 33034 és el que escolta perquè hi arribin les connexions dels proxies de CDP, dels hosts ESXi i de vCenter. El segon és el que importa aquí. La taula documenta aquells tres orígens i cap més; que qualsevol cosa que no sigui un dels tres hi sobri, en aquell port, ja és lectura nostra, no una recomanació del fabricant.

I aquí hi ha un detall de calendari que canvia la mida del problema. Durant anys, la protecció contínua de Veeam va ser una funció exclusiva de VMware vSphere, construïda sobre el filtre d'entrada/sortida de VMware (VAIO). A la 13.1, publicada el 29 de juliol de 2026, Veeam va treure Universal CDP, que mou la captura d'entrada/sortida fora de l'API de l'hipervisor i porta la protecció contínua a altres plataformes; la mateixa pàgina de producte ho resumeix com «RPO gairebé zero per a càrregues Linux amb Universal CDP». Dit d'una altra manera: el component on ha aparegut la fallada sense credencials és, just a la branca on ha aparegut, el que ha deixat de ser cosa només de qui té vSphere.

El que l'avís no et diu, que és just el que necessites

L'avís llista builds afectades i builds que corregeixen. El que no diu en cap punt és si el CDP Coordinator Service està aixecat i escoltant a tota instal·lació de la branca 13, o només on hi ha polítiques de protecció contínua configurades. Aquella diferència és la que separa «això m'afecta a mi» de «això afecta uns altres», i el document no et deixa contestar-la. Així que no la contestis llegint: ves a mirar la màquina. En aquest ordre, i sense saltar-te el primer perquè et pensis que ja te'l saps:

• La build exacta, no la branca. «Anem per la 13» no serveix: la frontera és a 13.1.1.18 i a 13.0.2.29. Surt a Ajuda > Quant a, a la consola.
• Si el 33034 escolta en aquell servidor, i des d'on s'hi arriba. Un servei que no escolta no s'ataca per xarxa; un que escolta i accepta mitja empresa, sí.
• Qui té els rols Backup Viewer i Restore Operator. Són el peatge de les altres fallades del parell d'avisos.
• La versió de l'agent de Linux, que va pel seu compte i té el seu propi CVE al mateix avís.

# Windows (servidor de copias)
netstat -ano | findstr ":33034"

# Veeam Software Appliance / Linux
ss -lntp | grep ':33034'

# desde otra maquina: ¿a quien le responde?
nc -zv <servidor-de-copias> 33034

La tercera ordre és la que de debò informa, perquè no pregunta què hi ha instal·lat sinó qui hi arriba. Si et respon des del portàtil d'administració, des de la xarxa d'usuaris o des de qualsevol lloc que no sigui un proxy de CDP, un ESXi o el vCenter, tens dues feines per endavant: pujar la build i, després, arreglar el motiu pel qual aquell port estava obert a qui no tocava. El pedaç tapa aquesta fallada; l'abast de xarxa et deixa exposat a la següent.

Els altres tres CVE del mateix avís

KB4948 no porta només el crític. Porta dues de severitat mitjana, CVE-2026-108140 i CVE-2026-108141, totes dues de 5,9 i amb la mateixa descripció: un usuari autenticat amb el rol Restore Operator que a més controla el contingut d'un recurs NAS copiat pot escriure fitxers que ell controla en una ruta arbitrària del servidor de còpies, mitjançant recorregut de rutes relatives. Aquella segona condició no és menor, i Veeam les puntua amb PR:H, no amb PR:L: en la seva lectura, aquell rol compta com a privilegi alt. I porta CVE-2026-105477, de 7,3, una escalada local de privilegis a l'agent de Veeam per a Linux, que afecta 13.1.1.4 i anteriors de la 13.1 i es corregeix a 13.1.2.11.

El rol dels dos mitjans mereix un apunt. Restore Operator és, per disseny, el permís que dones a algú perquè pugui recuperar coses sense ser administrador del servidor de còpies; és a dir, el permís del qual presumeix qualsevol pla de recuperació ben repartit. Dues de les quatre fallades d'aquest avís es disparen des de rols que existeixen precisament per no haver de repartir el d'administrador. Separar funcions continua estant bé; el que no es pot és explicar-ho com si el rol petit fos inofensiu.

La part que no arregla cap pedaç

L'octubre va deixar una cosa clara i és més incòmoda que qualsevol dels quatre CVE: el servidor de còpies és un objectiu, no un espectador. Té el seu propi ritme d'avisos, els seus propis serveis escoltant i els seus propis rols repartits, i res d'això no depèn de com de bé facis les còpies. És un servidor més, amb la particularitat que és el que ha de continuar dempeus quan els altres no hi són.

La conseqüència pràctica és d'aïllament, i ja la vam desenvolupar quan vam explicar per què el servidor de còpies dins del domini és una dependència circular: si la màquina que et salva comparteix autenticació i xarxa amb allò que ha caigut, no et salva. L'octubre hi afegeix una capa de calendari: qui necessiti el vistiplau de tres departaments per tocar aquella màquina arribarà tard al pròxim avís, i hi haurà un pròxim avís.

A everyWAN això cau a compliment i continuïtat, perquè l'RTO i l'RPO que signes en un pla depenen d'una màquina concreta que algú ha de mantenir dreta i al dia, i a manteniment informàtic, que és on viu la part avorrida: l'inventari de builds i la cadència de pedaçat. Ho diem sense adorns, perquè és el que hem vist: gairebé ningú no té escrit enlloc quina build del seu programari de còpies està corrent avui, i és la primera dada que demana qualsevol d'aquests dos avisos.

I una cosa més, per honestedat: res d'això no diu que Veeam sigui pitjor que la resta. Un fabricant que publica quatre CVE amb vector, builds exactes i data està fent la seva feina; el silenci seria molt pitjor notícia. El que l'octubre demostra no va de marques: l'estratègia de «em quedo a la versió anterior fins que la nova maduri» no és una posició defensiva. És, simplement, una altra aposta.

Fonts. CVE-2026-108142, CVE-2026-108140, CVE-2026-108141 i CVE-2026-105477, amb les seves puntuacions, builds afectades, builds corregides i la frase «Older versions (e.g., 12.x) are not affected» — avís KB4948 de Veeam, 27-oct-2026. CVE-2025-64393 i la nota que la v13 no estava afectada — avís KB4934 de Veeam, 06-oct-2026. Ports 9509 i 33034 del CDP Coordinator Service i els orígens documentats per a cadascun — taula de ports de la documentació de Veeam. «RPO gairebé zero per a càrregues Linux amb Universal CDP» — pàgina de producte de Veeam Data Platform 13.1; la data de disponibilitat general, el 29 de juliol de 2026, és a la nota de premsa de Veeam, no pas a la pàgina de producte. Que la protecció contínua va ser exclusiva de VMware vSphere fins a la 13.1 i es recolzava en el filtre VAIO ho documenta Chris Childerhose a la comunitat de Veeam; és una font de comunitat (Veeam Legend), no documentació oficial, i així ho assenyalem. La lectura comparada dels dos vectors i la hipòtesi sobre l'AT:P són nostres i estan marcades com a tals al text. Dedupe declarat: KB4934 i el rol Backup Viewer els vam publicar el 07-10-2026; la novetat aquí és KB4948, la simetria entre les dues branques i l'encaix amb Universal CDP. Les frases dels avisos es reprodueixen en el seu anglès original; la de la pàgina de producte va traduïda. Els identificadors, puntuacions, vectors i builds es reprodueixen tal qual.