El 4 d'agost CISA va incloure tres fallades al seu catàleg de vulnerabilitats explotades, amb termini de correcció per al dia 7. Una és un 9,8 a Langflow, una d'aquelles eines que algú munta en una tarda per «provar coses d'IA». La fallada no té res de subtil: hi ha un endpoint que reparteix tokens de superusuari a qualsevol que arribi al port i un altre que executa el codi que li enviïs. Encadenats, donen la màquina sencera. I feia sis setmanes que hi havia pedaç.
L'interessant no és la fallada. És que aquest mateix any s'han publicat avisos gairebé calcats en tres productes diferents de la mateixa família —els que munten la capa d'IA i d'automatització d'una empresa— i tots s'expliquen pel mateix malentès: aquest programari es va dissenyar per al teu portàtil i va acabar en un servidor amb les credencials de l'empresa a dins.
Què fa exactament la fallada de Langflow
CVE-2026-9198, publicat pel PSIRT d'IBM i catalogat per CISA com a «IBM Langflow». Afecta Langflow OSS de la 1.0.0 a la 1.10.0. La descripció del NVD és d'aquelles que es llegeixen dues vegades: un atacant sense autenticar encadena /api/v1/auto_login —que «emet tokens de SUPERUSUARI a qualsevol que truqui per xarxa»— amb /api/v1/validate/code —que executa codi d'usuari mitjançant exec()— i aconsegueix execució remota completa en un desplegament per defecte.
El nom del primer endpoint explica tota la història. Auto login és una comoditat: arrenques l'eina a la teva màquina i no has de teclejar usuari i contrasenya per fer proves. Com a comoditat local és raonable. El que no és raonable és que aquesta comoditat continuï viva quan el mateix contenidor s'aixeca en un servidor amb un port obert, que és exactament el que passa quan el «ho provo una estona» es queda. Aquesta lectura és nostra; la dada dura és la del NVD, i amb ella n'hi ha prou.
- →23 de juny de 2026: surt Langflow 1.10.1, la primera versió sense la fallada.
- →17 de juliol: el CVE entra al NVD amb un 9,8.
- →4 d'agost: CISA el fica al KEV —cosa que vol dir explotació confirmada, no teòrica— amb termini per a les agències federals el dia 7.
Sis setmanes entre el pedaç i l'entrada al KEV —i en el mateix registre del NVD, CISA ja marcava l'explotació com a activa des del 17 de juliol, divuit dies abans—. Aquest buit és el que importa: no el tanca el fabricant, el tanques tu. I el termini del dia 7 només obliga legalment les agències federals nord-americanes, però per a la resta serveix de termòmetre: quan una cosa entra al KEV, ja no parlem de risc, parlem de gent a dins.
El mateix supòsit, tres vegades
Si això fos un producte amb mala sort, seria una anècdota. Mira els altres dos:
- ✓Open WebUI, CVE-2026-45672 (8,8). Abans de la 0.8.12, l'endpoint
/api/v1/utils/code/executeexecutava codi Python arbitrari a través de Jupyter per a qualsevol usuari verificat encara que l'administrador hagués posatENABLE_CODE_EXECUTION=false. L'avís ho diu amb una frase que haurien d'emmarcar: la configuració diu «desactivat» i el codi s'executa igualment. - ✓n8n, CVE-2026-25049 (9,9 al NVD). Abans de la 1.123.17 i la 2.5.2, un usuari autenticat amb permís per crear o modificar fluxos podia fer servir expressions manipulades als paràmetres per provocar execució d'ordres a la màquina que executa n8n.
- ✓n8n, CVE-2026-21858 (10,0). De la 1.65.0 a la 1.120.x, certs fluxos amb formulari permetien a un atacant remot i sense autenticar llegir fitxers del servidor. Corregit a la 1.121.0. I per si faltava varietat, CVE-2026-59208: amb més d'un emissor de confiança configurat, n8n resolia la identitat fent servir només el
subdel token i ignorant l'iss, de manera que un token vàlid d'un emissor servia per entrar com l'usuari d'un altre.
Tres productes, cinc avisos, un sol patró: el model d'amenaça amb què es van dissenyar no és el del lloc on acaben. Es pensen per a una persona, en una màquina, en una xarxa de confiança, i acaben en un servidor multiusuari on arriba mitja empresa —i de vegades mitja internet— perquè així l'equip l'obre des de casa.
Regla u: un flag de configuració no és un control
El cas d'Open WebUI és el més net dels cinc i per això és el que fem servir per explicar-ho. L'interruptor existia. L'administrador el va posar a false. I l'endpoint no va preguntar. Si al costat d'aquella instal·lació hi havia un document de compliment dient «l'execució de codi està deshabilitada», aquell document era fals des del primer dia i ningú no ho podia saber mirant la interfície.
D'aquí la regla que apliquem: un control és una cosa que pots verificar des de fora de la cosa que estàs controlant. Si la teva única garantia que no s'executa codi és que l'aplicació promet no executar-lo, no tens un control: tens una preferència. Sota cada interruptor de l'aplicació n'hi ha d'haver un altre que no depengui de si l'aplicació es porta bé —una regla de xarxa, un proxy que autentica, una sortida a internet tancada, un usuari del sistema sense permisos—. Això, i no una diapositiva, és el que significa Zero Trust aplicat a alguna cosa concreta.
Regla dos: qui pot editar un flux és administrador
Una plataforma d'automatització guarda credencials de tot allò que connecta: és la seva funció. La clau de l'API del CRM, el token OAuth del correu, la contrasenya de la base de dades, la clau del proveïdor d'IA. Tot junt, a la mateixa màquina, perquè si no, no pot automatitzar res.
Ara ajunta-ho amb CVE-2026-25049: qui podia editar un flux podia executar ordres a l'amfitrió. A l'organigrama, «editor de fluxos» sona a un rol menor que es dona a la persona de màrqueting que munta l'enviament de newsletters. A la màquina, aquest rol i el d'administrador són el mateix. El permís d'editar automatitzacions cal tractar-lo com el d'administrar el servidor: les mateixes persones, el mateix segon factor, la mateixa revisió. I si hi ha departaments que no es refien entre si, no és un tema de rols, és un tema d'instàncies separades.
Sí, nosaltres també en tenim una
Escriure això sense dir-ho seria fer trampa: fem servir n8n per automatitzar tasques internes. Aquest mateix post arriba a LinkedIn a través d'un flux seu. Així que no et direm que no ho muntis, perquè ho tenim muntat, i perquè per a una empresa que no vol que les seves dades passin per un servei de tercers, autoallotjar continua sent la resposta correcta.
El que diem és una altra cosa: el dia que l'aixeques, deixa de ser un experiment. Entra a l'inventari amb nom i propietari, té finestra d'actualització com qualsevol altre servei, i no penja d'internet «mentrestant». La frontera entre un pilot i producció no la marca la mida: la marca si algú se n'assabenta quan es trenca. Un contenidor que fa vuit mesos que funciona sense que ningú sàpiga quina versió té ja és producció, es digui com es digui a la reunió.
Quan NO muntar-ho a casa
Tres situacions en què preferim el servei del fabricant encara que costi diners, i ho diem sabent que en totes tres hi perdem hores facturables:
- →Si no tindrà propietari. Un contenidor sense ningú al darrere és pitjor que una subscripció cara: la subscripció s'actualitza sola i el contenidor es queda a la versió del dia que es va muntar. Si ningú no es compromet a mirar-lo un cop al mes, no ho muntis.
- →Si el pla és publicar-lo a internet perquè l'equip hi entri des de casa. Aquesta frase és la que converteix una fallada «per a usuaris autenticats» en una fallada per a qualsevol. L'accés remot es resol amb VPN o amb un proxy que autentiqui al davant, no obrint el port.
- →Si el motiu era la privacitat però no hi haurà còpies ni registres. Vas autoallotjar perquè les teves dades no sortissin, i ara tens les claus del teu ERP en una màquina sense còpia i sense registres. Això no és privacitat; és el mateix problema amb menys gent mirant-lo.
El repàs d'aquesta setmana
El que estem fent aquests dies a les infraestructures que toquem, per si et serveix el guió:
- 1.Buscar-ho. Escaneig intern dels ports per defecte —7860 de Langflow, 5678 de n8n, 8080 d'Open WebUI, publicat sovint com a 3000— i la pregunta incòmoda a l'equip: hi ha cap VPS pagat amb una targeta personal? Gairebé sempre n'hi ha.
- 2.Versions mínimes. Langflow 1.10.1 o superior (la branca actual va per la 1.11.2, del 4 d'agost), Open WebUI 0.8.12 o superior, n8n 1.123.17 / 2.5.2 o superior i, si fas servir intercanvi de tokens amb diversos emissors, 2.27.4 / 2.28.1 o superior.
- 3.Treure'l d'internet. Si està publicat, darrere de VPN o d'un proxy amb identitat. I revisar què pot arribar cap enfora: una plataforma que executa codi i té sortida lliure a internet és una consola de comandament esperant que algú la trobi.
- 4.Credencials amb abast. Res de comptes de servei que ho poden tot «perquè no donin problemes». Permisos mínims per integració i, sobretot, que es puguin rotar sense refer els fluxos. Si rotar una clau implica tocar trenta automatitzacions, no la rotaràs.
- 5.Propietari i finestra. Un nom a l'inventari i una data al mes per actualitzar. És el més avorrit de la llista i l'única cosa que evita repetir aquesta conversa d'aquí a sis setmanes amb un altre CVE.
Res d'això no és exclusiu de la IA. És la mateixa feina que descrivíem ahir parlant de la consola des de la qual un proveïdor d'IT gestiona els teus equips —que, per cert, va tornar a aparèixer al mateix lot del KEV del 4 d'agost amb la seva fallada original—, i l'altra cara de l'inventari d'IA que demana l'AI Act: el reglament t'obliga a saber quina IA corre a la teva empresa per motius de transparència; el KEV t'obliga a saber-ho per motius bastant més urgents.
El que va dir CISA el dia 4
Convé llegir bé què significa una entrada al KEV, perquè se sol confondre. CISA no va dir «aquest programari és insegur». Va dir «algú l'està fent servir per entrar». Són dues frases molt diferents i només la segona té data. Langflow, n8n i Open WebUI són projectes seriosos que publiquen les seves fallades, les arreglen i documenten les versions corregides; els cinc avisos d'aquest post existeixen precisament perquè algú va fer bé la seva feina. El forat no és al programari: és a les setmanes que passen entre que surt el pedaç i algú l'aplica a la màquina que ningú no recorda haver muntat.
Si a la teva empresa hi ha una d'aquestes plataformes —i n'hi ha a moltes més de les que apareixen a l'inventari—, la comprovació d'avui no és un projecte: és obrir la interfície, mirar la versió i mirar si des de fora de l'oficina algú hi arriba. Deu minuts. És exactament per on comencem quan muntem automatització amb IA en un client: abans d'automatitzar res, saber què hi ha corrent i qui ho pot tocar. Si prefereixes que ho mirem nosaltres, escriu-nos: la primera conversa sol durar poc i acabar en una llista curta.
Fonts (verificades): CVE-2026-9198 (Langflow OSS 1.0.0–1.10.0, CVSS 9,8 assignat pel PSIRT d'IBM, publicat el 17-07-2026, cadena auto_login + validate/code) — NVD; inclusió al catàleg de vulnerabilitats explotades el 04-08-2026 amb termini el 07-08-2026, juntament amb CVE-2026-34486 (Apache Tomcat) i CVE-2026-18556 (N-able N-central) — CISA KEV; valoració SSVC de CISA Coordinator inclosa en el mateix registre del NVD, amb data 17-07-2026 i exploitation: active; data de publicació de Langflow 1.10.1 (23-06-2026) i de 1.11.2 (04-08-2026) — releases del projecte; CVE-2026-45672 (Open WebUI anterior a 0.8.12, CVSS 8,8 assignat pel CNA —GitHub—, l'endpoint executa codi encara que ENABLE_CODE_EXECUTION=false) — NVD; CVE-2026-25049 (n8n anterior a 1.123.17 i 2.5.2, CVSS 9,9 al NVD) — NVD; CVE-2026-21858 (n8n 1.65.0–1.120.x, CVSS 10,0 assignat pel CNA —GitHub—, corregit a 1.121.0) — NVD; CVE-2026-59208 (token exchange amb diversos emissors, corregit a 2.27.4 i 2.28.1) — NVD; ports per defecte — documentació de Langflow i documentació de n8n i Open WebUI. Les lectures i recomanacions operatives són nostres.
Saps quina versió té la teva plataforma d'automatització?
A everyWAN muntem automatització i IA com es munta producció: amb inventari, propietari, permisos que es poden auditar i una finestra d'actualització. Sense fum i sense ports oberts «mentrestant».
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN