El 14 de juliol, SonicWall va tancar un parell de zero-days explotats als seus SMA 1000 amb la build 12.4.3-03453. L'1 de setembre va publicar un altre avís. Entre les versions afectades hi figura la 12.4.3-03453 i anteriors. La build que et deixava al dia al juliol és l'última build vulnerable al setembre, i entre una cosa i l'altra van passar 49 dies.
Dels de juliol ja en vam escriure: l'appliance VPN perimetral és l'objectiu perfecte. Tornar sobre la mateixa caixa set setmanes després no ens fa cap gràcia, i precisament per això aquest post no va de córrer més amb els pedaços. Va d'una cosa que només es veu quan poses els dos avisos l'un al costat de l'altre.
Els dos avisos, a la mateixa taula
Això surt de les fitxes del NVD i dels avisos del fabricant, no de titulars:
| Juliol (SNWLID-2026-0008) | Setembre (SNWLID-2026-0016) | |
|---|---|---|
| SSRF sense autenticar | CVE-2026-15409 — 10.0 | CVE-2026-83548 — 10.0 |
| El seu vector CVSS | AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H | AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H |
| Component | Work Place | Work Place |
| Execució d'ordres | CVE-2026-15410 — 7.2AV:N … PR:H | CVE-2026-83549 — 7.8AV:L … PR:L |
| On viu | AMC | AMC |
| Build corregida | 12.4.3-03453 / 12.5.0-02835 | 12.4.3-03526 / 12.5.0-02952 |
| Entrada al KEV | 14-jul → termini 17-jul | 2-sep → termini 5-sep |
La fila que importa és la sisena. 12.4.3-03453 és alhora la build que va arreglar el juliol i la build més nova que el setembre declara afectada. No és un matís de redacció: qui va complir el termini de tres dies del catàleg KEV al juliol —que era el correcte— va aterrar exactament a la versió que 49 dies després torna a aquest mateix catàleg.
I el vector CVSS dels dos SSRF és idèntic caràcter a caràcter. Mateixa nota, mateix vector, mateixa classe de fallada (CWE-918), mateix component. Dues vegades en set setmanes.
El «local» que no et protegeix
Aquí hi ha la part que es desprioritza sola. El CVE d'execució del juliol venia amb AV:N (xarxa) i PR:H (privilegis alts). El del setembre ve amb AV:L —vector d'atac local— i PR:L. Un responsable d'IT que obre la fitxa, llegeix «local» i té l'AMC restringit a la xarxa de gestió, tanca la pestanya tranquil. És la reacció lògica i és l'equivocada. I hi ha un detall que convé posar sobre la taula abans de continuar: la descripció que la mateixa SonicWall signa per a aquest CVE parla d'«un atacant remot autenticat com a administrador» —remot i admin— mentre que el vector diu AV:L i PR:L. El de juliol, descrit gairebé amb les mateixes paraules, es va puntuar AV:N i PR:H. El bitxo no va canviar tant entre juliol i setembre; el que va canviar és com es va puntuar. I això no et dóna cap sortida: o l'AV:L és literal i alguna cosa t'ha de donar aquest «local», o no ho és i llavors s'hi arriba per xarxa.
Perquè «local» és exactament el que l'altre CVE del parell regala. SonicWall descriu el 10.0 amb una expressió seva que convé llegir a poc a poc: «Pre-authentication SSRF via unintended forward-proxy». Un proxy de reenviament no intencionat. I la classificació d'aquesta fitxa no es va quedar en el CWE-918 de sempre: la mateixa SonicWall, com a CNA, li va assignar també el CWE-441 —i CISA ho replica a la seva entrada del KEV—, el nom oficial del qual a MITRE és «Unintended Proxy or Intermediary (Confused Deputy)» — el producte rep una petició i no preserva prou l'origen abans de reenviar-la fora de la seva esfera de control.
El nom d'aquest CWE és l'explicació de per què el «local» de l'altre CVE no et cobreix: la petició no neix a internet, neix dins del mateix aparell. L'aparell és aquest delegat confós. La teva regla d'«a l'AMC només s'hi arriba des de la xarxa de gestió» continua sent certa i continua sense servir, perquè qui truca ja és dins de la caixa.
Que això no és especulació nostra ho avala el juliol, que sí es va documentar pas a pas. Rapid7, que va descobrir aquell parell, va descriure que l'SSRF permetia «obrir un túnel basat en websocket cap a serveis que només escolten a localhost», arribar així al servei intern ctrl-service al port 8188, i des d'allà executar ordres com a root. El segon CVE de juliol el van anomenar, en les seves paraules, «a local privilege escalation». Al juliol el «local» ja era assolible; al setembre és el que diu la mateixa puntuació.
El que no afirmem
- ✗No sabem des de quan s'explota el parell de setembre. SonicWall confirma explotació activa, però no ha publicat data d'inici. Del de juliol sí que se'n va saber després: Volexity va situar-ne l'inici el 22 de juny, 22 dies abans del pedaç.
- ✗L'encadenament de setembre no està publicat pas a pas com el de juliol. Que tots dos s'encadenen fins a execució sense autenticar ho diuen els analistes; el com exacte, encara no. La nostra lectura de l'
AV:Les recolza en el CWE-441 i en el paral·lelisme amb el juliol, i la marquem com a lectura, no com a fet de l'avís. - ✗Que el KEV marqui el parell de juliol com a usat en campanyes de ransomware i el de setembre com a «desconegut» no és una nota de gravetat. És que encara no hi ha atribució. El de juliol també va començar sense atribució.
La pregunta canvia de lloc
Una fallada és una fallada. Dues vegades la mateixa forma de fallada en 49 dies —una porta sense autenticar que reenvia peticions, més una consola d'administració que executa— ja no és mala sort: és l'arquitectura de l'aparell dient-te alguna cosa. I a partir d'aquí, la pregunta útil deixa de ser «està pedaçat?» i passa a ser «fins on arriba aquesta caixa quan la controlen?».
La diferència pràctica entre les dues preguntes és que la primera la contesta el fabricant cada vegada que publica un avís, i la segona la vas contestar tu una vegada, fa anys, el dia que vas muntar el concentrador — i no l'has tornat a mirar.
A les pimes que ens arriben, aquest concentrador acostuma a fer dues feines que no són la mateixa. Primera: que la gent que teletreballa arribi a les aplicacions. Segona: que les delegacions i algun proveïdor arribin al datacenter. Es van ajuntar a la mateixa caixa perquè ningú no volia un segon aparell, i és una decisió que en el seu moment va ser raonable. El problema és que la segona feina no necessita un portal públic, i tanmateix hereta tota l'exposició de la primera.
Separar el transport entre seus de l'accés remot d'usuaris és la part d'això que sí que és de disseny i no de pedaçat. És el que fem quan muntem SD-WAN multiseu: la connectivitat entre delegacions va pel seu propi camí, amb política per seu, i no penja de si el portal de teletreball aguanta l'avís d'aquesta setmana. Qui compromet el portal deixa d'heretar automàticament les rutes a totes les seus.
I ara la part honesta, perquè si no això seria un fullet: l'SD-WAN no arregla el de SonicWall. No treu la necessitat d'un portal d'accés remot per a usuaris, i l'orquestrador d'un SD-WAN és un pla de gestió amb exactament la mateixa malaltia — nosaltres mateixos ho vam escriure al juliol sobre el CVE de l'orquestrador de VeloCloud. Canviar de caixa no cura res. L'única cosa que canvia és quantes coses diferents pengen d'una sola caixa exposada, que és una magnitud que sí que controles tu.
Si tens un SMA 1000, per aquest ordre
- 1Mira el número de build exacte, no la branca. Si hi posa
12.4.3-03453o12.5.0-02835, ets a la versió que el juliol va deixar «al dia» i el setembre declara afectada. Destí: 12.4.3-03526 o 12.5.0-02952. Models afectats: 6210, 7210 i 8200v. - 2Pedaçar tanca la porta; no et diu si va entrar algú. Són dues finestres diferents i totes dues s'han de mirar: la de juliol (des del 22 de juny) i la de setembre (data d'inici no publicada). El fabricant demana revisar indicadors de compromís amb el seu suport, no donar-ho per bo.
- 3Si hi va haver compromís, el fabricant no diu «neteja». Diu reinstal·lar la imatge del maquinari o tornar a desplegar el virtual, canviar totes les contrasenyes d'usuari i d'administrador i restablir els tokens TOTP. Aquest últim punt és el que més es salta la gent, i és el que decideix si l'atacant continua passant el teu MFA demà.
- 4Escriu la llista de tot el que aquest aparell pot arribar a tocar. En paper. Si un SSRF el converteix en proxy de reenviament, el dany màxim és aquesta llista. Gairebé ningú no la té escrita, i és l'única cosa que converteix un CVSS en una xifra teva.
- 5Separa qui necessita portal de qui necessita ruta. L'empleat que teletreballa necessita portal. La delegació i el proveïdor necessiten ruta amb política, i això no ha de passar per un web publicat a internet. És feina de treure confiança implícita, no de comprar una altra caixa.
Un apunt sobre el calendari, que és la part que ningú no explica: els dos avisos van entrar al KEV amb tres dies de termini. Tres dies per inventariar, coordinar una finestra, actualitzar un equip pel qual entra tot el teletreball i a més revisar indicadors. Dues vegades en set setmanes. Això no ho absorbeix una persona que a sobre té la seva feina; ho absorbeix una guàrdia amb procediment, que és exactament per al que existeix el suport 24×7. I avui, 7 de setembre, el termini del segon avís va vèncer fa dos dies.
En curt
No som resellers de SonicWall ni de ningú, i aquest post no va de fer-te canviar de marca: la caixa següent tindrà els seus propis avisos. El que diu és que un aparell que repeteix la mateixa forma de fallada en 49 dies t'està donant una dada de disseny, no una tasca de manteniment. El pedaç el posa el fabricant quan pot. L'abast —què arriba a tocar aquest equip el dia que no és teu— el poses tu, i és l'única cosa de tot això que no depèn de la propera build.
Fonts (verificades el 7-set-2026): avís SNWLID-2026-0016 de SonicWall (1-set-2026), versions afectades i corregides, «Pre-authentication SSRF via unintended forward-proxy» i passos de remediació — sonicwall.com; vectors CVSS i CWE de CVE-2026-83548, CVE-2026-83549, CVE-2026-15409 i CVE-2026-15410 — NVD (fitxes en estat Analyzed); dates d'alta i terminis del catàleg KEV de CISA (versió 2026.09.04); builds corregides del juliol i mecànica del túnel websocket, ctrl-service i port 8188 — Rapid7; data d'inici d'explotació del parell de juliol (22-juny-2026, actor UTA0533) — Volexity, via Cybersecurity Dive; definició de CWE-441 — MITRE.
Saps fins on arriba el teu concentrador d'accés remot?
A everyWAN dissenyem i operem la connectivitat entre seus i l'accés remot com dues coses diferents, amb política per seu i sense que tot pengi d'un portal publicat. Si tens les dues coses a la mateixa caixa, t'ajudem a separar-les.
Parlar amb everyWAN