FortiMail: el pedaç va sortir el 2, l'avís ho va dir el 7, i la mitigació continua posada

L'1 d'octubre Fortinet va publicar un avís dels que no admeten agenda: una fallada de 9,8 a FortiMail, explotable sense credencials, ja explotada i sense versió corregida disponible. L'única cosa que hi havia damunt la taula era apagar una funció. Les notes de la versió corregida de la branca 7.6 porten data del 2 d'octubre; l'avís no es va actualitzar per dir-ho fins al 7. Qui vigilava l'expedient, que és el que recomana tothom, va tenir el pedaç publicat cinc dies abans d'assabentar-se'n. I la segona meitat de la feina —tornar a engegar allò que es va apagar— no sol estar escrita enlloc.

Les dues dates del mateix avís

L'expedient és FG-IR-26-175, publicat l'1 d'octubre del 2026 i actualitzat el 7. La vulnerabilitat és CVE-2026-104286 i Fortinet la descriu així, literalment: «An Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') [CWE-22] and Improper Neutralization of NULL Byte or NULL Character [CWE-158] vulnerability may allow an unauthenticated attacker to write arbitrary files on the underlying system via crafted HTTP or HTTPS requests». En català pla: qualsevol que arribi al servei web de l'aparell pot escriure fitxers on no toca, sense iniciar sessió. Puntuació, 9,8 sobre 10.

Dos detalls que convé no saltar-se. El primer: la va trobar el mateix equip de seguretat de producte de Fortinet —el crèdit és per a Gwendal Guégniaud— i tot i així el fabricant reconeix que ja estava sent explotada. El segon: CISA la va posar al seu catàleg de vulnerabilitats explotades el mateix 1 d'octubre, amb data límit del 4 per a l'administració federal civil nord-americana. Tu no ets una agència federal civil nord-americana, però aquest catàleg és el millor termòmetre públic que hi ha de «això s'està fent servir ara mateix».

L'1 d'octubre aquells tres números —8.0.2, 7.6.7 i 7.4.9— ja estaven escrits a l'avís, amb l'advertiment que encara no s'havien publicat. Un expedient pot anomenar la versió que et salvarà abans que es pugui descarregar.

I també passa a l'inrevés, que és la dada que estructura aquest post. El registre de canvis de les notes de versió de FortiMail diu 2026-10-02 — Initial release of the FortiMail 7.6.7 Release Notes (compilació 858), i la 8.0.2 porta data del 3 d'octubre (compilació 263). L'avís no es va actualitzar per reconèixer-les fins al dia 7. Cinc dies i quatre dies de desfasament, respectivament, entre que el pedaç es pot descarregar i que l'expedient que vigiles ho diu. Si la teva condició per retirar una mitigació és «quan l'avís digui que hi ha pedaç», el teu rellotge va endarrerit respecte del de Fortinet.

La solució provisional apaga una funció de negoci

El que Fortinet va oferir mentre no hi havia pedaç és al mateix expedient: «Disable the IBE feature support via the GUI (Encryption -> IBE -> IBE Service 'off')», o per línia d'ordres config system encryption ibe → set status disable → end. Com a alternatives, treure l'accés des d'internet a la interfície de webmail —o limitar-lo només a la xarxa privada de confiança— o bloquejar en un WAF les peticions POST a /ibe que continguin ../.

IBE és el xifratge basat en identitat, i la documentació de FortiMail explica per a què serveix sense que calgui interpretar res. Quan un correu sortint encaixa amb una política de xifratge, l'aparell el xifra tot sol. Al destinatari li arriba un avís amb un adjunt HTML que conté instruccions i enllaços; si és el primer cop, es registra al FortiMail; si no, inicia sessió i el llegeix allà, i el missatge es desxifra en obrir-lo. No instal·la res ni genera claus. Dit en termes d'oficina: és la via per la qual una empresa envia documentació confidencial a algú que no és al seu domini. Una oferta, un informe, una nòmina, un contracte.

Hi ha dues coses que no afirmarem perquè la documentació pública no les resol i no ens inventarem la resposta. Una: què passa amb els avisos ja enviats el destinatari dels quals encara no havia entrat al portal. Dues: què fa l'aparell amb un correu que encaixa amb una política de xifratge mentre el servei IBE està apagat —si el deixa passar en clar, si el rebutja o si el reté—. Totes dues depenen de la teva versió i de la teva configuració, i totes dues són la primera comprovació que faríem al teu aparell. Si vas apagar IBE la setmana passada i no ho has mirat, mira-ho avui.

Les altres dues mitigacions tampoc no són de franc. Tallar l'accés des d'internet al webmail apaga, de passada, el webmail que potser fa servir algú. I una regla de WAF que bloqueja ../ dins d'un POST a /ibe és una conjectura raonable sobre la forma de l'atac que es coneix avui: aguanta un cap de setmana i poca cosa més.

Apagar ho decideix una persona; engegar, ningú

Apagar és una acció d'una sola persona, amb pressa i sense debat: un 9,8 explotat no es discuteix en comitè. Engegar exigeix quatre coses que, una setmana després, ja no són al cap de ningú: saber què es va apagar exactament, saber per què, comprovar que la condició que ho justificava ja no es compleix, i que algú verifiqui que allò que torna funciona de debò. Quatre requisits i cap responsable. Per això la mitigació es queda posada.

Fa una setmana vam escriure sobre el forat d'entrada: gairebé cap política de pedaços no té redactat el cas «no hi ha pedaç», i vam proposar una excepció per escrit que caduca tota sola al cap de set dies naturals perquè a ningú no se li quedi oberta. Aquella clàusula obliga a tornar-hi, però no diu què cal mirar el dia que toca. Aquest és el forat de sortida: arriba la data, el pedaç ja existeix, i ningú no ha deixat escrit què es va apagar ni com es comprova que ha tornat. El forat d'entrada es nota de seguida, perquè algú pregunta què fem. Aquest no es nota mai, perquè no fa mal: el sistema està segur, el tiquet està tancat i una funció apagada no genera alertes. Genera un correu que no arriba.

I no és un problema de gent descurada. En l'estudi de referència sobre grans serveis d'internet, l'error d'operador va ser la primera causa de caigudes en dos dels tres serveis analitzats, i els errors de configuració la categoria més gran dins d'aquell error (Oppenheimer, Ganapathi i Patterson, USENIX 2003). Una mitigació d'urgència és, per definició, un canvi de configuració fet a mà, amb pressa i fora de la finestra habitual: la categoria que més avaries provoca i la que menys rastre deixa.

La fitxa de mitigació temporal: sis línies

No proposem cap eina ni cap procés amb nom propi. Proposem sis línies que s'escriuen el mateix dia, al tiquet que ja tens obert, abans de tancar-lo. Van emplenades amb aquest cas perquè es vegi que no és un formulari buit.

• Què s'ha apagat, amb l'ordre exacta. «Servei IBE del FortiMail, config system encryption ibe → set status disable → end, l'1-10-2026 a les 18:40, per [nom].» L'ordre exacta importa perquè desfer-la no sempre és la mateixa ordre a l'inrevés.
• Què deixa de funcionar i qui ho nota. «El destinatari extern no pot llegir correu xifrat. Ho noten comercial i administració; no ho nota el servei de suport.» Si aquesta línia no es pot escriure és que ningú no sap per a què servia la funció, i això ja és una troballa.
• Per què, amb l'identificador. «FG-IR-26-175 / CVE-2026-104286, 9,8, explotat, sense versió corregida el dia del canvi.» Sense identificador, d'aquí a tres mesos això és una casella desactivada sense motiu aparent, i ningú no gosa tocar-la.
• La condició exacta que la retira. «Quan aquesta unitat corri la versió corregida de la seva branca o superior: 8.0.2, 7.6.7 o 7.4.9.» Una condició que es comprova mirant l'aparell. «Quan surti el pedaç» no serveix, i aquest cas ensenya per què: el pedaç va sortir cinc dies abans que l'avís ho digués.
• Qui la retira i qui verifica. Dos noms diferents. I verificar és enviar un correu que dispari la política de xifratge a una adreça externa de prova i llegir-lo des de fora, amb el mòbil si cal.
• Data de revisió, es compleixi o no la condició. La mateixa cadència que l'excepció de risc que vam proposar la setmana passada: set dies naturals. Si el pedaç encara no ha sortit, la fitxa es torna a mirar igualment, encara que només sigui per confirmar per escrit que l'apany continua sent el mal menor.

