L'arranjament no demana finestra ni reinici, i per això pot ser que no hi sigui

L'avís de Cisco del 14 d'octubre té la forma de sempre: un 9,8, un aparell al perímetre i explotació activa abans que es publiqués res. El que no té la forma de sempre és a la taula de versions corregides, en una frase que descol·loca el procediment que tens escrit per a aquests casos: «Updating the Content Scanner Tools does not require a software upgrade or a product restart».

És una bona notícia: l'arranjament no t'obliga a saltar de branca, ni a aturar el correu de l'empresa un dissabte a la nit. I és exactament per això que pot ser que no hi sigui. El procés de pedaços de gairebé totes les empreses que ens trobem està fet de quatre peces: un tiquet, una aprovació, una finestra i un reinici que confirma que s'ha fet. Un arranjament que no necessita cap de les quatre no és que sigui fàcil d'aplicar: és que no deixa rastre d'haver-se aplicat ni de no haver-se aplicat.

Què diu l'avís, en curt

CVE-2026-76519, avís cisco-sa-esa-afw-zqYJkjxp, publicat el 14 d'octubre de 2026 a les 16:00 GMT en versió 1.0 final. CVSS 3.1 base 9,8, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: per xarxa, sense credencials, sense que ningú hagi de fer clic. Afecta Cisco Secure Email Gateway, físic i virtual, i el mateix avís diu que «in October 2026, the Cisco PSIRT became aware of active exploitation of this vulnerability». CISA el va posar al seu catàleg de vulnerabilitats explotades el mateix dia 14, amb data límit federal del 17 d'octubre i classificat com a CWE-23, travessia de ruta relativa.

La fitxa de CISA descriu la capacitat sense adorns: permet «an unauthenticated, remote attacker to write arbitrary files on the underlying operating system». La cobertura del dia —BleepingComputer, The Hacker News— hi afegeix que el que s'aconsegueix per aquí és execució amb privilegis de root, i que el disparador és un correu amb un adjunt manipulat. És a dir: no cal entrar enlloc; n'hi ha prou d'escriure a qualsevol bústia que passi per l'aparell. I l'aparell és, per definició, el que veu tot el correu de l'empresa.

Hi ha dues condicions, i totes dues s'han de donar alhora. La primera: «the File Reputation service, which is part of Cisco AMP, is enabled and assigned to a mail policy». La segona: «the Content Scanner Tools version is earlier than 25.3.0.5525». Mitigacions, cap: «there are no workarounds that address this vulnerability». Versions corregides d'AsyncOS: 15.5.5-014 a la branca 15.5 i 16.5.0-780 a la 16.5; per a la branca 16.0 l'avís no dona número, diu «Migrate to fixed release».

«Estem afectats?» té tres respostes, i cap no és a l'inventari

Aquesta és la part que ens interessa de debò, perquè és la que es repeteix amb qualsevol altre fabricant. La pregunta sembla d'inventari i no ho és. Per contestar-la calen tres dades que viuen en tres llocs diferents, i la que tu guardes no és cap de les tres.

• Una fila d'una política de correu. L'avís t'envia a mirar a Mail Policies > Incoming Mail Policies > Advanced Malware Protection (o la de sortida). Algú ho va decidir un dia, política per política, així que pot estar posat en una i no en una altra. Qui administra el sistema gairebé mai no s'ho sap de memòria.
• La versió d'un motor que no és la de l'aparell. L'avís indica l'ordre exacta: «use the contentscannerstatus command at the CLI». Són dos números que no es mouen junts: l'avís corregeix branques d'AsyncOS, però l'arranjament viatja en el paquet del motor, de manera que la versió que tu inventariaries no et diu si el motor és a 25.3.0.5525.
• Si l'aparell pot sortir a buscar-lo. El paquet del motor es descarrega dels servidors d'actualització de Cisco. El fabricant publica fins i tot hosts estàtics «for customers that have strict firewall or proxy requirements» —updates-static.ironport.com i downloads-static.ironport.com, pel port 80—, cosa que és tant com reconèixer que hi ha molts aparells als quals no es deixa sortir al carrer sense permís. Aquella regla de tallafocs la va escriure seguretat, amb bon criteri, probablement fa anys.

El que tu guardes, en canvi, és la versió d'AsyncOS. És el número que surt a l'informe, el que es mira a l'auditoria i el que es compara amb l'avís. I en aquest cas concret no contesta la pregunta.

La columna que pot dir «Never updated»

A la guia de referència de la CLI d'AsyncOS, l'exemple de sortida que el mateix fabricant posa per a aquella ordre és aquest:

mail.example.com> contentscannerstatus
Component                           Version    Last Updated
Content Scanner Engine              1.0        Never updated

És un exemple de manual, no una mesura de res: no diu que hi hagi aparells allà fora sense actualitzar mai. Diu una cosa més modesta i més útil: que «Last Updated» és una columna que existeix i que pot dir «mai». Algú va dissenyar aquell camp perquè calia. Al mateix lloc on esbrines si estàs exposat hi ha la data que et diu quant fa que aquell motor no canvia, i aquella data és, a la pràctica, l'auditoria d'un canal d'actualització que ningú no signa.

I l'hora importa: pedaçat no és net

Aquí és on un arranjament silenciós deixa de ser una comoditat i passa a ser un problema d'ordre. La vulnerabilitat permet escriure fitxers. Actualitzar el motor tanca la porta per on s'escriuen; no toca el que ja es va escriure. Un aparell corregit pot ser un aparell compromès, i totes dues coses són compatibles sense contradicció.

La fitxa de CISA per a aquest CVE porta marcat el camp de triatge forense. La guia d'implantació de la directiva BOD 26-04, que és la que ho regula, ho escriu sense embuts: «do not alter or remediate systems prior to evidence/artifact collection when possible», i explica el motiu amb una frase que convé rellegir: «patching may jeopardize the availability of artifacts». La seqüència que marca no és lenta —recollida en 2-24 hores, pedaç en 2-24 hores, prioritzant el volàtil: el registre del sistema, la memòria cau i la RAM—, però és una seqüència: primer es mira, després es tanca.

Convé dir-ho amb precisió: aquella directiva obliga les agències federals nord-americanes, no una empresa de Manresa ni de Barcelona. No la citem com a obligació, la citem com a procediment raonat per gent que respon a aquests incidents cada dia i que va haver d'escriure per què el pedaç va després. I si el pedaç entra sol, per un canal automàtic, sense tiquet i sense reinici, aquell ordre no es trenca per una mala decisió: es trenca perquè no hi va haver cap decisió.

El motor que inspecciona també és superfície d'atac

La primera condició de l'avís és incòmoda. L'aparell és explotable quan el servei de reputació de fitxers —la part que analitza els adjunts buscant programari maliciós— està activada i assignada a una política. Dit d'una altra manera: la peça per on entra l'atac és la peça que vas comprar perquè no entressin atacs.

Ho diem perquè ningú no ho llegeixi a l'inrevés: això no és un argument per apagar l'anàlisi d'adjunts. L'avís diu que no hi ha mitigacions, i nosaltres no vendrem com a arranjament apagar un control de seguretat; el dia que l'apagues passes a estar exposat a tota la resta, que és molt més freqüent que un zero-day al motor. El que sí que diu és una altra cosa: qualsevol motor que inspecciona és codi que obre contingut hostil amb privilegis alts. Antivirus, analitzador de contingut, sandbox, signatures d'IDS, l'agent de l'EDR. Tots. Quan dissenyes el camí del correu, aquell motor va a la columna de «controls» i també a la de «coses que poden ser atacades». D'aquí surt la conseqüència pràctica: que la passarel·la no sigui el teu únic punt de detecció, perquè el dia en què l'atacada és ella, la telemetria que et queda és la del lloc de treball.

El correu que enviem avui, i la foto que hi demanem

La majoria de pimes que tenen una d'aquestes passarel·les no l'administren: l'administra un tercer, o un company que va marxar, o el qui la va muntar fa sis anys. Així que l'entregable d'avui és un correu de tres preguntes, amb la resposta que esperes rebre escrita al costat perquè no et contestin «està tot correcte».