La fitxa ha de viure on algú mira: l'inventari, un tiquet que continua obert, una llista d'excepcions que es revisa cada mes. En un xat de grup no hi viu; s'enfonsa en dos dies i ningú no la torna a llegir.

Dues coses que el pedaç no tanca

La primera, si el teu FortiMail és a la branca 7.2: l'avís t'envia a una altra branca. «Upgrade to branch 7.4 or above», diu. Això és un canvi de versió major a l'aparell pel qual passa tot el teu correu, amb les proves que això exigeix. Mentrestant la mitigació és l'única cosa que tens, i la fitxa de dalt passa a ser l'única explicació escrita de per què el teu correu xifrat fa setmanes que està apagat.

La segona: si el teu aparell va ser accessible, el pedaç tanca la porta però no desfà allò que va entrar. Això és una vulnerabilitat d'escriptura de fitxers, i el que deixa al darrere és un fitxer, no pas una sessió que caduqui tota sola. Fortinet va publicar indicadors de compromís, i en va publicar força més del que se sol veure: dues adreces IP (79.141.169.187 i 45.129.0.192), entrades concretes del registre d'esdeveniments del sistema —una ordre de cron llançada com a root, tancaments de sessió d'administrador i l'alta d'un compte d'arxivament apuntant a aquella mateixa IP— i errors del registre de xifratge en desxifrar IBE. Convé saber quina d'aquestes coses dura. Les IP, poc: canviar d'IP li costa a un atacant molt menys que a tu revisar un sistema de fitxers. Les entrades de registre aguanten més, i són per on començaríem. Cap de les dues no és un certificat de netedat; d'això en vam escriure llarg al seu dia: pedaçar no és netejar.

Què faríem nosaltres, i què no

Què faríem aquesta setmana:

• Pujar a 8.0.2, 7.6.7 o 7.4.9 segons la branca, i comprovar la versió a l'aparell, no al tiquet.
• Retirar la mitigació amb la prova d'extrem a extrem descrita a dalt i deixar constància de qui la va fer i quan.
• Preguntar a comercial, a administració i a qui enviï documentació a tercers si han notat res estrany entre l'1 i avui. Aquesta conversa sol donar més que qualsevol registre.
• Si l'aparell va ser accessible des d'internet, revisar fitxers i tasques programades abans de donar-lo per net.
• Escriure la fitxa de les altres mitigacions que porteu posades. Sempre n'hi ha més d'una, i gairebé mai no són al mateix lloc.

Què no faríem:

• Deixar la regla de WAF com a solució definitiva. Era un apany amb data, i la data ja ha passat.
• Donar per retirada una mitigació perquè la casella estigui marcada. La prova és un correu que arriba i es llegeix.
• Tornar a apagar IBE sense avisar abans qui envia allò confidencial. Trenta segons d'avís estalvien tres dies de «no m'ha arribat».
• Fer servir aquest cas per carregar contra el fabricant. Va trobar la fallada a casa, va publicar la solució provisional el mateix dia i la correcció al cap de sis. Això és fer-ho raonablement bé; el forat del qual parla aquest post és nostre, no seu.