1. Què retorna avui contentscannerstatus? Resposta esperada: la sortida enganxada tal qual, amb la versió i la data de la columna «Last Updated». No val «sí, està actualitzat». Si la versió és anterior a 25.3.0.5525, som a la segona condició de l'avís.
2. En quines polítiques de correu està activat el servei de reputació de fitxers? Resposta esperada: la llista de polítiques d'entrada i de sortida en què està assignat. Si es donen les dues condicions, l'aparell és explotable mentre el motor continuï per sota de 25.3.0.5525; l'avís diu que d'aquella versió endavant està corregit.
3. Quan es va actualitzar el motor i qui ho comprova? Resposta esperada: una data i un nom. Si la resposta és «s'actualitza sol», la pregunta següent és des de quan i contra quin servidor, perquè un aparell sense sortida a Internet no s'actualitza sol: es queda quiet i no avisa.

I amb aquell correu hi va una petició més, la que gairebé mai no es fa: abans de tocar res, guardeu una còpia dels registres de correu de les últimes setmanes i anoteu la versió que corre ara mateix. No és paranoia ni és endarrerir l'arranjament —l'arranjament es posa avui—: és que així que el motor canviï de versió —ho faci sol o ho faci algú—, la resposta a «quina versió teníem el dia que això s'estava explotant?» deixa d'estar enlloc. Dos minuts. El que costa és recordar-se'n, i per això va escrit.

El que no estem dient

• No sabem quants aparells estan sense actualitzar, ni n'hem mesurat cap que no sigui dels nostres clients. El «Never updated» del principi és un exemple del manual de Cisco, no una estadística.
• No hem reproduït la vulnerabilitat ni tenim detalls de l'atac. Cisco no publica indicadors a l'avís i nosaltres no ens n'inventarem cap; si administres un d'aquests aparells, els registres que tinguis valen més que qualsevol regla que et puguem suggerir des de fora.
• I no diem que Cisco ho hagi fet malament distribuint-ho així. Un arranjament que entra sense reiniciar el correu d'una empresa és, tècnicament, el millor que et poden donar. El canal està bé. El que no hi és, és al teu procediment.

Fa una setmana escrivíem sobre una altra passarel·la de correu, un altre fabricant i el mateix descompàs a l'inrevés: el pedaç ha arribat i la teva mitigació continua posada, amb l'apany temporal allà plantat mesos després. I fa dues setmanes, que la teva política de pedaços no contempla que no hi hagi pedaç. Els tres casos diuen el mateix des d'angles diferents: el procediment només sap reconèixer una forma de pedaç —la que demana finestra— i tot el que no tingui aquella forma passa de llarg sense que ningú ho miri. Un motor que s'actualitza sol, una mitigació provisional que es queda, una vulnerabilitat sense pedaç. Tres forats de la mateixa mida.

Fonts (consultades el 15-10-2026): el CVE, la puntuació 9,8 amb el seu vector, la data i hora de publicació, les dues condicions, l'ordre contentscannerstatus, la ruta de la interfície, l'absència de mitigacions, les versions corregides i la frase sobre que actualitzar el motor no requereix actualització de programari ni reinici surten de l'avís cisco-sa-esa-afw-zqYJkjxp de Cisco. L'exemple de sortida amb la columna «Last Updated» és de la guia de referència de la CLI d'AsyncOS 16.0.1. Els hosts estàtics d'actualització i la frase sobre tallafocs i proxy, de la nota tècnica 117854 del mateix fabricant. L'entrada del catàleg —data d'alta 14-10-2026, termini 17-10-2026, CWE-23, marca de triatge forense i la descripció de l'escriptura arbitrària de fitxers— del catàleg KEV de CISA (versió 2026.10.14). Les dues frases sobre no remeiar abans de recollir evidències i sobre que pedaçar pot comprometre els artefactes, de la guia d'implantació de BOD 26-04. El detall de l'execució com a root i de l'adjunt manipulat, de la cobertura de BleepingComputer i The Hacker News. El que és nostre, i ho acotem: la lectura del canal de distribució de l'arranjament contra com està muntat un procés de pedaços normal, l'ordre «mirar abans de tancar» aplicat a un arranjament que entra sol, i les tres preguntes del correu.