La fallada i l'avaria

En això fa anys que hi insistim i no canviarà: la fallada és inevitable, l'avaria és una decisió de disseny. La fallada, aquí, va ser el CVE, i no la vas decidir tu. L'avaria —una empresa que fa dies que no pot enviar documentació xifrada als seus clients i que no sap que no pot— sí que la decideixes tu, el dia que apagues alguna cosa sense escriure qui la torna a engegar. Mateixa vulnerabilitat, dos resultats oposats. El que els separa cap en sis línies d'un tiquet.

Fonts i mètode (verificat el 9 d'octubre del 2026): el text literal de la vulnerabilitat (CWE-22 i CWE-158, escriptura de fitxers sense autenticar via HTTP/HTTPS), la puntuació 9,8, les branques afectades (8.0.0-8.0.1, 7.6.0-7.6.6, 7.4.0-7.4.8 i 7.2.0-7.2.9), les versions corregides 8.0.2, 7.6.7 i 7.4.9, la indicació «Upgrade to branch 7.4 or above» per a la branca 7.2, el text de la solució provisional («Disable the IBE feature support via the GUI (Encryption -> IBE -> IBE Service 'off')» i les ordres de consola), les alternatives de treure accés al webmail i bloquejar POST a /ibe amb «../», els indicadors de compromís (les dues adreces IP, les entrades del registre d'esdeveniments del sistema i els errors del registre de xifratge) el crèdit de la troballa a Gwendal Guégniaud de l'equip de seguretat de producte de Fortinet (apartat «Acknowledgement»), i les dates de publicació (1-oct-2026) i actualització (7-oct-2026) provenen de l'avís FG-IR-26-175 del PSIRT de Fortinet. Que a la publicació inicial les versions corregides estaven anomenades però no disponibles, la fórmula «reported to be exploited in the wild» sense més detall i la inclusió al catàleg de vulnerabilitats explotades de CISA l'1 d'octubre amb data límit federal del 4 són a la cobertura de Help Net Security del 2-oct-2026. El funcionament de l'IBE —xifratge disparat per política, avís al destinatari amb adjunt HTML amb instruccions i enllaços, registre el primer cop, inici de sessió les següents, desxifrat en obrir i sense instal·lar programari ni generar claus— prové de la documentació d'administració de FortiMail. La dada sobre la causa principal de caigudes en grans serveis és d'Oppenheimer, Ganapathi i Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX 2003. El que no sabem: no hem pogut determinar, amb documentació pública, què passa amb els avisos IBE ja enviats el destinatari dels quals no ha entrat al portal, ni què fa l'aparell amb un missatge que encaixa amb una política de xifratge mentre l'IBE està apagat; el post ho declara com a pregunta oberta i no ho afirma en cap sentit. Tampoc no sabem quantes organitzacions van aplicar la solució provisional ni quantes ja l'han retirada: l'afirmació que «la mitigació continua posada» és la nostra lectura del patró, no una dada mesurada. No hem verificat de manera independent l'explotació activa: ens recolzem en el que declaren Fortinet i CISA. Les dates de les versions corregides (notes de versió de FortiMail 7.6.7 del 2 d'octubre del 2026, compilació 858, i 8.0.2 del 3 d'octubre, compilació 263) provenen del registre de canvis de la documentació de Fortinet; la data d'actualització de l'avís (7 d'octubre) prové del mateix FG-IR-26-175, i el desfasament entre totes dues coses és aritmètica nostra sobre aquestes dues fonts. De la 7.4.9 n'hem confirmat la compilació (630) però no la data de publicació, així que no la donem. Els cinc dies de la portada mesuren aquest desfasament documental i NO quant de temps va estar apagat cap sistema concret. Fotografia de portada: Process Water Building, TRA-605, detailed view of six valve handwheels in wall niche, Historic American Engineering Record (HAER ID-33-G-64), Library of Congress, domini públic, via Wikimedia Commons.