# everyWAN — Soluciones IT para empresas / Enterprise IT solutions

> everyWAN (MINORISA DE SISTEMAS INFORMÁTICOS Y DE GESTIÓN, S.L.) es un proveedor español de
> servicios IT gestionados para empresas: ciberseguridad, infraestructura y cloud, copias de
> seguridad y recuperación ante desastres, Microsoft 365, redes/SD-WAN, soporte 24/7, colocation
> y migraciones (VMware→Proxmox, Ceph). Sede en Sant Fruitós de Bages (Barcelona), España.
> Web trilingüe: español (/es), català (/ca), english (/en).
>
> everyWAN (MINORISA DE SISTEMAS INFORMÁTICOS Y DE GESTIÓN, S.L.) is a Spanish managed IT services
> provider for businesses: cybersecurity, cloud & infrastructure, backup & disaster recovery,
> Microsoft 365, networking/SD-WAN, 24/7 support, colocation and migrations (VMware→Proxmox, Ceph).
> Based in Sant Fruitós de Bages (Barcelona), Spain. Trilingual site: /es, /ca, /en.

## Servicios / Services
- [Ciberseguridad / Cybersecurity](https://everywan.com/es/seguridad/ciberseguridad)
- [Zero Trust](https://everywan.com/es/seguridad/zero-trust)
- [Backup 365](https://everywan.com/es/seguridad/backup-365)
- [EDR/MDR](https://everywan.com/es/seguridad/edr-mdr)
- [Infraestructura y Cloud / Cloud & Infrastructure](https://everywan.com/es/soluciones/infraestructura-y-cloud)
- [Colocation](https://everywan.com/es/soluciones/colocation)
- [Disaster Recovery](https://everywan.com/es/soluciones/disaster-recovery)
- [Microsoft 365](https://everywan.com/es/eficiencia/microsoft-365)
- [SD-WAN](https://everywan.com/es/eficiencia/sd-wan)
- [Soporte IT 24/7 / 24-7 IT Support](https://everywan.com/es/servicios/soporte-it-24x7)
- [Mantenimiento informático / IT Maintenance](https://everywan.com/es/servicios/mantenimiento-informatico)
- [Consultoría / Consulting](https://everywan.com/es/servicios/consultoria)

## Blog (contenido tecnico / technical content)
- [Migrar de VMware a Proxmox: el disco llega entero, Windows no arranca, y el fallo es de dos semanas antes. TESIS PROPIA SOBRE POR QUE FALLAN LAS MIGRACIONES DE VMWARE A PROXMOX: NO FALLAN EN EL TRANSPORTE DEL DISCO, FALLAN EN EL ORDEN DEL CALENDARIO. HECHOS DE PARTIDA VERIFICADOS EN FUENTE PRIMARIA: Proxmox VE 8.2, publicada el 24 de abril de 2024, incorporo el importador de ESXi como PLUGIN DE ALMACENAMIENTO integrado en la API y la interfaz web. Sus limitaciones documentadas en el wiki oficial Migrate to Proxmox VE hablan TODAS del transporte y NINGUNA del sistema invitado: la importacion "can be significantly slower if the VM has snapshots", "importing a VM with disks backed by a VMware vSAN storage does not work", "encrypted VM disks, for example via a Storage Policy, cannot be imported", un datastore con caracteres especiales como el "+" "might not work", e importar via vCenter "will dramatically reduce performance"; se recomienda apagar la VM en origen para un estado consistente y la importacion se ha probado de ESXi 6.5 a 8.0. LA FRASE QUE EXPLICA EL BUCLE, literal del wiki oficial Paravirtualized Block Drivers for Windows: "To switch an existing Windows installation to use the VirtIO-SCSI drivers and boot from them, it needs to see a disk requiring the driver before". Eso es una DEPENDENCIA CIRCULAR PERFECTA: ese disco no existe mientras la VM vive en ESXi (donde la controladora es LSI Logic SAS o VMware Paravirtual) y en Proxmox ya no arranca para verlo; el "antes" cae en el hipervisor que estas abandonando. SALIDA DOCUMENTADA: cuando el invitado es Windows "the disk bus type needs to be switched from the default SCSI to IDE or SATA" para poder arrancar, y despues el procedimiento del DISCO SENUELO de 1 GB en VirtIO SCSI conectado en caliente, instalar el driver desde la carpeta vioscsi de la ISO, apagar, soltar los discos y reengancharlos como VirtIO SCSI, con el aviso final "Adapt the Boot Order under the VM's Option tab. Make sure that the primary boot device is still the old boot disk". LA APORTACION ORIGINAL DEL POST, declarada como lectura propia y no de las fuentes: ese procedimiento oficial RESUELVE UNA MAQUINA, NO UNA MIGRACION, porque su coste es POR MAQUINA, SECUENCIAL y DENTRO DE LA VENTANA (dos apagados y arranques limpios extra de un Windows Server, un paso manual con raton dentro del invitado que no se puede lanzar desde la API de Proxmox, y un cambio de orden de arranque), y es la unica parte del trabajo que NO escala con mas ancho de banda. Con tres VM de Windows cabe; con cuarenta no, y no revienta a la mitad: alguien deja las ultimas arrancando por SATA "de momento" y eso reaparece meses despues como un ticket de rendimiento que nadie relaciona con la migracion. TESIS CENTRAL: la unica tarea con RESTRICCION DE ORDEN DURA -tiene que pasar antes, no puede pasar despues- es justo la que el plan estandar coloca al final, porque los planes se escriben desde el evento hacia atras y lo que hay que hacer el martes anterior no tiene casilla. LA SOLUCION NO ES CORRER MAS, ES MOVER EL TRABAJO DE FECHA: el driver VirtIO se mete en el Windows Driver Store con la VM VIVA en ESXi y se marca para cargar en el arranque, con lo que el bucle se deshace por el pasado (guia publica de croit: "By injecting the driver into the Windows Driver Store and flagging it to load during initialization, you eliminate the hardware-toggling loop entirely"; el post advierte de que NO ha auditado ese script). OTRA TAREA CON LA MISMA FORMA, tambien del wiki: "On Windows, consider removing the static network configuration, if there is any. After the migration, the network adapter will change and Windows will show a warning if you configure the same IP address on another network adapter, even if the previous one is not present anymore". PLAN EN TRES FECHAS en vez de una noche: D-14 preparacion del invitado en ESXi en horario de oficina con las VM encendidas (driver dentro y marcado, red estatica anotada y retirada, VMware Tools fuera, e inventario de que Windows y que controladora hay); D-7 una VM real migrada de verdad y dejada corriendo una semana, no para ver si el asistente funciona sino para descubrir que pasos hacen falta en TUS maquinas; D-0 copiar y nada mas. AVISO DE NO CONFUNDIR CONTROLES: preparar el invitado reduce la PROBABILIDAD de usar el plan de vuelta atras, no la NECESIDAD de tenerlo escrito. CUANDO NO VA CONTIGO: si todas tus maquinas son Linux moderno los modulos virtio suelen ir en el initramfs y arranca solo (con la excepcion real del initramfs recortado al hardware del anfitrion, cuyo sintoma es un kernel panic en vez de pantalla azul); y con tres VM de Windows y una tarde, la via oficial del wiki basta. El post NO da cifras de minutos por maquina y lo dice explicitamente porque no las tiene medidas de forma defendible. Servicio que posiciona: migracion-vmware-proxmox, con infraestructura-y-cloud y consultoria](https://everywan.com/es/blog/migrar-vmware-proxmox-el-disco-llega-entero-windows-no-arranca) — 2026-09-09
- [Windows DNS, un 9,8 sin autenticar: lo que convierte un fallo en gusano no es el fallo, es tu red. TESIS PROPIA SOBRE POR QUE UN FALLO SE PROPAGA COMO GUSANO: NO ES UNA PROPIEDAD DEL CVE, ES UNA PROPIEDAD DE LA TOPOLOGIA Y DEL INVENTARIO DE ROLES. HECHO DE PARTIDA: el martes de parches del 8-sep-2026 fue el mayor de la historia de Microsoft y las cifras no coinciden entre fuentes (Zero Day Initiative 972 CVE de Microsoft y 114 criticos; CrowdStrike 972 y 113; Tenable 964; prensa 973-974), porque, segun Security Affairs, "depending on how researchers count external and Chromium bugs, Microsoft fixed between 966 and 997 CVEs in this update". EL FALLO PROTAGONISTA: CVE-2026-69730, ejecucion remota de codigo en el ROL DE SERVIDOR DNS de Windows (no el cliente DNS), critica, CVSS 9,8, uso despues de liberar segun Cisco Talos, sin autenticar y sin interaccion del usuario; Dustin Childs (ZDI) lo llama "SigRed's spiritual successor" y dice "We haven't seen a global worm in years, but with a DNS flaw acting as the spiritual successor to SigRed, that reality could change fast". Microsoft lo clasifica como "Exploitation More Likely". NO ES UN SOLO FALLO DE DNS: tres de los veinte gusanables son del servidor DNS (69730, 69858, 72987) y Talos lista ademas 69813, 69827 y 77505, todos RCE con CVSS 8,1. POR QUE IMPORTA A UNA PYME: segun CrowdStrike, "in most Active Directory (AD) environments, DNS runs on domain controllers themselves rather than on dedicated infrastructure", de modo que "a successful exploit against an AD-integrated DNS server can deliver code execution on a domain controller"; la maquina vulnerable es la que guarda las contrasenas de todos y la que nadie quiere reiniciar. LA APORTACION ORIGINAL DEL POST (declarada como lectura propia, no de las fuentes): los veinte CVE gusanables -recuento PERSONAL de Childs, "wormable" NO es etiqueta de Microsoft- se reparten en TRECE componentes (DHCP 69510 y 72979; Active Directory DS 69524; RMCAST 69530, 78449 y 78450; Message Queuing 69579 y 83997; RRAS 69590; NFS ONCRPC XDR 69595; servidor DNS 69730, 69858 y 72987; cliente SMB 72936; IP Helper 72981; Netlogon 72982; ICS 72983; SSTP 73009; Failover Cluster 73010 y 78444), y esos trece NO son una lista sino DOS. GRUPO UNO, SUPERFICIE IRREDUCIBLE (7 CVE): servidor DNS, servidor DHCP, Netlogon y Active Directory DS son los servicios que un puesto unido al dominio TIENE que poder alcanzar para funcionar -sin DNS no resuelve, sin Netlogon no inicia sesion, sin DHCP no tiene direccion-, asi que la segmentacion no te salva del puesto de trabajo y solo queda parchear rapido y controlar que OTROS segmentos llegan. GRUPO DOS, ROLES QUE ALGUIEN INSTALO (11 CVE, mas de la mitad): RMCAST, Message Queuing, Failover Cluster, RRAS, NFS, ICS y SSTP no vienen activos de fabrica; solo son gusanables donde alguien encendio el rol y se le olvido, y se gestionan DESINSTALANDO, que es gratis y permanente. DOS EXCEPCIONES DECLARADAS QUE NO ENCAJAN EN NINGUN GRUPO: el cliente SMB se explota al reves (es codigo en el portatil y ataca el servidor malicioso que responde) e IP Helper (iphlpsvc) corre por defecto en todos los Windows gestionando tuneles IPv6. COROLARIO: "no tenemos el DNS publicado en internet" no salva, porque un gusano interno entra por el portatil de alguien y ese portatil tiene permiso POR DISENO para hablar con el puerto 53 del controlador. CHECKLIST ACCIONABLE: (1) comprobar quien llega al 53 desde wifi de invitados, rango VPN y VLAN de impresoras/camaras, probando LOS DOS TRANSPORTES porque no son intercambiables -Test-NetConnection <IP-DC> -Port 53 solo prueba TCP, y las consultas normales van por UDP, que se prueba con Resolve-DnsName -Server <IP-DC> o nslookup-; (2) inventariar el rol con Get-WindowsFeature DNS o Invoke-Command sobre Get-ADComputer -Filter {OperatingSystem -like "*Server*"}, sacando en la misma vuelta los siete roles opcionales del grupo dos; (3) segmentar lo segmentable (invitados, impresoras, camaras, domotica, VPN de proveedores no necesitan hablar con el controlador) sin fingir que se puede cortar el 53 a los puestos; (4) parchear los controladores PRIMERO, sin "secundario" porque en AD todos son iguales desde Windows 2000 y lo que hay son roles FSMO: localizarlos con netdom query fsmo, empezar por un DC sin ninguno, verificar con repadmin /replsummary y dejar el emulador de PDC para el final; (5) mirar que mas carga esa maquina (DNS y DHCP juntos, o "dos controladores" que son dos VM en el mismo anfitrion). AVISO CRITICO DE ROLLBACK: en un controlador de dominio restaurar la instantanea de la VM NO es un plan de vuelta atras, porque provoca un USN rollback que rompe la replicacion de forma silenciosa salvo que el hipervisor soporte VM-GenerationID; el rollback real es desinstalar la actualizacion o promocionar otro DC y degradar el afectado. HONESTIDAD: SigRed (CVE-2020-1350, CVSS 10,0, julio 2020, 17 anos latente, mitigacion TcpReceivePacketSize a 0xFF00 en KB4569509) genero el mismo discurso y el gusano global NUNCA llego; a 9-sep-2026 CVE-2026-69730 no esta en el catalogo KEV de CISA y no hay prueba de concepto publica conocida; los dos fallos que SI se estan explotando este mes no son el 9,8 sino dos elevaciones de privilegios locales con CVSS 7,8 (CVE-2026-81963 en la pila de Windows Update, primero de siete desde 2022 explotado como dia cero segun Satnam Narang de Tenable, y CVE-2026-85880 en ALPC). La razon para mover ficha no es el gusano, es la frase corta: ejecucion de codigo sin autenticar en un controlador de dominio. Seccion "cuando esto no va contigo" que descarta el tema para quien tenga quince portatiles, ninguna maquina Windows servidor y el DNS del router del operador. Servicio que posiciona: redes-y-comunicaciones, con mantenimiento-informatico](https://everywan.com/es/blog/windows-dns-lo-que-convierte-un-fallo-en-gusano-es-tu-red) — 2026-09-09
- [Una casilla protegera una carga de trabajo entera en Microsoft 365 Backup: lo que factura no es lo que ves en el informe de uso. TESIS DE COSTE OCULTO Y ALCANCE POR DEFECTO SOBRE EL BACKUP NATIVO DE MICROSOFT 365. HECHO DE PARTIDA: el aviso MC1387526 del centro de mensajes (publicado en junio de 2026, vista previa publica en julio) introduce Full Workload Backup, UNA politica POR CARGA DE TRABAJO -son tres casillas distintas, SharePoint, OneDrive y Exchange Online, no una por tenant- que protege automaticamente todos los objetos elegibles no cubiertos por otra politica, INCLUIDOS LOS QUE SE CREEN DESPUES; las politicas personalizadas tienen precedencia; VIENE DISPONIBLE PERO DESACTIVADO y lo activa un administrador a mano, de modo que NADA SE ENCIENDE SOLO; disponibilidad general a partir de mediados de septiembre de 2026 con prevision de completarse a mediados de octubre. ARITMETICA DE LA FACTURA (pagina oficial Pricing model for Microsoft 365 Backup, Microsoft Learn, actualizada el 18-ago-2026): precio de lista 0,15 $ por GB y mes de contenido protegido; la base facturable es la suma de DOS BLOQUES, el tamano visible (sitios de SharePoint y cuentas de OneDrive con papelera de PRIMERA fase, buzon vivo y archivo en linea) y lo retenido para recuperar (papelera de SEGUNDA fase o de coleccion de sitios y elementos borrados y versionados); ejemplo literal de Microsoft: un sitio de 1 GB con 0,5 GB en su papelera de segunda fase y un buzon de 1 GB con archivo en linea de 1 GB se facturan como 3,5 GB. EL HALLAZGO QUE VERTEBRA EL POST, dado SIN recorte: la frase completa de la documentacion es "The admin center provides better growth visualization, but doesn't include the second-stage recycle bin or online archive sizes, and is thus incomplete", y Microsoft ADEMAS publica una calculadora oficial (aka.ms/M365BackupCalculator) cuyo campo de almacenamiento total pide explicitamente sumar datos vivos + papeleras + archivos en linea; o sea que la informacion, la herramienta y el aviso estan publicados, y el problema es que el informe de uso se abre en dos clics y la calculadora hay que descargarla. El desfase en el ejemplo oficial es de 2 GB mostrados frente a 3,5 GB facturados, un 75% mas DE LO QUE MUESTRA EL INFORME (no de lo que el usuario tiene: el archivo en linea es correo real que se ve en Outlook). Ruta correcta en PowerShell: Get-SPOSite, Get-PnPRecycleBinItem -SecondStage y Get-MailboxStatistics -Archive; con miles de sitios el segundo enumera elemento a elemento y exige conectarse a cada sitio. CONTRAINTUITIVO: limpiar NO baja la factura hasta que expira la ventana de recuperacion (ejemplo literal: un sitio protegido de 1 GB que baja a 0,5 GB sigue facturando 1 GB durante un ano), y sacar un sitio o buzon de la politica tampoco, porque se sigue usando como aproximacion el tamano que tenia al retirarlo hasta que expiran los puntos de restauracion. CORRECCION IMPORTANTE QUE EL POST HACE EXPLICITA: la ventana de recuperacion NO multiplica la factura, solo actua sobre el SEGUNDO bloque; en el ejemplo oficial 3 de los 3,5 GB son tamano vivo y solo 0,5 dependen de la ventana, asi que pasar de 2 anos a 3 meses no divide el recibo por ocho. La frecuencia de puntos de restauracion no impacta materialmente el coste. Quedan una palanca grande (que proteges) y una menor (durante cuanto: 3, 6, 12 o 24 meses por politica, con las existentes en 12 por defecto). GOBERNANZA: las politicas de retencion y eliminacion de Purview NO afectan a la ventana de recuperacion del backup, que permanece completamente aislada; es la defensa correcta ante un borrado malicioso y a la vez un problema si alguien ejerce el derecho de supresion, porque la unica salida documentada es dar de baja el producto entero -no un borrado quirurgico- y ademas arrastra 90 dias de gracia durante los cuales las copias siguen siendo recuperables (el post marca esto como LECTURA PROPIA, no interpretacion juridica). QUE SIGNIFICA "INMUTABLE" AQUI, CON LAS DOS FRASES CONTRADICTORIAS DE LA MISMA PAGINA CITADAS: "follows that definition except for disallowing deletion" y "The backups are immutable unless expressly deleted by the Backup tool admin via product offboarding". Los tres controles reales frente a un administrador comprometido son los 90 dias de gracia, el aislamiento respecto de Purview y la notificacion multiadministrador, que LLEGA COMO RESUMEN DIARIO (no en tiempo real) y admite hasta veinte destinatarios individuales ademas de listas y grupos. LO QUE HACE BIEN, con las cifras DADAS TAL COMO ESTAN PUBLICADAS Y SENALANDO QUE NO CUADRAN ENTRE SI: para un solo sitio, menos de 20 minutos para menos de 1 TB con punto expres, 30 minutos por unidad de proteccion en la tabla de rendimiento y de 10 a 120 minutos en la nota al pie; para restauraciones masivas, de 1 a 3 TB por hora en la tabla de caracteristicas y hasta 250 unidades y 2 TB por hora en la de rendimiento; 100-500 elementos por buzon y minuto en Exchange; con la advertencia de que las cifras de mas de 1.000 unidades salen de pruebas internas con sitios de 12 GB de media y buzones de unos 26.000 elementos. OTRA CONTRADICCION DECLARADA: la tabla marca la restauracion de ficheros por versiones como "coming soon" mientras el apartado de rendimiento describe la restauracion granular de carpeta y fichero como si existiera. En Exchange la restauracion devuelve elementos a la misma carpeta o a otra DENTRO del buzon del usuario. HONESTIDAD: seccion que recomienda a una empresa de veinte personas con pocos cientos de gigas marcar la casilla y dejar de leer, y declaracion de que everyWAN no vende licencias de Microsoft ni de nadie. Servicio que posiciona: backup-365, con cumplimiento-y-continuidad y consultoria](https://everywan.com/es/blog/microsoft-365-backup-una-casilla-por-carga-de-trabajo) — 2026-09-09
- [La IA ya encuentra fallos de dia cero sola: tu problema son los 43 dias de despues. TESIS CONTRARIAN SOBRE DONDE ESTA EL CUELLO DE BOTELLA REAL DEL PARCHEO. HECHO DE PARTIDA: el 4-sep-2026 OpenAI presento GPT-6 Astra y declaro que es el primer modelo que despliega alcanzando el nivel "Critico" de capacidad en ciberseguridad de su Preparedness Framework, umbral que su propio marco define por dos vias, la primera "identify and develop functional zero-day exploits of all severity levels in many hardened real-world critical systems without human intervention"; cifras publicadas: ExploitBench 100% frente al 78,5% de GPT-5.6 Sol, ExploitGym 42,4% frente a 30,3% y con menos tokens de salida; probado contra fallos divulgados en los tres meses previos al lanzamiento (posteriores a su corte de entrenamiento) para descartar memorizacion, y por el camino encontro DOS vulnerabilidades desconocidas cuyos fabricantes estan siendo avisados. LETRA PEQUENA QUE CASI NADIE CONTO (lectura declarada como nuestra): ese 100% se midio SIN las salvaguardas de produccion, mientras que la version que una empresa puede activar esta restringida a revision y correccion segura de codigo y se niega a generar pruebas de concepto, o sea que el numero del titular describe una configuracion distinta de la del producto; ademas el acceso viene desactivado por defecto. SEGUNDO DETALLE: la relajacion de esas restricciones esta prevista para defensores verificados via el programa Daybreak, de modo que la mitad ofensiva llega primero como capacidad demostrada y la defensiva llega despues y con lista de invitados. Cita de Sanchit Vir Gogia: "Astra behaves better and watches worse" (menor monitorabilidad de la cadena de razonamiento que en Sol). LOS DOS NUMEROS QUE YA DECIDIAN EL RIESGO, ANTERIORES A ASTRA: M-Trends 2026 de Mandiant situa el tiempo MEDIO hasta la explotacion en aproximadamente MENOS SIETE DIAS (63 dias en 2018; cruzo el cero en 2024), o sea que de media el fallo se explota una semana antes de que exista el parche; y el DBIR 2026 de Verizon situa la MEDIANA para remediar del todo una vulnerabilidad del catalogo KEV en 43 DIAS, frente a 32 el ano anterior. El post declara explicitamente que sumarlos para dar "cincuenta dias" es una ilustracion y no una estadistica (media y mediana, informes y poblaciones distintos). EL NUMERO QUE MAS DUELE: de las vulnerabilidades del KEV que las organizaciones tienen en sus sistemas solo se remedia por completo el 26%, frente al 38% del ano anterior; el contrapeso honesto, del mismo informe, es que la mediana de vulnerabilidades del KEV por organizacion subio de 11 a 16 (casi un 50% mas), pero eso refuerza la tesis: la empresa mediana tenia DIECISEIS en todo el ano y cerro CUATRO. El KEV no es volumen: es una lista corta, gratuita y ya priorizada (tandas comprobadas de 3 el 11-ago, 4 el 18-ago, 6 el 26-ago, 2 el 31-ago y 7 el 2-sep). CONCLUSION: si no puedes con la lista corta que otro te ha filtrado, "hay demasiados CVE" nunca fue el motivo, y un motor que encuentre fallos mas deprisa no cambia tu riesgo, cambia tu calendario. POR QUE 43 DIAS NO ES PEREZA (observacion propia de operar infraestructura de clientes desde 2015, no un estudio): no sabes donde corre (falta inventario), no tienes donde probarlo (falta staging), no puedes deshacerlo (falta rollback), no puedes parar (falta ventana) y no hay nadie despierto (falta turno); mas una sexta razon, que el miedo es racional porque los parches rompen cosas. LO QUE SI MUEVE EL NUMERO: inventario que se alimenta solo, entorno de pruebas parecido a produccion, despliegue por partes con vuelta atras en un clic, telemetria por sintomas y alguien que pueda ejecutarlo fuera del horario de oficina; el post declara que everyWAN vende guardia 24x7 y que la guardia SOLA no baja la mediana. HONESTIDAD: seccion "cuando esto no va contigo" que desaconseja montar un programa de parcheo a quien tiene quince portatiles y nada publicado, y seccion "antes de que nos cites" con las reservas (no hemos usado Astra, no afirmamos que haya atacantes usandolo, no sabemos si la capacidad se traducira en mas explotacion real, y discrepancia de fuentes sobre la fecha 3 vs 4 de septiembre). Servicio que posiciona: soporte-it-24x7, con mantenimiento-informatico y ciberseguridad](https://everywan.com/es/blog/la-ia-encuentra-el-zero-day-tu-tardas-43-dias) — 2026-09-08
- [REPLICATION nunca fue un permiso de solo lectura: PostgreSQL cerro un dlopen() de doce anos. TESIS DE GOBIERNO DE PRIVILEGIOS + CAMBIO DE COMPORTAMIENTO ESCONDIDO EN UN PARCHE DE SEGURIDAD. HECHOS VERIFICADOS EN FUENTE PRIMARIA: CVE-2026-6471, puntuacion 7,2 con vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H, descripcion oficial de postgresql.org "Missing authorization in PostgreSQL logical decoding allows a non-superuser holding REPLICATION privilege to dlopen any file visible to the operating system account running the server, via the choice of logical decoding plugin. This in turn runs arbitrary code as that account"; afecta a las versiones anteriores a 18.6, 17.11, 16.15, 15.19 y 14.24, publicadas el 13-ago-2026; el fallo existe desde la introduccion de la decodificacion logica en PostgreSQL 9.4 (2014), doce anos. REQUISITOS DE EXPLOTACION: wal_level = logical y el atributo REPLICATION en el rol; la replicacion fisica no carga plugins. EL MITO QUE DESMONTA: la documentacion de CREATE ROLE ya dice "A role having the REPLICATION attribute is a very highly privileged role, and should only be used on roles actually used for replication", pero el permiso se pide por lo que hace ("el CDC necesita leer el WAL") y se concede por como se llama. EL PARCHE MUEVE LA FRONTERA DE AUTORIZACION: introduce el parametro output_plugin_libraries, lista blanca de librerias "that are also trusted for use as logical output plugins by replication clients", con la advertencia "All users are subject to this restriction" (tambien superusuarios); en el codigo fuente (src/backend/utils/misc/guc_tables.c, rama 18) el parametro es PGC_SUSET con la marca GUC_SUPERUSER_ONLY, o sea que solo un superusuario puede leerlo o cambiarlo (incluido ALTER SYSTEM SET desde SQL): quien decide que codigo se carga deja de ser el atributo del rol y pasa a ser el pequeno grupo que toca la configuracion del servidor. CAMBIO DE COMPORTAMIENTO QUE ROMPE PRODUCCION: el valor por defecto es solo pgoutput y test_decoding, y las notas de 18.6 avisan "Installations that rely on other output plugins must add them after updating the server"; wal2json documenta en su README la linea output_plugin_libraries = 'pgoutput, test_decoding, wal2json' y el error library "wal2json" may not be used as an output plugin; la documentacion de Debezium da decoderbufs como valor por defecto de plugin.name; ademas pg_upgrade --check falla si el cluster nuevo no permite los plugins de los slots del viejo. HONESTIDAD DE FUENTES: a 4-sep-2026 The Hacker News comprobo que el CVE no estaba en el catalogo KEV de CISA ni habia PoC publico; Cyera (investigacion PostGREShell, rutas UNC en Windows y automontaje NFS en Linux) dice haber hallado 114 plugins maliciosos de PostgreSQL en VirusTotal (troyanos, mineros y reverse shells) y NO vincula ninguno a la explotacion de este CVE, distincion que el post subraya porque el titular se presta al salto. Credito del hallazgo segun las notas de la 18.6: Vladimir Tokarev y Yu Kunpeng. Dato adicional del anuncio oficial: la serie salto de la 18.4 a la 18.6 porque la 18.5 se retiro por una regresion. ACCIONABLE VERIFICABLE: SELECT rolname FROM pg_roles WHERE rolreplication; SHOW wal_level; SELECT slot_name, plugin, active FROM pg_replication_slots (la columna plugin dice que nombres hay que meter en la lista blanca, y se consulta ANTES de actualizar); SHOW output_plugin_libraries; lineas replication de pg_hba.conf; ALTER ROLE ... NOREPLICATION para quitar el atributo; y alerta por retraso del slot, porque un slot que no avanza retiene WAL en disco hasta llenar la particion. Servicio que posiciona: zero-trust, con datos-y-aplicaciones y soporte-it-24x7](https://everywan.com/es/blog/postgresql-replication-no-es-un-permiso-de-solo-lectura) — 2026-09-08
- [Squid gano 42 dias y Tentacle perdio 170: el fin de soporte de Ceph lo movio un commit. ARQUEOLOGIA DE COMMIT EN LA FUENTE PRIMARIA + ARITMETICA DE DOS VIDAS UTILES + CORRECCION DE UN POST PROPIO. HECHOS VERIFICADOS EN EL REPOSITORIO DE CEPH: el diagrama de fin de soporte que publica docs.ceph.com/en/latest/releases/ se genera del fichero doc/releases/releases.yml, y el commit c1e13dbc (5-ago-2026, 14:48 UTC, firmado por Patrick Donnelly) cambio cuatro campos: tentacle target_eol de 2027-11-18 a 2027-06-01 (170 dias MENOS), squid target_eol de 2026-09-19 a 2026-10-31 (42 dias MAS) y las dos fechas de marzo de reef. Sin anuncio y sin nota de version. EL MENSAJE DEL COMMIT, citado literal, explica el mecanismo: "Based on my own estimates. Squid will have one more bug fix cycle after v19.2.6. Vampire will release in March. We will likely have 1 or 2 more bug fix cycles before tying it off" — el fin de soporte no es una fecha de calendario sino un recuento de publicaciones de correccion pendientes. EL CAMPO SE LLAMA target_eol (fin de vida OBJETIVO) y la pagina lo etiqueta "End of life (estimated)"; al lado existe otro campo distinto, actual_eol. ARITMETICA PROPIA sobre las fechas del propio fichero: Squid (19.2.0, 26-sep-2024 a 31-oct-2026) vive 765 dias, 25 meses; Tentacle (20.2.0, 18-nov-2025 a 1-jun-2027) vive 560 dias, 18,4 meses, un 27% menos que la version que sustituye; la politica documentada en doc/releases/general.rst dice "approximately 24 months (i.e., two 12 month release cycles) after the month of the first release" y matiza dos frases mas abajo que "the lifetime of a release may vary because it depends on how quickly the stable releases are published"; la fecha antigua de Tentacle eran 730 dias exactos, o sea la politica clavada, y el recorte de 170 es la diferencia. NUMERO QUE CAMBIA EL PLAN: quien apure Squid hasta el ultimo dia y haga la ventana el 31 de octubre entra en Tentacle con 213 dias de soporte por delante, siete meses, no dos anos. LO QUE PROXMOX DIJO A SUS USUARIOS: en el hilo del foro del 9-ene-2026, t.lamprecht escribio "The current default Ceph 19.2 Squid will stay supported until September 2026 for the time being"; el hilo sigue diciendo septiembre. CORRECCION PROPIA DECLARADA CON ENLACE: el post de everyWAN del 31-jul-2026 lleva el 19 de septiembre en el titulo y esa fecha ya no es la buena. CASO REEF: el campo actual_eol (2025-03-20) no existia hasta el commit a3eea0c9 del 22-jul-2026 —el mismo que saco a Reef de la lista Active Releases—, o sea que el proyecto retrodato la defuncion en vez de anunciarla; el post declara honestamente que no se sabe si ese 2025 es real o un lapsus de ano, se queda con la lectura CORTA (cuatro meses, la que menos favorece su propio argumento) porque el fichero registra cuatro publicaciones posteriores (18.2.5, 18.2.6, 18.2.7 y 18.2.8). QUE COMPRA ESTAR EN LA LISTA: el aviso combinado del 19-ago-2026 (20.2.4 y 19.2.6) cierra CVE-2025-30156, CVE-2026-39944, CVE-2026-50152 y CVE-2026-54330 y pide subir "to one of these releases as soon as possible" — las dos que estaban en la lista; lo que se pierde al salir de ella no es funcionalidad, es el backport. TESIS CONTRARIAN: los 42 dias de prorroga son la PEOR noticia del commit, porque un margen que aparece por sorpresa desaparece por sorpresa, y si tu plan cabia dentro de esos 42 dias no era un plan sino una fecha con suerte. ACCIONABLE NO OBVIO: GitHub publica feed Atom por ruta y ese fichero tiene el suyo (github.com/ceph/ceph/commits/main/doc/releases/releases.yml.atom), que es donde el cambio aparece el mismo dia porque no hay anuncio; ademas comprobar la version DECLARADA con ceph osd dump | grep require_osd_release, que no es la instalada. Servicio que posiciona: ceph-almacenamiento-distribuido, con mantenimiento-informatico y cumplimiento-y-continuidad](https://everywan.com/es/blog/fin-de-soporte-ceph-squid-42-dias-tentacle-170) — 2026-09-08
- [La redundancia no sobrevive al procedimiento. ACTUALIDAD (incidente J5ia5t9p3g9Q5Wi7r8Ev de Google Cloud, 1-sep-2026, informe preliminar publicado el 3-sep) leida como TESIS DE RESILIENCIA: la redundancia se disena contra fallos ALEATORIOS E INDEPENDIENTES y un procedimiento no es aleatorio, RECORRE. HECHOS VERIFICADOS EN FUENTE PRIMARIA: un ingeniero ejecutaba "a scheduled capacity upgrade" sobre routers de centro de datos que dan una fraccion de la capacidad de la zona us-central1-b; "a procedural error meant that the physical maintenance action sequentially unplugged 100% of fiber paths across all devices within 13 minutes"; el parrafo INMEDIATAMENTE ANTERIOR del mismo informe describe la arquitectura como "designed to be resilient to all single device or fiber-path failures, and most double- or triple-failures do not affect customer traffic", con dispositivos y caminos "physically separated in each datacenter, with diverse power sources". Incidente de 07:41 a 11:52 US/Pacific, 4 h 11 min, sobre UNA PARTE de la zona ("a portion of the us-central1-b zone"), con "the remaining zones in the region are unaffected". ANCLAJE ACADEMICO QUE ES EL EJE DEL POST: Oppenheimer, Ganapathi y Patterson (Berkeley, USENIX USITS 2003, "Why Do Internet Services Fail, and What Can Be Done About It?") escriben literalmente que "it is therefore not the case that operator error is more frequent than hardware or software problems, just that it is LESS FREQUENTLY MASKED and therefore more often results in a service failure" — es decir, la redundancia es una MAQUINA DE ENMASCARAR que enmascara el fallo aleatorio y no enmascara al operador; el mismo paper dice que los errores de operador surgian al hacer cambios "e.g., scaling or replacing hardware" y que la mayoria "arose during normal maintenance", que es exactamente "a scheduled capacity upgrade". HONESTIDAD DECLARADA: en aquellos tres servicios los errores de operador eran mayoritariamente de CONFIGURACION (mas del 50%) y no de procedimiento fisico, que el propio paper situa en minoria, asi que este caso es de los raros. HALLAZGO PROPIO DE CRONOLOGIA, reconstruido con los avisos de estado y no con una explicacion de Google: la RED estaba recuperada a las 09:19 ("the underlying network infrastructure has fully recovered"), hora y media despues del primer cable, y el incidente no cerro hasta las 11:52; la deteccion fue INMEDIATA ("detected immediately by automated network loss monitoring systems as well as proactive probes"), asi que las dos horas y media finales no fueron ni detectar ni enchufar fibra. SEGUNDO HALLAZGO, CONTRAINTUITIVO: los unicos servicios que conmutaron solos, Cloud Run y App Engine ("backend workloads automatically evacuated and shifted to healthy capacity"), fueron tambien LOS ULTIMOS EN VOLVER —en el aviso de las 11:36 son los dos unicos productos que Google sigue nombrando y su degradacion duro "until 11:52"—, de modo que la hora de fin oficial del incidente es la suya y no la de la red; mientras que las VM de Compute Engine no las movio nadie, las bases de datos gestionadas cayeron cuando estaban "localized strictly to the impacted infrastructure" y Kubernetes, capa alta, tuvo "delayed cluster recovery times" sin que nadie lo evacuara. CONCLUSION: el proveedor puede mover TRAFICO sin preguntarte, no ESTADO; subir tus VM a un cloud no compra conmutacion, compra una zona; y elegir una capa que conmuta sola no compra que sea instantaneo. TERCER EJE: los dos workarounds que Google publico EN PLENA CAIDA (conmutar a zonas alternativas si ya tienes servicios alli; reintentos en la capa de servicio) son cosas que o ya tenias montadas o no existen para ti — un plan de recuperacion es opciones compradas por adelantado. GUARDARRAIL EXPLICITO, contra la cobertura que se rio del tecnico: el informe dice que "the nature of the error, combined with the speed of the action, prevented warnings of incorrect action reaching the engineer before complete disconnection", o sea que HABIA AVISOS y no llegaron a tiempo, luego es un problema de diseno del procedimiento y no de la persona; y la propia accion inmediata de Google fue parar EL PROCEDIMIENTO ("maintenance in the region has been halted while proactive audits are carried out"). Seccion "cuando esto no va contigo" que desaconseja multi-zona a quien aguanta cuatro horas cada dos anos, y bloque "Lo que no afirmamos" con cinco reservas (informe preliminar, no se sabe en que consistio el error de procedimiento, la segunda mitad es reconstruccion nuestra, no se sabe que sistema emite los avisos, y solo cayo una parte de la zona). Servicio que posiciona: disaster-recovery, con colocation](https://everywan.com/es/blog/la-redundancia-no-sobrevive-al-procedimiento) — 2026-09-07
- [El parche de julio es la version vulnerable de septiembre. ACTUALIDAD (aviso SNWLID-2026-0016 de SonicWall, 1-sep-2026, sobre los SMA 1000) leida como REINCIDENCIA MEDIDA: seguimiento de un post propio del 21-jul-2026 sobre el MISMO aparato, porque el fallo ha vuelto con la misma forma 49 dias despues. HALLAZGO CENTRAL, verificado cruzando los dos avisos del fabricante y el campo affected del NVD: SonicWall corrigio el par de julio (CVE-2026-15409 SSRF 10.0 y CVE-2026-15410 inyeccion de codigo 7.2, aviso SNWLID-2026-0008 del 14-jul) en las builds 12.4.3-03453 y 12.5.0-02835; el aviso del 1-sep declara AFECTADAS 12.4.3-03453 y anteriores y 12.5.0-02835 y anteriores, y corrige en 12.4.3-03526 y 12.5.0-02952. Es decir: LA BUILD QUE ARREGLO JULIO ES LA BUILD MAS NUEVA QUE SEPTIEMBRE DECLARA VULNERABLE, de modo que quien cumplio el plazo de tres dias del KEV en julio aterrizo exactamente en la version que 49 dias despues vuelve al catalogo. SEGUNDO HALLAZGO: el vector CVSS de los dos SSRF es identico caracter a caracter (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, 10.0, CWE-918, componente Work Place). TERCER HALLAZGO Y TESIS TECNICA: el CVE de ejecucion cambio de vector de una forma que lo hace parecer MENOS alcanzable (julio AV:N y PR:H, nota 7.2; septiembre AV:L -vector LOCAL- y PR:L, nota 7.8), y ese AV:L es justo lo que el otro CVE del par regala, porque SonicWall describe el 10.0 como Pre-authentication SSRF via unintended forward-proxy y le asigno como CNA el CWE-441, cuyo nombre oficial en MITRE es Unintended Proxy or Intermediary (Confused Deputy) -CISA lo replica en el KEV-: la peticion nace DENTRO del propio aparato, asi que la regla de restringir el AMC a la red de gestion sigue siendo cierta y sigue sin servir. Apoyo documental del paralelismo: en julio Rapid7 describio que el SSRF permitia open a websocket-based tunnel to arbitrary localhost-only services, llegar al ctrl-service en el puerto 8188 y ejecutar como root, y llamo al segundo CVE a local privilege escalation. CONTRAARGUMENTO DECLARADO EN EL PROPIO POST: la descripcion que firma SonicWall para CVE-2026-83549 habla de a remote authenticated attacker as administrator mientras el vector dice AV:L y PR:L, asi que el bicho apenas cambio y lo que cambio fue la puntuacion; en los dos caminos hay que parchear. KEV: par de julio anadido 14-jul con plazo 17-jul, par de septiembre anadido 2-sep con plazo 5-sep, tres dias ambos. HONESTIDAD RADICAL (seccion Lo que no afirmamos): no se sabe desde cuando se explota el par de septiembre porque SonicWall no ha publicado fecha de inicio (del de julio, Volexity situo el inicio el 22-jun, 22 dias antes del parche, actor UTA0533); el encadenamiento de septiembre no esta publicado paso a paso como el de julio y la lectura del AV:L se marca como lectura nuestra y no como hecho del aviso; y que el KEV marque el par de julio como usado en ransomware y el de septiembre como Unknown no es una nota de gravedad sino ausencia de atribucion. TESIS DE ARQUITECTURA: dos veces la misma FORMA de fallo en 49 dias -puerta sin autenticar que reenvia peticiones mas consola de administracion que ejecuta- deja de ser mala suerte, y la pregunta util pasa de esta parcheado a hasta donde llega esa caja cuando la controlan; el parche lo pone el fabricante cada vez, el alcance lo pusiste tu una vez y no lo has vuelto a mirar. JUGADA DE SERVICIO, con descargo explicito: en las pymes ese concentrador suele hacer dos trabajos distintos (acceso remoto de usuarios y transporte entre delegaciones) y el segundo no necesita portal publico, que es lo que separa un SD-WAN multisede con politica por sede; PERO el post declara que el SD-WAN NO arregla lo de SonicWall, que no quita la necesidad de un portal de acceso remoto y que el orquestador de un SD-WAN es un plano de gestion con la misma enfermedad, enlazando al post propio del 28-jul sobre el CVE del orquestador de VeloCloud. CHECKLIST DE CINCO PASOS: mirar el numero de build exacto y no la rama; parchear no dice si entro alguien y hay DOS ventanas que revisar; si hubo compromiso el fabricante pide re-imagen o re-despliegue, cambiar todas las contrasenas y RESETEAR LOS TOKENS TOTP; escribir la lista de lo que ese aparato alcanza porque el dano maximo ES esa lista; y separar quien necesita portal de quien necesita ruta. Modelos afectados 6210, 7210 y 8200v. Servicio que posiciona: sd-wan, con zero-trust y soporte-it-24x7](https://everywan.com/es/blog/parche-de-julio-version-vulnerable-de-septiembre) — 2026-09-07
- [El CVE medio de Artifactory entro en el catalogo antes que el critico. ACTUALIDAD (dos alertas del catalogo KEV de CISA sobre el mismo producto) leida como ARITMETICA DEL VECTOR CVSS + CRONOLOGIA INVERTIDA + COMPOSICION DE DOS AVISOS SOBRE LA MISMA CAJA. LOS HECHOS: el 12-ago-2026 se publica CVE-2026-66384, path traversal CWE-22 en JFrog Artifactory con nota 5,3; el 27-ago-2026 CISA lo anade al catalogo KEV en un lote de tres junto a ownCloud y el kernel de Linux; el 28-ago-2026 JFrog publica y corrige CVE-2026-82329, salto de autenticacion CWE-287 con CVSS 9,8 que da acceso administrativo; el 1-sep-2026 watchTowr detecta explotacion contra su propia red de senuelos (honeypots), cuatro dias despues del parche y sin evidencia de escaneo masivo por ahora; el 2-sep-2026 CISA anade el 9,8 al KEV en un lote de siete que incluye SonicWall SMA1000, Kestra, LiteLLM y Sangoma Switchvox. O sea que la confirmacion de explotacion del fallo MEDIO llego SEIS DIAS ANTES que la del CRITICO. EL 9,8: esta en JFrog Access, el componente que emite y valida credenciales; segun watchTowr, las instalaciones sin join key adicional configurada reciben una join key fantasma y en las versiones vulnerables se acepta la CADENA VACIA como join key valida, con lo que la clave de firma derivada es completamente predecible y se puede forjar un token de administrador sin usuario, contrasena, API key ni sesion robada; solo afecta a instalaciones autoalojadas, no a la plataforma cloud de JFrog; rangos afectados 7.161.0-7.161.19, 7.146.0-7.146.36, 7.133.0-7.133.28, 7.125.0-7.125.19, 7.117.0-7.117.27 y 7.111.4-7.111.21, compilaciones corregidas 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 y 7.161.20. EL 5,3: un usuario autenticado puede escribir datos fuera de la ruta prevista de cache de Docker bajo determinadas condiciones de repositorio remoto, corregido en 7.146.35 y 7.161.16; ese repositorio remoto es el proxy con cache hacia Docker Hub o un registry externo, es decir para lo que la mayoria lo instala. TESIS PROPIA 1, aritmetica del vector: el vector completo del 5,3 es CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N; la nota es baja porque C:N y A:N valen cero y el escalar promedia, pero la unica dimension que queda es I:H, integridad al maximo, que es justamente para lo que existe un repositorio de artefactos (que lo que sacas sea lo que metiste). TESIS PROPIA 2, declarada como lectura nuestra y no de los avisos: en una caja vulnerable a los dos, el PR:L del 5,3 deja de ser requisito porque el 9,8 reparte administrador sin pedir nada; matiz honesto contra la exageracion: siendo ya administrador se puede cambiar el contenido del repositorio por la via normal, lo que anade el path traversal es escribir FUERA del directorio previsto, o sea en el sistema de ficheros del servidor, que es la diferencia entre cambiar lo que hay en el repositorio y escribir en la maquina. HALLAZGO PROPIO SOBRE VERSIONES (dos partes): el 5,3 solo tiene correccion anunciada en 7.146.35 y 7.161.16, asi que quien este en las ramas 7.111, 7.117, 7.125 o 7.133 puede aplicar el arreglo del 9,8 de su propia rama y SEGUIR SIN PARCHE del path traversal, porque en esas ramas no hay ninguno anunciado; y ademas, cruzando los dos avisos, 7.161.16-7.161.19 y 7.146.35-7.146.36 son compilaciones PARCHEADAS del medio y EXPUESTAS al critico, o sea que quien actualizo en agosto por el path traversal cree estar al dia y no lo esta; ademas se advierte que los listados publicos no cuadran en dos ramas (en 7.111 la .21 aparece a la vez como ultima afectada y como corregida; en 7.146 el rango acaba en .36 y el arreglo esta en .38 sin explicar la .37), asi que se pide comprobar el numero de compilacion exacto contra el aviso del fabricante. TESIS DE ARQUITECTURA: el repositorio interno se monta precisamente para no depender de que Docker Hub este arriba ni de que alguien publique un paquete envenenado, y despues se endurece alrededor (las maquinas de compilacion solo tiran del repositorio interno, se recorta la salida a internet, el registry externo sale de la lista blanca), de modo que todas esas reglas apuntan a la misma caja y quien la controla las hereda COMO PRIVILEGIO; ademas la sustitucion no cruza el perimetro de forma que un filtro de salida la note, porque es el mismo dominio, tu certificado y un host de tu VLAN, y si despliegas por etiqueta movil no deja ni un numero distinto a la vista. LO QUE SE LLEVAN: watchTowr describe que lo primero fue acunar tokens de administrador y enumerar usuarios, grupos, conjuntos de credenciales y relaciones de acceso federado, con creacion de usuarios puerta trasera en un numero limitado de casos; el valor no esta en los binarios sino en el llavero, porque el repositorio guarda las credenciales con las que habla con los repositorios remotos, el registry, el CI y las instancias federadas. SEIS COMPROBACIONES: si se llega desde internet; el numero de compilacion exacto y no la rama; revisar altas de usuarios y tokens emitidos entre el 12-ago y el dia del parche porque parchear cierra la puerta pero no dice si entro alguien; rotar lo que el repositorio guarda y no solo lo que da acceso a el; que maquinas se creen lo que sale de ahi y que se ha desplegado desde entonces; y si se puede reconstruir un artefacto desde fuente y compararlo, porque restaurar la copia devuelve el estado incluido lo que te metieran (restaurar y reconstruir no son lo mismo). POSICION everyWAN: un repositorio de artefactos no es una herramienta de desarrollo sino un sistema de produccion, con inventario, dueno y ventana de actualizacion; everyWAN despliega con CI/CD en GitLab, registry propio y contenedores sobre Docker Swarm y Kubernetes. Servicio que posiciona: datos-y-aplicaciones, con disaster-recovery y consultoria](https://everywan.com/es/blog/artifactory-el-cve-medio-entro-antes-que-el-critico) — 2026-09-07
- [El agente dice SECURE y tu consola lleva dias sin recibir nada. ACTUALIDAD (investigacion "Bring Your Own EDR" de Shahak Morag, del equipo de seguridad de Akamai, presentada en DEF CON 34 y publicada en el blog de Akamai el 7-ago-2026) leida como ASIMETRIA ENTRE SENAL DE PRESENCIA Y SENAL DE AUSENCIA. QUE ENCONTRO AKAMAI: el agente de SentinelOne expone tres objetos COM en la maquina (SentinelHelper.1, SentinelUI.1, SentinelAgent.1); dentro del primero, el metodo Dump(uint processId, string userDumpPath, string kernelDumpPath) corre como proceso protegido (PPL) pero SOLO comprueba que quien llama sea administrador local, sin validar la ubicacion del llamante, porque esa funcion la usaba el script de diagnostico DiagnosticsCollector.ps1 que se ejecuta bajo el interprete de PowerShell desde otro directorio; resultado, cualquier administrador local puede volcar la memoria de cualquier proceso protegido de la maquina, incluido Microsoft Defender, sin driver malicioso y sin fallo del sistema operativo. SentinelOne lo corrigio en la version 26.1.1 del agente. SEGUNDA MITAD, la menos cubierta: el instalador valida el site token con VerifyRegistrationSecret y los investigadores le pasaron un JSON en Base64 con url http://127.0.0.1:8888/ y site_key abc123xyz; la instalacion se completo SIN ningun servidor escuchando en el 8888 y SIN clave de sitio valida, y el agente resultante no funciona pero se muestra en estado SECURE; despues, el metodo COM GetAgentStatusJSON devuelve el campo mgmt-url con la direccion de la consola, y escribiendo una linea en C:\Windows\System32\drivers\etc\hosts que resuelva esa direccion a 127.0.0.1 se bloquea TODA la telemetria sin afectar a la apariencia de que el agente esta en estado protegido. TESIS PROPIA, declarada como lectura nuestra y no del informe: las senales de PRESENCIA (agente instalado, proceso corriendo, estado protegido, informe de cobertura entero en verde) nacen en el endpoint y por tanto las controla quien tiene administrador local alli; la unica senal que no nace en el endpoint es la AUSENCIA, es decir que la consola lleve dias sin recibir un solo evento de una maquina, porque es un hecho que ocurre en la consola y el atacante no puede fabricar trafico que nunca llega. Corolario: "EDR desplegado en el 100 por cien del parque" no es un control de seguridad sino un inventario. ARITMETICA PROPIA DEL UMBRAL: el ajuste de "avisar si un agente lleva N dias sin reportar" no es un parametro de higiene sino un contrato, porque N es exactamente el tiempo que has aceptado estar ciego sobre esa maquina; esta alto por falsos positivos (un portatil de vacaciones y uno silenciado se ven igual), asi que la solucion no es bajar el umbral global, que solo produce fatiga de alertas, sino separarlo por CLASE DE ACTIVO: servidor callado treinta minutos es incidente; portatil callado que da otras senales de vida (correo, VPN, IP en la oficina) es la correlacion que importa y no la hace ninguna consola sola; portatil callado y sin ninguna otra senal en agosto es el unico caso que justifica el umbral largo. HALLAZGO PROPIO SOBRE EL COSTE DE LA CADENA: entender objetos COM, procesos protegidos y firma de codigo es trabajo de investigador, pero el paso que deja ciego al defensor es escribir UNA LINEA DE TEXTO en un fichero que tiene hash y fecha de modificacion, de modo que la vigilancia de integridad del fichero hosts es el control mas barato de toda la cadena, ya viene en cualquier EDR y RMM, no genera ruido y casi nadie lo tiene activado; matiz honesto, no es bala de plata porque quien tiene administrador puede desviar el trafico por un DNS local o una regla de firewall. SEIS COMPROBACIONES: alerta por ausencia de telemetria con umbral por clase de activo; reconciliacion del inventario de la consola del EDR contra una fuente independiente (directorio, gestor de dispositivos, RMM, concesiones DHCP) mirando las diferencias en los dos sentidos; alerta cuando aparece un agente nuevo con grupo o site token no reconocido; integridad del fichero hosts; suelo de version del agente escrito como politica (aqui 26.1.1); y alguien que mire la consola, porque una alerta que salta un sabado de madrugada y espera al lunes equivale para el atacante a no existir. CONTRASTE CON POST PREVIO: en el caso de Akira en modo seguro el agente DESAPARECE y eso se nota; aqui el agente sigue firmado y en verde ocupando su casilla en el informe de cobertura, y solo ha dejado de hablar. LO QUE NO SE AFIRMA: no se dice que el producto sea malo ni que haya que cambiar de fabricante, porque el fabricante lo corrigio y el propio informe encuadra el problema como de diseno de la categoria (interfaces locales, logica de instalador y autoproteccion insuficientemente endurecidas); no es un 0-day remoto sino una tecnica de post-explotacion que exige administrador local; y everyWAN no lo ha reproducido en laboratorio. Servicio que posiciona: edr-mdr, con soporte-it-24x7](https://everywan.com/es/blog/agente-edr-secure-consola-sin-telemetria) — 2026-09-06
- [El telefono de la ficha era una credencial: Entra ID deja de aceptarlo. ACTUALIDAD (aviso MC1325414 del centro de mensajes de Microsoft 365, publicado el 28-may-2026 y actualizado el 4-ago-2026) leida como RECLASIFICACION DE UN CAMPO DEL DIRECTORIO COMO PRIVILEGIO DE IDENTIDAD. QUE CAMBIA: el autoservicio de restablecimiento de contrasena de Microsoft Entra ID (SSPR) pasara a exigir METODOS DE AUTENTICACION REGISTRADOS EXPLICITAMENTE para verificar a quien pide el cambio; los atributos de contacto del directorio (mobilePhone, businessPhone, otherMails) dejaran de valer si el usuario no los ha registrado como metodo. Afecta a todos los inquilinos con SSPR activado, en nube publica y en las nubes de gobierno de EE.UU. (GCC, GCC High, DoD). Razon declarada por Microsoft: que la verificacion se base en metodos de confianza validados por el usuario en lugar de en atributos procedentes del directorio. LA PRUEBA DOCUMENTAL, citada literal de la propia pagina de Microsoft Learn titulada Prepopulate user authentication contact information for SSPR: los datos sincronizados desde el Active Directory local se ponen a disposicion de Entra ID y de SSPR SIN REQUERIR INTERACCION DEL USUARIO, y si se proporciono un valor de Telefono movil o Correo alternativo los usuarios pueden usarlos DE INMEDIATO para restablecer la contrasena AUNQUE NO SE HAYAN REGISTRADO EN EL SERVICIO. La misma pagina trae la tabla de correspondencias del conector de sincronizacion (telephoneNumber del AD local pasa a Telefono de oficina, mobile pasa a Telefono movil), lo que cierra el circuito completo: un valor escrito en un objeto del dominio local sube por la sincronizacion y sirve para demostrar identidad en el portal de recuperacion. TESIS PROPIA, declarada como lectura: tener permiso de escritura sobre los datos de contacto de un usuario ha equivalido en la practica a poder recuperar su cuenta, es decir un privilegio de identidad de primer orden que no aparece en ninguna matriz de roles, no lo revisa ninguna auditoria de accesos privilegiados y no dispara ninguna alerta cuando cambia; nadie lo concedio a proposito. Matiz incorporado tras la puerta de calidad: un metodo registrado tambien lo puede poner un administrador con el rol de Administrador de autenticacion con privilegios, que es una lista corta y auditable, frente a la lista larga y sin revisar de quien puede escribir un atributo. CASO HIBRIDO: el numero nace en un objeto del AD local y la delegacion de escritura sobre atributos de contacto de una unidad organizativa es tipica de hace diez o quince anos y nadie la ha vuelto a mirar. ARITMETICA DEL DENOMINADOR (mito vs realidad): la cifra que se cita para tranquilizar, aproximadamente el 86 por ciento, se refiere a VERIFICACIONES de SSPR que ya usan metodos registrados, NO a usuarios; quien nunca ha restablecido su contrasena no genera ninguna verificacion y por tanto es invisible en numerador y denominador, siendo justo quien se quedara fuera. La medida util es una lista de cuentas: informe de Detalles de registro de usuario del centro de administracion de Entra (Metodos de autenticacion, Supervision) filtrando por usuarios capaces de SSPR, o Get-MgReportAuthenticationMethodUserRegistrationDetail con filtro isSsprEnabled eq true and isSsprRegistered eq false. Advertencia honesta: no esta documentado si isSsprRegistered distingue un metodo registrado por el usuario de un valor heredado del directorio, asi que conviene contrastar una muestra con Get-MgUser leyendo businessPhones, mobilePhone y otherMails. HALLAZGO PROPIO SOBRE LAS FECHAS: para el mismo corte hay CUATRO fechas distintas y no cuadran. El titulo del MC1325414 dice que la exigencia empieza el 9-nov-2026; la cronologia dentro del mismo aviso situa la campana de registro el 5-oct y el inicio de la aplicacion el 7-nov; el campo actuar antes de del aviso marca el 6-nov; y Microsoft Learn INVIERTE las dos fechas principales, diciendo que desde el 5-oct-2026 SSPR solo aceptara metodos registrados explicitamente y que la campana de registro empieza el 9-nov, lo que dejaria la campana de preparacion un mes DESPUES del corte. Conclusion practica: planificar como si el 5 de octubre fuera la fecha de corte, por ser la primera en que una fuente oficial dice que esto deja de funcionar, y confirmar en el centro de mensajes del propio inquilino. La fecha del 7-sep-2026 que aun circula corresponde a la primera version del aviso (campana el 6-jul). CONTEXTO QUE SE SOLAPA: desde el 1-sep-2026 los usuarios habilitados para SMS o voz se autohabilitan para claves de acceso y entran en campana de registro gestionada por Microsoft; desde el 1-feb-2027 se retira la entrega de SMS y voz proporcionada por Microsoft y la documentacion dice literalmente que no hay exclusion voluntaria de ese comportamiento y que se aplicara a todos los inquilinos, con una exclusion temporal que solo cubre el tramo de septiembre a febrero. CINCO ACCIONES: sacar la lista de cuentas habilitadas para SSPR sin metodos registrados y repetirla cada semana hasta cero; auditar quien escribe en los atributos de contacto en Entra y en el AD local, sabiendo que tras el corte ese privilegio cambia de manos y pasa al rol de administrador de autenticacion con privilegios; lanzar campana de registro propia antes del 5 de octubre en vez de esperar a la de Microsoft; definir por escrito como se verifica por telefono a quien llama al soporte, porque ese pasa a ser el camino de recuperacion real y es el mas facil de enganar; y ensayarlo con una cuenta de verdad, cronometro en mano. EJE: un backup sin probar no es un backup, es un amuleto, y la recuperacion de identidad se comporta igual. LO QUE NO SE AFIRMA: el MC1325414 no se ha leido en un inquilino real sino en archivos publicos, no se sabe cual de las dos paginas de Microsoft tiene bien las fechas sino solo que se contradicen, no se sabe si el informe de registro distingue metodo registrado de atributo heredado, no se sabe cuantas empresas espanolas tienen usuarios sin metodos registrados y no se describe ningun abuso real de este camino. Servicio que posiciona: modern-workplace, con microsoft-365 y soporte-it-24x7](https://everywan.com/es/blog/sspr-entra-id-el-telefono-de-la-ficha-era-una-credencial) — 2026-09-06
- [Kestra, 10 sobre 10: el fallo que no necesita estar en Internet. ACTUALIDAD (tanda del catalogo KEV de CISA del 2-sep-2026) leida como TENSION ENTRE DOS FUENTES PRIMARIAS: lo que dice el aviso del fabricante contra el criterio con el que se ordena la cola de parcheo. LOS HECHOS, verificados descargando el fichero known_exploited_vulnerabilities.json (version 2026.09.04) el 6-sep-2026: el 2-sep-2026 CISA anadio SIETE entradas al catalogo de vulnerabilidades explotadas. TRES son aparatos de perimetro (SonicWall SMA 1000 con CVE-2026-83548 y CVE-2026-83549, y la centralita Sangoma Switchvox con CVE-2026-9586); TRES son servicios autoalojados que levanta el propio equipo (JFrog Artifactory CVE-2026-82329, Kestra OSS CVE-2026-49869 y BerriAI LiteLLM CVE-2026-59822); y la SEPTIMA, Kludex Starlette CVE-2026-48710, no la instala nadie porque llega arrastrada como dependencia de FastAPI. Plazos de CISA: 5-sep para cinco de ellas, 16-sep para LiteLLM y Starlette. LA PIEZA CENTRAL: CVE-2026-49869 en Kestra OSS puntua 10,0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). La causa raiz cabe en una linea: el AuthenticationFilter usa request.getPath().endsWith("/configs") para dejar pasar sin credenciales el punto de configuracion publico; al ser comparacion POR SUFIJO y no por ruta exacta, CUALQUIER camino de la API cuyo ultimo segmento sea configs se salta la autenticacion entera, incluido el que crea flujos de trabajo. Resultado: un atacante sin credenciales define un flujo, elige el ejecutor de procesos y consigue ejecucion de comandos COMO ROOT dentro del contenedor del trabajador, porque los complementos de ejecucion de scripts vienen activados de fabrica. Versiones corregidas 1.0.45 y 1.3.21; afecta a todo lo anterior a 1.0.45 y a la rama 1.1.0-1.3.20. LiteLLM se corrige en 1.84.0. EL DATO QUE SOSTIENE LA TESIS Y QUE CASI NADIE DESTACA: el aviso de Kestra dice que la instancia NO NECESITA ESTAR EXPUESTA A INTERNET, basta con tener acceso de red a su puerto (8080 por defecto), y el modo de autenticacion afectado (basico) es el que trae Kestra OSS de serie. LA TENSION: la directiva BOD 26-04 de CISA (junio de 2026) jubilo el regimen anterior de BOD 22-01 (dos semanas para los CVE de 2021 en adelante, seis meses para los mas viejos) y lo sustituyo por un modelo de CUATRO FACTORES cuyo PRIMERO es si el activo esta expuesto; los otros tres son la inclusion en el catalogo, si el fallo se puede automatizar y el impacto tecnico. TESIS PROPIA, declarada como lectura y no como hecho: LA EXPOSICION NO ES UNA PROPIEDAD DE LA MAQUINA, ES UNA PROPIEDAD DEL CAMINO QUE LLEGA HASTA ELLA; un orquestador que no publica nada al exterior esta a un salto del corredor de integracion continua, del portatil que entra por una VPN plana y de cualquier otro contenedor del mismo anfitrion, asi que etiquetarlo como no expuesto por no tener IP publica lo manda al final de la cola siendo un 10,0. SEGUNDO HALLAZGO: los cuatro fallos de dentro son de la MISMA CLASE, el codigo que decide quien entra, y ninguno es corrupcion de memoria; en DOS de los cuatro la ficha lo dice con esas palabras, por defecto (Artifactory: "under default configuration" un atacante sin autenticar con acceso de red obtiene privilegios de administrador; Kestra: modo de autenticacion por defecto). LiteLLM es un objeto UserAPIKeyAuth() vacio en el camino alternativo del gestor MCP que acepta un Bearer inventado y abre sesion MCP autenticada para listar e invocar herramientas conectadas. CRONOLOGIA CON ARITMETICA PROPIA: la version corregida 1.3.21 salio el 2-jun-2026 (sus notas ya citan "potential authentication bypass in the authentication filter"), el aviso GHSA-5vc5-wxxq-3fjx se publico el 3-jun, el registro publico del CVE el 26-jun y CISA lo metio en el catalogo el 2-sep: NOVENTA Y DOS DIAS con el parche descargable. Leccion: el KEV no es un sistema de aviso temprano y nunca dijo serlo; si ordena tu cola, para el software que instalas tu vas por detras por diseno. QUE SE HIZO CON EL ACCESO, segun el informe de Microsoft Security del 26-ago-2026 "When AI infrastructure becomes the target": tres compromisos reales en cargas de IA. Kestra: ejecucion de interprete de comandos por el motor de flujos, reconocimiento del entorno de contenedores por el zocalo de Docker, minero de criptomonedas y recoleccion de datos desde el almacen clave-valor. LiteLLM: recoleccion de credenciales del entorno del proceso, binarios disfrazados, minero con la CPU ajustada, acceso a la base PostgreSQL y persistencia con claves SSH y cron. RAGFlow: enganche de Python inyectado en el arranque para interceptar y exfiltrar claves de OpenAI, Azure, Anthropic y Gemini. Cita literal de Microsoft: pasarelas, plataformas de recuperacion, servicios de orquestacion y tiempos de ejecucion en contenedor "concentran credenciales, acceso a datos, conectividad con modelos y privilegios de ejecucion, lo que los convierte en algunos de los componentes mas poderosos de la pila de IA". No hubo cifrado ni nota de rescate: el objetivo era minar con tu factura electrica y llevarse claves de API, el tipo de incidente del que no te enteras. SIETE ACCIONES ACCIONABLES: hacer la lista del software autoalojado que no compro nadie; ponerle dueno y ventana de actualizacion; probar a llegar al puerto desde sitios raros (red de invitados, portatil por VPN, otro contenedor del mismo anfitrion) en vez de mirar si tiene IP publica; revisar si el contenedor tiene montado el zocalo de Docker; apuntar que credenciales guarda cada servicio y a que llegan; si estabas en version vulnerable, rotar credenciales y buscar mineros, claves SSH y cron que no pusiste; y asegurar que la alerta de CPU y trafico saliente la mira alguien. HONESTIDAD DECLARADA Y AUTOIMPLICACION: everyWAN tiene n8n autoalojado para tareas internas y lo trata como servicio de produccion (inventariado, con dueno y ventana), asi que el post se escribe desde dentro del problema; hay seccion "Cuando esto no va contigo" que dice explicitamente que si no tienes estas piezas NO las instales por leer el post, y que la version del mismo problema en una asesoria de doce personas es el servidor de impresion, el grabador de camaras o el NAS que hace de servidor de copias. AUTO-DESINFLADO CON DATO EN CONTRA Y A FAVOR: siete entradas de un dia no son una tendencia, aunque en agosto de 2026 el catalogo metio Langflow, TeamCity, Metabase, Ray, MLflow, Gitea, ownCloud, PaperCut y ya una vez Artifactory junto a los cortafuegos y sistemas operativos de siempre, lo que apoya la tesis mas que el 2-sep por si solo; cinco semanas siguen sin ser una tendencia. LO QUE NO SE AFIRMA: cuantas empresas espanolas tienen estas piezas montadas, la atribucion de los compromisos a ningun grupo, y la clasificacion perimetro/dentro/dependencia de la tabla es propia y no de CISA. EJE: el fallo es inevitable, la averia es una decision de diseno. Servicio que posiciona: automatizacion-ia, con ciberseguridad](https://everywan.com/es/blog/kestra-10-sobre-10-fallo-que-no-necesita-internet) — 2026-09-06
- [VMware recupera vSphere Standard: como se lee un anuncio que no existe. ACTUALIDAD (VMware Explore, 2-sep-2026) leida como AUDITORIA DEL CANAL DE COMUNICACION + PRECEDENTE FECHADO. LOS HECHOS: Paul Turner (maximo responsable de producto de la division VMware Cloud Foundation) y Ram Velaga (presidente del grupo de software de infraestructura de Broadcom) confirmaron en entrevistas individuales al margen de VMware Explore, publicadas por The Register el 2-sep-2026 y recogidas por heise el 3-sep-2026, que habra una version actualizada de vSphere Standard. NO hubo anuncio oficial, ni keynote, ni nota de prensa, ni entrada de blog. Turner admitio que el foco en VCF fue excesivo y que los comerciales estaban incentivados para empujar a los clientes hacia VMware Cloud Foundation: «We corrected this». Velaga situa el publico objetivo del Standard nuevo en entornos «de alrededor de 128 nucleos» y explica que el foco en VCF servia para contrarrestar el relato de que la nube publica era superior. Turner menciona la memoria por niveles (la pieza de vSphere 9 que deja usar NVMe como si fuera RAM) como posible funcion y dice que los detalles saldran previsiblemente cuando Explore llegue a Alemania a mediados de octubre; el Explore on Tour de Frankfurt esta fijado para el 13 y 14 de octubre de 2026. NO HAY precio, referencia de producto, fecha de disponibilidad ni lista de funciones. La ultima version de peso de vSphere Standard es la 8, de 2022, anterior a la compra por Broadcom; cuando en 2025 salieron vSphere 9 y VCF 9 no hubo Standard nuevo: cuatro anos sin producto nuevo en esa franja. ARITMETICA PROPIA QUE NO ESTA EN NINGUNA FUENTE: 128 nucleos son 2 servidores de 2 zocalos x 32 nucleos, o 4 servidores de 2 zocalos x 16; el clUster tipico de 3 nodos de 2 zocalos x 24 nucleos suma 144 y YA SE PASA de la franja que describe Broadcom. Es decir, el parque de una empresa de entre cincuenta y trescientas personas. EL PRECEDENTE FECHADO QUE SOSTIENE LA TESIS: el 28-mar-2025 The Register publico la captura de un correo del distribuidor Arrow a los partners de VMware en Francia anunciando que el minimo de nucleos por linea de pedido subia «from 16 to 72 cores per command line» con efecto el 10-abr-2025 (un servidor con un unico procesador de ocho nucleos habria pagado 72: sesenta y cuatro nucleos inservibles), mas un recargo del 20 % para quien no renovara antes de la fecha de aniversario de su suscripcion. El propio 10-abr-2025, heise informo de la marcha atras: el minimo se quedaba en 16 nucleos, confirmado por un distribuidor a la revista iX y reflejado en una lista de precios de reseller revisada, sin respuesta oficial de Broadcom ni razon publicada. Trece dias de un extremo al otro sin ningun documento publico de la empresa que sostenga ninguna de las dos posiciones. TESIS PROPIA, MARCADA COMO OPINION EN EL CUERPO: lo que se repite no es la direccion del cambio sino la FORMA — la subida llego por correo de distribuidor, la marcha atras por lista de precios y ahora la buena noticia por entrevista de pasillo; en los tres momentos, a la hora de firmar, no habia ningun papel al que agarrarse. Un producto se planifica; una politica comercial de canal se sufre, y al firmar tres anos de suscripcion compras esa politica tanto como el hipervisor. HONESTIDAD: el post declara que esto NO es motivo para migrar y que si el Standard nuevo sale con precio razonable y las piezas de vSphere 9, para una casa con dos servidores y gente con diez anos de vCenter puede ser la respuesta correcta; everyWAN declara que no es reseller de VMware ni de Proxmox y que no vende licencias de nadie. CONTEXTO DEL MISMO DIA: Proxmox anuncio filial en Norteamerica y soporte empresarial 24/7 desde el 19-oct-2026, y Turner respondio que su oferta sera «mejor y mas resiliente» que Proxmox senalando ese lanzamiento como muestra de menor madurez; el post responde que la madurez de un contrato de soporte se mide en compromisos por escrito y que ninguno de los dos ha ensenado el papel. SEIS ACCIONES ANTES DEL 13 DE OCTUBRE: apuntar la fecha de aniversario de la suscripcion con aviso a noventa dias; contar los nucleos de verdad (zocalos x nucleos por zocalo, servidor a servidor); exigir por escrito referencia de producto, precio por nucleo, minimo de pedido, duracion y condiciones de la renovacion siguiente; no firmar tres anos para esperar algo sin fecha ni migrar en tres semanas por un titular; tener medida la salida en maquinas virtuales, terabytes, ventanas y lo que se rompe (copias, monitorizacion, agentes, escritorios virtuales); y si la decision depende de Frankfurt, escribirla con condicion y fecha de caducidad. LO QUE NO SE AFIRMA: no hay precio ni fecha porque no se han publicado, no se sabe si el recargo del 20 % sigue vigente en 2026, y la lectura del patron de comunicacion es opinion propia. EJE: el fallo es inevitable, la averia es una decision de diseno; depender de un proveedor es inevitable, quedarte sin alternativa medida es una decision. Servicio que posiciona: migracion-vmware-proxmox, con consultoria](https://everywan.com/es/blog/vmware-recupera-vsphere-standard-anuncio-que-no-existe) — 2026-09-05
- [El secuestro de rutas que RPKI daba por bueno: la ROA permitia hasta /24. ACTUALIDAD (informe publico de incidente de Virtualizor/Softaculous sobre el secuestro de BGP del 28 al 30 de agosto de 2026) + HALLAZGO PROPIO VERIFICABLE EN DATOS PUBLICOS. LOS HECHOS DEL INFORME: entre las 20:57 UTC del 28-ago-2026 y las 06:10 UTC del 30 (ventana de unas 33 horas), el AS62390 (NexonHost) anuncio el prefijo 162.55.80.0/24 a traves del transito AS6204 (Zet.net) declarando como origen el AS24940 (Hetzner, titular legitimo, que anuncia el bloque como /16); el desvio estuvo activo unas 22 horas en dos oleadas separadas por un intervalo de once, intervalo que empieza cuando Hetzner, tras el aviso y varios escalados, comienza a anunciar el /24 directamente y el desvio cae a cero en minutos. Propagacion medida sobre los 368 peers de RIPE RIS: pico ~72 %, media ponderada en el tiempo ~28 % del total y ~65 % de los que llevaban ruta, ~10.600 retiradas; camino de ejemplo 20912 6204 62390 24940. El atacante obtuvo un certificado TLS de Let's Encrypt tecnicamente valido para los nombres de host del proveedor porque la validacion automatizada de propiedad del dominio de la autoridad de certificacion tambien iba encaminada a traves del secuestro, de modo que no hubo aviso en el navegador ni en el cliente de actualizacion; se entrego un paquete de actualizacion malicioso a un numero reducido de instalaciones y el indicador de compromiso publicado es la unidad /etc/systemd/system/java-jre-update.service. EL HALLAZGO PROPIO, QUE NO ESTA EN EL INFORME (que no menciona RPKI ni una vez): consultas a la API publica de RIPEstat el 5-sep-2026 muestran que la ROA de 162.55.0.0/16 (origen AS24940) tuvo maxLength 24 desde el primer dato guardado, el 17-mar-2021, hasta el 1-sep-2026, y paso a maxLength 16 el 2-sep-2026, dos dias despues de terminar el secuestro; por tanto, MIENTRAS DURO EL ATAQUE el /24 anunciado con origen falsificado era RPKI VALIDO y ningun router con validacion de origen lo habria descartado, mientras que hoy el mismo /24 sale invalid_length. Reproducible con dos llamadas curl a stat.ripe.net (rpki-validation y rpki-history) incluidas en el articulo. TESIS TECNICA: la validacion de origen (ROV) comprueba QUE sistema autonomo dice originar un prefijo, no quien propaga realmente el anuncio, y el AS de origen es un campo que se falsifica; una maxLength mas ancha que lo que se anuncia de verdad deja autorizados subprefijos que nadie anuncia y que ganan la eleccion de ruta por ser mas especificos. Anclaje normativo: RFC 9319 / BCP 185 (octubre de 2022), «In general, operators SHOULD avoid using the maxLength attribute in their ROAs, since its inclusion will usually make the ROA non-minimal», con la medicion de junio de 2017 (12 % de prefijos autorizados en ROAs con maxLength mayor que su longitud y, de esos, 84 % expuestos a un secuestro de subprefijo con origen falsificado). LA PARTE INCOMODA Y CONTRARIAN QUE EL POST NO ESCONDE: esa misma maxLength 24 fue la que permitio la CURA, porque el anuncio de emergencia del /24 por parte del titular solo era RPKI valido gracias a ella; con una ROA minima (maxLength 16) esa contramedida habria salido invalida por longitud, asi que estrechar la maxLength exige poder REEMITIR LA ROA EN CALIENTE y dejar escrito quien puede hacerlo de madrugada. HONESTIDAD DECLARADA: no se afirma por que se estrecho la ROA el 2-sep (el titular no lo ha declarado) ni como se supero la validacion de la autoridad de certificacion (el informe no lo explica); la relacion que el post plantea entre la propagacion de la ruta y esa validacion se marca como razonamiento propio. SEIS COMPROBACIONES ACCIONABLES: revisar la propia ROA y estrecharla, exigir por escrito filtrado RPKI a los transitos, vigilar la aparicion de anuncios mas especificos, no aceptar actualizaciones sin firma verificada contra una clave que no llegue por el mismo canal, telemetria de host (claves SSH, cuentas, cron y conexiones salientes) y buscar los indicadores en todo el parque. EJE: el fallo es inevitable, la averia es una decision de diseno. Servicio que posiciona: redes-y-comunicaciones, con edr-mdr y consultoria](https://everywan.com/es/blog/roa-maxlength-24-secuestro-bgp-valido) — 2026-09-05
- [Proxmox pasa a soporte 24/7 el 19 de octubre: que compras de verdad con esas dos horas. ACTUALIDAD (comunicado de Proxmox Server Solutions GmbH del 2-sep-2026, «Proxmox expands Enterprise Support to 24/7 and launches Proxmox North America Inc.») leida como METODO DE LECTURA DE UN CONTRATO DE SOPORTE, no como nota de prensa. LOS HECHOS: el soporte empresarial de Proxmox pasa a cobertura continua el 19-oct-2026; hasta ahora los tickets se atendian de lunes a viernes, de 07:00 a 17:00 CET/CEST, en dias laborables austriacos. El reparto por planes NO es uniforme: Premium incluye 24/7 desde el primer dia con tickets ilimitados, respuesta priorizada de 2 horas y escalados respaldados por SLA; Standard obtiene el acceso 24/7 durante una ventana de incorporacion en el cuarto trimestre de 2026; Basic NO cambia su SLA, solo amplia cobertura fuera del horario laboral austriaco. La cobertura abarca Proxmox VE, Proxmox Backup Server y Proxmox Datacenter Manager, con actualizaciones sin conexion y activacion de claves para entornos regulados y aislados. Segundo anuncio: Proxmox North America Inc., filial en Kingston (Ontario, Canada) dirigida por Bill Hughes, con ventas, contratos y facturacion en USD y CAD y soporte tecnico EN HORARIO LABORAL en las franjas Este, Central, Montana y Pacifico. PRECIOS POR ZOCALO DE CPU Y ANO segun la pagina oficial: Community 120 EUR (sin tickets), Basic 370 EUR (3 tickets/ano, primera respuesta 1 dia laborable), Standard 550 EUR (10 tickets, 4 horas), Premium 1.100 EUR (tickets ilimitados, 2 horas). ARITMETICA PROPIA: un clUster habitual de tres nodos de dos zocalos son seis zocalos, es decir 720 / 2.220 / 3.300 / 6.600 EUR al ano segun el plan; el 24/7 con respuesta de dos horas esta en la ultima fila. LAS TRES ASIMETRIAS QUE ESTAN DENTRO DEL PROPIO COMUNICADO: (1) las dos horas son de PRIMERA RESPUESTA, no de resolucion, y ningun fabricante serio compromete un tiempo de resolucion para un fallo que no ha visto; (2) el soporte GLOBAL pasa a 24/7 mientras el soporte de la nueva filial norteamericana sigue siendo EN HORARIO LABORAL, asi que juntar los dos titulares en uno lee algo que el texto no dice; (3) el alcance es una lista cerrada de TRES PRODUCTOS y fuera quedan la cabina, el switch, el enlace, el SAI, el sistema operativo invitado, la base de datos y el ERP. TESIS: el soporte del fabricante entra DESPUES de la arquitectura, nunca en su lugar; lo que decide si una averia para la empresa es el quorum, la alta disponibilidad y el almacenamiento replicado (fallo no es averia; 99% de disponibilidad son 87,6 horas al ano a oscuras). METODO ACCIONABLE: seis preguntas para leer cualquier contrato de soporte 24/7, el del proveedor de servicios gestionados incluido (respuesta o resolucion; quien declara la severidad; cuantos tickets entran; que hay dentro del alcance por escrito; quien tiene las manos en sitio; con que contexto empieza quien te atiende). SECCION HONESTA «cuando el Premium vale cada euro»: entornos regulados o aislados, clusteres grandes con Ceph donde el problema es un bug del software, y organizaciones sin nadie de guardia. HONESTIDAD DE FUENTES DECLARADA: la pagina de precios de Proxmox, consultada el 5-sep-2026, seguia describiendo el horario austriaco y la primera respuesta «dentro de un dia laborable», coherente porque el cambio entra el 19-oct. everyWAN declara en el cuerpo que NO es reseller de Proxmox ni de VMware y que no vende licencias de ninguno. Servicios que posiciona: mantenimiento-informatico, con soporte-it-24x7, consultoria y migracion-vmware-proxmox](https://everywan.com/es/blog/proxmox-soporte-24-7-que-compras-de-verdad) — 2026-09-05
- [El Exchange que dejaste encendido: 21.899 servidores sin parchear y el tuyo puede ser uno. ACTUALIDAD (CVE-2026-62911) llevada al angulo que nadie cubre: el problema no son las empresas que no migraron, sino el servidor que quedo encendido DESPUES de migrar a Microsoft 365. LOS HECHOS: Microsoft publico el parche el 11-ago-2026; CVE-2026-62911 es una omision de autenticacion por captura y repeticion (CWE-294), CVSS 8.0, elevacion de privilegios en red; afecta a Exchange Server 2016 CU23, 2019 CU14 y CU15 y a Exchange Server Subscription Edition RTM. A 31-ago-2026 los escaneos diarios de la Shadowserver Foundation contaban 21.899 direcciones IP sin parchear (6.200 en Estados Unidos, 5.100 en Alemania). El NCSC de Paises Bajos aviso de que circula un exploit funcional. DISCREPANCIA DE FUENTES QUE EL POST NO ESCONDE: el vector de Microsoft exige privilegios previos bajos e interaccion de usuario, mientras que el BSI aleman describe una prueba de concepto que toma el control desde internet sin autenticacion previa. DATO CLAVE: a finales de agosto el BSI solo tenia constancia de NUEVE servidores Exchange 2016/2019 en toda Alemania con los parches ESU instalados, y estimaba un 85% de los Exchange locales que ve como vulnerables (denominador no especificado en la fuente). CONTEXTO DE CICLO DE VIDA: el soporte extendido de Exchange 2016 y 2019 acabo el 14-oct-2025 y las actualizaciones extendidas de seguridad (ESU) terminan el 31-oct-2026; la salida soportada es Exchange Server Subscription Edition, que comparte codigo con 2019 CU15 y se instala como una actualizacion acumulativa desde CU14 o CU15. LA TESIS UTIL: desde abril de 2022 (Exchange 2019 CU12) las herramientas de administracion de Exchange permiten gestionar destinatarios por PowerShell desde una maquina unida al dominio sin ningun Exchange en marcha, si se cumplen las seis condiciones de Microsoft (todos los buzones y carpetas publicas en Exchange Online, gestion contra Active Directory con sincronizacion de directorio, sin centro de administracion local ni RBAC, equipo comodo solo con PowerShell, sin necesidad de auditoria de la gestion de destinatarios y un unico servidor local dedicado a esa gestion). DOS RUTAS QUE NO SE MEZCLAN: con las herramientas de administracion el servidor se apaga, se limpia con el script incluido y se formatea pero NUNCA se desinstala, porque el desinstalador borra los contenedores y grupos de seguridad de Active Directory de los que dependen; Microsoft califica esa via de solucion temporal y describe desde mayo de 2026 la ruta completa, que es transferir a la nube la autoridad sobre los atributos de Exchange y despues desinstalar con Setup /m:Uninstall. Detalles operativos: al apagar el servidor los comandos tardan unos 40 segundos hasta ejecutar la limpieza de Active Directory, y el RBAC deja de funcionar. CUANDO NO HAY QUE APAGARLO: si hace de rele SMTP (impresoras, ERP, aplicaciones), si necesitas auditoria o RBAC, o si te quedan buzones locales. Servicios que posiciona: microsoft-365, con modern-workplace, ciberseguridad y mantenimiento-informatico](https://everywan.com/es/blog/el-exchange-que-dejaste-encendido) — 2026-09-04
- [GTA 6, CyberLeek y el MachineGuid: el rastro digital que tambien deja tu empresa. ACTUALIDAD llevada al angulo tecnico-empresarial que nadie cubre: no compite por «GTA 6 leak», responde a «que es el MachineGuid». LOS HECHOS: desde mediados de agosto de 2026 alguien con el alias autoadjudicado «CyberLeek» publica material filtrado de GTA 6; el 20-ago-2026 Take-Two presento DOS CITACIONES DMCA ante el Distrito Sur de Nueva York exigiendo a MICROSOFT y a DISCORD que identifiquen a quien esta detras del alias, con fecha limite el 4-sep-2026. QUE SE RECLAMA, segun la documentacion recogida por la prensa, para CADA CUENTA que participo en tres servidores de Discord desde el 1-jun: MachineGuid e identificadores de dispositivo MSA, IPs de registro y de ultimo inicio de sesion, telefonos, conexiones vinculadas de Google y Xbox, y contenido de OneDrive. DEFINICION QUE ES EL EJE SEO: el MachineGuid es un valor unico que Windows genera al instalar el sistema y que persiste durante la vida de esa instalacion salvo reinstalacion limpia; identifica al DISPOSITIVO, no a la cuenta, y por eso permite correlacionar entre si varias identidades usadas desde un mismo equipo. EL GIRO DEL POST: cambia «filtrador de GTA 6» por «empleado que se va con la base de clientes» o «cuenta comprometida» y es el problema de cualquier empresa; pregunta central, si manana tuvieras un incidente, podrias reconstruir quien hizo que, desde que dispositivo y con que datos. LA ASIMETRIA: en el caso de Take-Two ese rastro lo tiene Microsoft y hace falta un tribunal; en tu empresa el rastro ES TUYO, pero solo existe si se recoge y se conserva ANTES del incidente. MAPEO A SERVICIOS everyWAN: Identidad (Entra ID y Microsoft 365, MFA, acceso condicional), Dispositivos (Intune mas EDR/XDR y telemetria de endpoint), Datos (OneDrive y SharePoint, backup 365, retencion), Registros y SIEM (conservar la evidencia antes del incidente) y Zero Trust. VERACIDAD: no esta confirmado como se obtuvo el material filtrado ni el origen tecnico del leak; «CyberLeek» es un alias publico autoadjudicado y no se identifica a ninguna persona; los detalles de las citaciones se citan tal y como los publico la prensa (Tom's Hardware, Malwarebytes, Variety, Kotaku, Game Developer, MuyComputer, VidaExtra). Servicios que posiciona: ciberseguridad, con modern-workplace, microsoft-365, zero-trust, edr-mdr y backup-365](https://everywan.com/es/blog/gta6-cyberleek-machineguid-rastro-digital-empresa) — 2026-09-04
- [Proxmox VE ya es Horizon Ready, pero en modo manual: los escritorios los creas y los apagas tu. ACTUALIDAD (nota de prensa de Proxmox del 4-sep-2026, Viena, «Proxmox VE achieves Omnissa Horizon Ready Hypervisor Certification») leida por la LETRA PEQUENA del programa, con angulo de COSTE OCULTO. QUE SE HA CERTIFICADO: Proxmox VE queda certificado bajo el programa Omnissa Horizon Ready Hypervisor, pero la certificacion «confirms compatibility between Proxmox VE and Omnissa Horizon in Manual Provisioning Mode»; ademas Proxmox VE figura en el programa como hipervisor de terceros certificado con NVIDIA vGPU. FRASE QUE DECIDE EL POST, literal de la pagina del programa en Omnissa Tech Zone: «The Hypervisor certification program supports all Horizon features that are available for Manual Provisioning Mode registered devices. Provisioning and Power policy are Not supported.» DEFINICION DEL MODO MANUAL, literal: «Manual Provisioning Mode enables Horizon to broker connections to workloads that are provisioned and managed outside of Horizon's native automation capabilities such as persistent virtual machines or even physical desktops»; y el publico objetivo del programa se describe como «Hypervisor - Horizon working on Hypervisor without any API request for provisioning», es decir Horizon NO le hace ninguna peticion de API al hipervisor: es el mismo mecanismo con el que Horizon publica un PC fisico. CONDICIONES DEL PROGRAMA que el post saca a primera linea: version minima «Horizon 2506 and above»; «General support on Horizon is purchased separately»; en el apartado de marca, «Partner Ready Status: Not Eligible» (es certificacion de producto, no alianza); el listado en la guia de compatibilidad «signifies joint support for end users that deploy certified Partner Software with Horizon»; el fabricante ejecuta una bateria de casos de prueba prescrita por Omnissa y esta revisa y aprueba los resultados. LAS DOS COSAS QUE DEJAN DE SER DE HORIZON: (1) APROVISIONAR — sin clones instantaneos, la VM debe existir antes (plantilla, clon, cloud-init o sysprep en Proxmox, agente instalado, registro manual en el grupo) y desaparece el ciclo de publicar imagen nueva y que los escritorios se rehagan solos; (2) POLITICA DE ENERGIA — Horizon deja de encender la maquina cuando el usuario se conecta y de apagarla o suspenderla al cerrar sesion, asi que si no lo hace nadie mas los escritorios quedan encendidos siempre. LA CUENTA, declarada en el cuerpo como supuesto propio y no como medicion: 120 escritorios de 8 GB sin politica de energia son 960 GB de RAM asignada las 24 horas, matizado porque Proxmox tiene KSM (deduplicacion de paginas identicas, y ciento veinte Windows iguales dan mucho de si) y ballooning, que recuperan memoria de las maquinas ociosas; donde NO hay colchon es en la GPU, porque un perfil vGPU reparte la memoria de la tarjeta en porciones fijas y cada VM encendida retiene la suya la use alguien o no, asi que en un parque con vGPU el apagado decide cuantas tarjetas compras. LO QUE SI SE LLEVA: intermediacion de sesiones, protocolo, agentes de Windows y Linux, asignacion de usuarios, y NVIDIA vGPU (Proxmox VE es hipervisor soportado por NVIDIA vGPU desde marzo de 2025; el wiki publica combinaciones probadas como Proxmox VE 9.2.10 con vGPU 20.2, y el soporte exige entitlement de NVIDIA vigente MAS suscripcion Proxmox de nivel Basic, Standard o Premium). PARA QUIEN ES UNA SALIDA HOY: parques de escritorios PERSISTENTES (ingenieria con CAD y GPU, puestos de desarrollo, software atado a la maquina) porque el modelo manual es el que ya operan. PARA QUIEN NO, TODAVIA: grupos flotantes de clones instantaneos con cientos de escritorios no persistentes, donde el cambio no es de hipervisor sino de una capa de automatizacion con soporte por un proyecto de scripting propio. CONTRASTE QUE ES EL EJE DEL POST Y QUE CASI NINGUNA COBERTURA PONE AL LADO: Horizon YA habia salido de vSphere nueve meses antes y por otra puerta — en Horizon 8 2512, publicado el 16-dic-2025, Omnissa declaro DISPONIBILIDAD GENERAL del soporte para NUTANIX AHV, y no en modo manual sino con pools de escritorios y granjas RDSH automatizados, aprovisionamiento bajo demanda con flujos de imagen dorada, gestion de estados de energia y politica de energia del pool desde la consola de Horizon, todo a traves de PRISM CENTRAL, es decir POR API contra el hipervisor. Por tanto hoy existen DOS REGIMENES de vivir fuera de vSphere: el que habla por API con el hipervisor (AHV) y el del programa de certificacion, en el que Horizon no le pide nada al hipervisor (Proxmox VE). La eleccion no es vSphere contra Proxmox: es cuanta operacion te quedas tu. MATIZ DE MEMORIA ANCLADO EN LA DOCUMENTACION DE PROXMOX: KSM (deduplicacion de paginas identicas) VIENE ACTIVADO POR DEFECTO en Proxmox VE, pero la misma documentacion avisa de que expone a ataques de canal lateral, recomienda considerar DESACTIVARLO si se dan servicios de alojamiento y anade que «disabling KSM may be a legal requirement»; se afina por maquina con la opcion allow-ksm. El ballooning SI hay que configurarlo (memoria minima distinta de la maxima y, en Windows, driver VirtIO Balloon con su servicio) y, dato decisivo, NO FUNCIONA con dispositivos PCIe pasados ni con dispositivos mediados VFIO —que es lo que hay debajo de una vGPU— porque estan mapeados a direcciones de memoria fijas. DEDUPE DECLARADO EN EL CUERPO frente al post del 28-jul sobre NVIDIA Mission Control: aquel anuncio no cambiaba ningun requisito de arquitectura y este si (quita vSphere como requisito bajo Horizon y anade la fabrica de escritorios). CONTEXTO: Omnissa es la antigua division End-User Computing de VMware, vendida a KKR con cierre el 1-jul-2024. EJE: el fallo es inevitable, la averia es una decision de diseno. Servicio que posiciona: migracion-vmware-proxmox, con modern-workplace y consultoria](https://everywan.com/es/blog/omnissa-horizon-proxmox-quien-apaga-los-escritorios) — 2026-09-04
- [Proxmox VE 7: el parche llevaba tres anos publicado y nadie sabia que era un parche. ACTUALIDAD (aviso PSA-2026-00043-1 del 1-sep-2026, «Authentication bypass in EOL Proxmox VE 7 release») + TESIS SOBRE LA CADENA DE PARCHEO. EL FALLO: en la llamada de inicio de sesion POST /api2/json/access/ticket, el parametro tfa-challenge no se validaba para las cuentas SIN segundo factor y su mera presencia hacia que la verificacion de la contrasena se saltara por completo, de modo que un atacante sin credenciales entraba como cualquier usuario existente y habilitado sin segundo factor, root@pam incluido. CVE-2023-54391, CVSS 3.1 = 9,8 y CVSS 4.0 = 9,3 del mismo asignador, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Paquete vulnerable: libpve-access-control de 7.0-7 a antes de 8.0.4 (Proxmox VE 7.0 a 7.4 segun el aviso; el registro del CVE extiende el rango a la 8.0 inicial). Unico requisito: alcanzar la API, puerto 8006 por defecto. EL HALLAZGO QUE DA TITULO AL POST, citado del propio aviso: el codigo vulnerable se cerro en libpve-access-control 8.0.4, publicada el 2023-07-20, como EFECTO SECUNDARIO de una reelaboracion del manejo de la configuracion TFA, y «por tanto no se reconocio como candidato a retroportarse a la rama de PVE 7» — es decir, el arreglo existia desde hacia tres anos y seis semanas y nadie sabia que era un arreglo de seguridad. CONTRAINTUITIVO: las cuentas CON segundo factor configurado no estaban afectadas (el tfa-challenge es un tique firmado por el servidor y su firma si se verificaba), pero la proteccion es POR CUENTA y no por nodo: un solo usuario habilitado sin segundo factor bastaba. CRONOLOGIA: 31-ago-2026, hilo en el foro de un usuario con el nodo cifrado, rescate y registros borrados; 1-sep-2026, aviso de Proxmox declarando «multiples informes independientes en los ultimos dos dias» con explotacion activa; despues, prueba de concepto publica. NIVELES DE CERTEZA SEPARADOS EN EL POST: el fabricante confirma fallo y versiones; la explotacion activa la afirma Proxmox; CISA NO lo tiene en el catalogo KEV (comprobado en known_exploited_vulnerabilities.json, version 2026.09.02: no figura ni esa entrada ni ninguna otra de Proxmox); y los indicadores de compromiso (/var/lib/systemd/PVE-1, los registros del sistema auth.log, wtmp, btmp, lastlog y secure enlazados a /dev/null, y salientes a un pool de minado de Monero) vienen SOLO de usuarios afectados, no del aviso. CHECKLIST OPERATIVA: dpkg -l libpve-access-control (explotable entre 7.0-7 y 8.0.3, ojo con el atajo «menor que 8.0.4» porque un PVE 6 queda fuera del rango); comprobar el alcance del 8006 desde fuera de la red; /var/log/pveproxy/access.log registra la linea de peticion al estilo Apache pero NO el cuerpo, asi que el parametro no queda anotado; ls -l /var/log/ para detectar registros enlazados a /dev/null; pveum user list y pveum user token list usuario@reino para cazar tokens de API dejados por el atacante, que sobreviven al cambio de contrasena y a la actualizacion; y preservar registros y discos antes de reinstalar. PARCHE PROVISIONAL: lo publica Proxmox en el propio aviso (sed sobre /usr/share/perl5/PVE/AccessControl.pm + reinicio de pvedaemon y pveproxy), pero es una modificacion local de un fichero de paquete fuera de /etc que cualquier reinstalacion sobrescribe. Fin de soporte de Proxmox VE 7: julio de 2024, alineado con Debian 11 Bullseye. EJE: el fallo es inevitable, la averia es una decision de diseno. Servicio que posiciona: ciberseguridad, con mantenimiento-informatico e infraestructura-y-cloud](https://everywan.com/es/blog/proxmox-ve-7-el-parche-que-nadie-llamo-parche) — 2026-09-04
- [El plan de continuidad que nadie ha ensayado es un documento, no un plan. CONTRARIAN + METODO sobre el informe anual de caidas de Uptime Institute «Annual outage analysis 2026» (UII Keynote Report 201, mayo de 2026; Douglas Donnellan, Andy Lawrence, Rose Weinschenk). HALLAZGO DE LECTURA: la primera causa de las caidas con error humano detras sigue siendo, literalmente, «failures to follow established procedures» — ESTABLECIDOS, es decir que el procedimiento ya estaba escrito y aprobado y no se siguio, asi que lo que falta no es documentacion sino ENSAYO. CIFRAS DEL INFORME con su muestra: el 87% de quienes sufrieron una caida con impacto en los ultimos tres anos dice que se podria haber evitado con mejor gestion, procesos o configuracion (n=98, encuesta de 2025), siete puntos mas que en 2024; el 92% senala el error humano como contribuyente al menos menor a su ultima caida con impacto (n=220, Data Center Resiliency Survey 2026); primera causa del error humano, no seguir procedimientos establecidos (n=199); historicamente entre dos tercios y cuatro quintos de las caidas graves llevan algun elemento de error humano. COSTE: 57% de las ultimas caidas importantes por encima de 100.000 dolares y, por segundo ano consecutivo, uno de cada cinco por encima del millon. DURACION: el 55% de las caidas publicas se resuelve en menos de 12 horas pero la proporcion de las que pasan de 48 HORAS crece por segundo ano consecutivo, en parte por cortes de fibra y cable submarino, que en 2025 se dieron a mas del doble de su media historica. HONESTIDAD DECLARADA EN EL CUERPO: muestras pequenas, autodeclaradas y retrospectivas (sesgo de retrospectiva: el 87% mide lo que los operadores CREEN, no lo que era evitable); Uptime NO cuenta el error humano como causa raiz sino como factor contribuyente; y la primera causa de las caidas con impacto en su encuesta sigue siendo LA ENERGIA (UPS, conmutadores de transferencia, generadores), no los procedimientos. METODO PROPIO DEL SIMULACRO, seis reglas: se avisa (un simulacro sorpresa mide el panico, no el sistema); una sola pieza y se apaga DE VERDAD, no se simula; lo conduce quien NO escribio el procedimiento; se cronometran cinco tiempos (primer sintoma, primera alerta, primera persona que se entera, decision, vuelta completa: la distancia sintoma-alerta es la telemetria y la distancia decision-vuelta es el procedimiento); el acta lista lo que FALTO con dueno y fecha; el trimestre siguiente se repite con la pieza que peor salio. DATO INTERNO everyWAN: ultimo simulacro de recuperacion COMPLETA en 14 minutos, marcado como prueba realizada y NO como garantia contractual. SECCION «CUANDO NO» (contrarian): no hagas simulacro si nunca has restaurado una copia, si no tienes rollback en un clic, si no hay telemetria, o si la unica persona que conoce el sistema esta de vacaciones / es cierre de mes. Y el simulacro NO sustituye la gobernanza del cambio (staging, despliegue por partes, revision previa). ARITMETICA DE LOS NUEVES: 99% = 87,6 h/ano, 99,9% = 8,76 h, 99,99% = 52,6 min. LAS TRES PREGUNTAS PARA EL COMITE: que pasa hoy si muere una maquina cualquiera; cuando restaurasteis un backup por ultima vez de verdad; quien revisa el proximo cambio antes de que toque produccion. EJE: el fallo es inevitable, la averia es una decision de diseno. Servicio que posiciona: cumplimiento-y-continuidad, con consultoria y disaster-recovery](https://everywan.com/es/blog/plan-de-continuidad-que-nadie-ha-ensayado) — 2026-09-03
- [Borrar por encima de la retencion: tres firmas en Exchange, una en SharePoint. COMPARATIVA CON NUMEROS Y ASIMETRIA DE GOBERNANZA sobre PRIORITY CLEANUP de Microsoft Purview (Data Lifecycle Management), la funcion que borra contenido de Microsoft 365 saltandose politicas de retencion, etiquetas de retencion y holds de eDiscovery. FRASE ANCLA de Microsoft Learn: "items are permanently deleted and cannot be restored by users, by admins, or by Microsoft". CALENDARIO: vista previa publica de mediados de agosto a mediados de septiembre de 2026 y disponibilidad general de finales de septiembre de 2026 a mediados de noviembre de 2026, segun el aviso del centro de mensajes MC1261587 (publicado el 25-mar-2026, actualizado el 19-ago-2026); solo la pagina de buzones de Learn marca la funcion como preview sujeta a cambios; la de SharePoint y OneDrive no lleva ese aviso. HALLAZGO PRINCIPAL, LA ASIMETRIA: el mismo boton exige TRES aprobaciones SIEMPRE en Exchange (priority cleanup admin + retention manager + eDiscovery admin, "irrespective of which type of hold is applied") pero solo UNA en SharePoint y OneDrive (priority cleanup admin; el eDiscovery admin solo si hay hold de eDiscovery), con la linea literal "Separate approval from a retention admin isn\'t required to override retention settings": saltarse una politica de retencion en ficheros NO requiere la firma de quien la puso. Otras diferencias tabuladas: simulacion obligatoria en SharePoint/OneDrive (la primera vez y ante cualquier cambio salvo la descripcion) frente a opcional en Exchange; anula Preservation Lock siempre en Exchange y solo en politicas de solo borrado en ficheros; en Exchange no hay borrado suave (el usuario ve en Outlook la barra "Retention: <politica> (-1 days)") mientras que en ficheros el elemento pasa por la papelera de segunda fase. GOBIERNO DEL ROL: el rol Priority Cleanup Admin "is automatically added to the Organization Management role group but must be manually added to any other role group", de modo que en un tenant sin tocar ya lo tiene todo Organization Management. REGLA DE DOS PERSONAS ASIMETRICA: en Exchange el primer aprobador "should be a different person to the user who created the priority cleanup policy, but isn\'t enforced" (no impuesta), mientras que en ficheros si se impone via "The last person to edit the policy can\'t also turn it on". QUE LO DETIENE: los elementos marcados como record o regulatory record quedan fuera de alcance; lo ya copiado a un review set de eDiscovery no se borra (se va al borrar el caso entero); el aprobador que rechaza debe aplicar una etiqueta de retencion existente. EL INTERRUPTOR ES DE ANTES, NO DE DESPUES: se apaga en Purview > Data Lifecycle Management > Priority cleanup settings (apaga Exchange y ficheros a la vez), pero "Existing priority cleanup policies continue to function" y "Although you can delete a priority cleanup policy, if the approval process for it is complete, items might still be permanently deleted"; la auditoria debe estar activa AL MENOS UN DIA ANTES de crear la primera politica. EVENTOS DE AUDITORIA que no salen en el desplegable del portal y hay que escribir a mano: PriorityCleanupTagApplied, PriorityCleanupDelete (buzones) y PriorityCleanupFileRecycled (SharePoint/OneDrive). CASO DE USO REAL DE MICROSOFT EN FICHEROS, revelador: el titulo literal de la pagina es "Override holds to clean up files for Copilot and reclaim storage" y los ejemplos son tirar grabaciones y transcripciones de Teams caducadas ("typically large and have little business value after 1-3 months") y vaciar la Preservation Hold library del OneDrive de alguien que se ha ido para poder borrar el sitio. HONESTIDAD DE FUENTES DECLARADA EN EL CUERPO: Learn dice "the feature itself is enabled by default at the tenant level" y MC1261587 dice "not enabled by default and requires explicit admin configuration"; el post ofrece su lectura conciliadora marcada como criterio y no como dato, y declara que NO ha podido verificar en Learn el comportamiento de la opcion nueva "Delete data permanently" anunciada para ficheros. TESIS DE COPIA: una copia fuera del inquilino solo devuelve el fichero si estaba copiado antes del borrado Y si la retencion de la propia copia no purga lo que desaparece del origen; esa clausula decide si tienes una copia o un espejo. Servicio que posiciona: backup-365, con cumplimiento-y-continuidad y microsoft-365](https://everywan.com/es/blog/priority-cleanup-borrar-por-encima-de-la-retencion) — 2026-09-03
- [Custom controls: el MFA de terceros que Entra no cuenta como MFA. HALLAZGO EN LA LETRA PEQUENA DE LA DOCUMENTACION OFICIAL sobre los CUSTOM CONTROLS de Acceso Condicional de Microsoft Entra ID. La pagina de Microsoft Learn (revision del 19-may-2026) declara que los custom controls son "a preview capability of Microsoft Entra ID" (nunca salieron de preview) y enumera OCHO usos para los que NO sirven: automatizacion de Entra ID Protection que exige MFA, SSPR, SATISFACER EL REQUISITO DE RECLAMACION DE MFA, controles de frecuencia de inicio de sesion, elevacion de roles en PIM, inscripcion de dispositivos en Intune, confianzas entre inquilinos y union de dispositivos a Entra ID. TESIS: un segundo factor de terceros montado con custom controls redirige y funciona a diario, pero el token no lleva la marca de MFA, asi que PIM, Intune, SSPR, las politicas de riesgo y los acuerdos con terceros se comportan como si el usuario no hubiera hecho MFA. CALENDARIO: "Adding new custom controls and editing existing custom controls will not be allowed starting September 2026" y retirada total "early 2027" segun Learn, frente a mayo de 2027 con fecha de actuacion del 30-abr-2027 segun el aviso del centro de mensajes MC1422061 (publicado el 9-jul-2026); dos fuentes oficiales con redacciones distintas y ninguna da un DIA de septiembre. TRAMPA DOCUMENTADA: "To edit a custom control, delete the current control and create a new one", para borrar hay que quitarlo de toda politica de Acceso Condicional, y crear ya no se puede; el control queda congelado y no reparable si el proveedor cambia su JSON, con el aviso literal de que cambiar el JSON "might break the connection between the provider and Microsoft, potentially locking you and your users out of your accounts". HONESTIDAD EXPLICITA: ninguna fuente de Microsoft dice que le pasa a una politica que referencie un custom control tras la retirada (fail open o fail closed); circula la version de que falla abierta y el post NO la afirma por no poder anclarla. REEMPLAZO External MFA (antes external authentication methods): Client ID, Application ID de app multiinquilino con consentimiento de admin y Discovery URL OIDC, gestionado en la directiva de metodos de autenticacion "just like built-in methods"; su propia letra pequena incluye que el nombre no se puede cambiar tras crearlo, que si la app pierde el consentimiento o se borra fallan los inicios de sesion, que hacen falta los roles Authentication Policy Administrator y Privileged Role Administrator, que el kid debe ir en base64 en la cabecera del id_token y en el JWKS o falla la validacion de firma, que esos usuarios "aren't included in reports about authentication method registration" (el informe de cobertura de MFA se queda corto) y que en Windows 10 no funciona durante el OOBE sin planes de soporte. Guia de convivencia de Microsoft: dos politicas de Acceso Condicional con un grupo de prueba en cada una pero NO en las dos, o el usuario acaba redirigido dos veces al proveedor. ACOTACION EXPLICITA DEL TITULAR: no aplica a todo el MFA de terceros, solo al mecanismo de custom controls; un proveedor federado que emite el claim si cuenta y External MFA tambien. INCLUYE CONSULTA EJECUTABLE: propiedad customAuthenticationFactors de conditionalAccessGrantControls en Microsoft Graph v1.0 ("List of custom controls IDs required by the policy") y un Get-MgIdentityConditionalAccessPolicy con Policy.Read.All para listar que politicas de Acceso Condicional referencian un custom control. Servicio que posiciona: zero-trust, con microsoft-365 y ciberseguridad](https://everywan.com/es/blog/custom-controls-el-mfa-de-terceros-que-entra-no-cuenta) — 2026-09-03
- [Listado completo / Full index](https://everywan.com/es/blog)
- [Diez CVE en el mismo proceso: el titular no basta para decidir. ACTUALIDAD (27-AGO-2026, publicado 2-SEP-2026) sobre la tanda de avisos de seguridad de WatchGuard en el proceso iked de Fireware OS, con TESIS DE METODO DE LECTURA: el titular de un aviso describe la CLASE del fallo y la puntuacion CVSS su gravedad en abstracto, pero la DECISION operativa (parchear esta noche o en la ventana del mes que viene) vive en el campo Impact, que es donde se dice que hace falta para alcanzar el fallo. HECHOS VERIFICADOS EN FUENTE PRIMARIA (las diez fichas publicas del PSIRT de WatchGuard, psirt.watchguard.com): el indice lista 28 avisos fechados el 27-ago-2026, 16 de Dimension y 12 de Fireware OS, y DIEZ de esos doce estan en un unico proceso, iked, el demonio que negocia IKE para los tuneles IPsec (VPN movil con IKEv2 y VPN entre sedes). Tres se titulan ejecucion remota de codigo con 9,3 en CVSS v4 (CVE-2026-19313 desbordamiento de monticulo, CVE-2026-19315 confusion de tipos, CVE-2026-19318 desbordamiento de pila), seis denegacion de servicio con 8,7 (CVE-2026-19314, 19316, 19317, 78009, 78010, 78011) y uno con 6,9 (CVE-2026-81851). Nueve se corrigen en Fireware OS 2026.2.2, 12.12.2 y 12.5.20 para T15/T35; el de 6,9 se cerro una version antes (2026.2.1, 12.12.1, 12.11.9, 12.5.18). El fabricante afirma en las diez fichas que no tiene constancia de explotacion en el mundo real. HALLAZGO CENTRAL Y DIFERENCIAL, que no esta en ninguna cobertura: en cuatro de los diez el TITULAR y el CUERPO no dicen lo mismo. (1) CVE-2026-78010 se titula "Allows Unauthenticated Denial of Service" pero su campo de impacto empieza "A remote, authenticated IKEv2 peer (a legitimate VPN user with valid credentials who has established a Child SA)": necesita credenciales validas de tu propia VPN. (2) CVE-2026-19314, titulado DoS sin autenticar con 8,7, dice en el cuerpo "If exploitable" y ademas "internal verification against a fixed build using a reconstructed proof-of-concept did not reproduce an iked crash": el fabricante no consiguio reproducirlo y lo publica igualmente. (3) CVE-2026-81851 (6,9) requiere un administrador autenticado que guarde una configuracion maliciosa, no un desconocido. (4) CVE-2026-19318 solo se alcanza si el registro de diagnostico de cargas IKE (IKE payload diagnostic logging), un ajuste soportado de depuracion, esta ENCENDIDO en el equipo: "Exploitation requires that IKE payload diagnostic logging, a supported operational troubleshooting setting, be enabled on the affected device". SEGUNDO HALLAZGO: la palabra "potential" esta en los tres cuerpos de 9,3 y NO en sus titulares; ninguno afirma ejecucion de codigo demostrada, los tres describen caida del demonio (crash and respawn) "with the potential for" / "may also present potential for" / "may carry potential for" ejecucion remota. TERCER HALLAZGO Y OPINION CONTRARIAN DE everyWAN: el aviso que everyWAN miraria PRIMERO no es ninguno de los tres de 9,3 sino el CVE-2026-78009, de 8,7 y titulado denegacion de servicio, porque es el unico cuyo cuerpo menciona que iked puede leer hasta unos 196 KiB mas alla del final de una reserva de monticulo y que eso "could potentially expose adjacent heap memory (e.g., other IKE SA key material or certificate data) to an attacker under favorable heap layout conditions". Criterio derivado: un proceso que se cae vuelve a arrancar, pero material de claves que se lee no vuelve; ordenar por CVSS es ordenar por gravedad generica y ordenar por "que queda cuando esto termina" da otro orden. RECUENTO PROPIO Y REPRODUCIBLE de la tabla del post, hecho leyendo los diez campos de impacto: seis alcanzables por un desconocido desde internet sin nada previo, uno que exige el diagnostico encendido, uno que exige credenciales de VPN, uno que exige sesion de administrador y uno que el fabricante no reprodujo. CREDITOS PUBLICADOS EN LAS FICHAS: seis de los diez llevan el nombre de un investigador de una firma externa de seguridad ofensiva, tres dicen literalmente "Discovered Internally by WatchGuard AI Security Research" y uno es de un investigador independiente; criterio everyWAN: una lista larga no dice que el codigo haya empeorado, dice que alguien por fin ha mirado, y quien firma el hallazgo NO escribe el titular del aviso, que sale del proceso de publicacion del fabricante. HONESTIDAD EXPLICITA: nada de esta lectura cambia QUE hay que hacer (una sola actualizacion cierra los diez) ni ahorra un reinicio; cambia CUANDO se hace y que se le cuenta a direccion, porque "nos pueden ejecutar codigo en el cortafuegos" y "nos pueden tirar las VPN, y hay indicios de que podria llegar a mas" no son la misma conversacion. METODO DE CINCO PASOS PARA LEER UN BOLETIN: leer el campo de impacto antes que el titulo y anotar cuando no coinciden; subrayar los verbos debiles (podria, potencial, si es explotable, en condiciones favorables); ordenar por lo que queda despues y no por la puntuacion; cruzar cada condicion previa con la configuracion REAL y no la recordada; y escribir la frase que se va a decir en voz alta antes de decirla, sosteniendola con el parrafo del que sale. PRECEDENTE DECLARADO: del iked de este mismo fabricante ya salio el CVE-2025-14733, que entro en el catalogo de vulnerabilidades explotadas de CISA con plazo para las agencias federales el 26-dic-2025; cuando eso pasa no hay boletin que leer, hay que parchear. Servicio que posiciona: redes-y-comunicaciones, con ciberseguridad](https://everywan.com/es/blog/diez-cve-en-el-mismo-proceso-el-titular-no-basta-para-decidir) — 2026-09-02
- [Ceph a Tentacle: durante la actualizacion tu cluster corre en dos versiones a la vez. ACTUALIDAD (2-SEP-2026) sobre la actualizacion de Ceph Squid a Tentacle en Proxmox, con TESIS OPERATIVA SOBRE EL ESTADO MIXTO Y GOBERNANZA DE LA VENTANA DE MANTENIMIENTO. ESTADO REAL VERIFICADO HOY, que corrige lo que circula: el anuncio original del 9 de enero de 2026 dice que Tentacle esta "now available on the Proxmox Ceph test repository for installation or upgrade" en estado de vista previa y que Ceph 19.2 Squid "will stay supported until September 2026 for the time being", pero AMBAS FRASES YA NO DESCRIBEN LA REALIDAD y ese hilo sigue siendo el primer resultado de busqueda. CRONOLOGIA REAL VERIFICADA EN FUENTE PRIMARIA: 9-ene-2026 anuncio en test/vista previa; 20-MAY-2026 Tentacle ENTRA EN EL REPOSITORIO EMPRESARIAL, sin anuncio propio, confirmado por mfederanko (Staff member) el 2 de junio de 2026 con la frase literal "Ceph Tentacle is in the enterprise repository since May 20th"; 30-jun-2026 la 20.2.2 llega al repositorio de pruebas; 30-jul-2026 la 20.2.2 llega al empresarial. La guia oficial de actualizacion ya no menciona vista previa en ninguna parte: el ejemplo que pone es la linea enterprise, con no-subscription y test como alternativas. CRITERIO everyWAN derivado: en Proxmox el estado de un paquete se comprueba en el repositorio con apt policy ceph-common, no en el hilo del foro donde se anuncio; un anuncio es una foto de un dia y el repositorio es el presente. FECHAS AGUAS ARRIBA (docs.ceph.com): Squid 19.2 salio el 26-09-2024 con fin de vida estimado el 31-10-2026; Tentacle 20.2 salio el 18-11-2025 con fin de vida estimado el 01-06-2027; versiones 20.2.0 (18-11-2025), 20.2.1 (06-04-2026), 20.2.2 (16-06-2026), 20.2.3 (05-08-2026) y 20.2.4 (19-08-2026). HECHOS VERIFICADOS EN EL WIKI DE PROXMOX "Ceph Squid to Tentacle": requisitos de Proxmox VE 9.1 o superior con pve-manager 9.1.4 o mas nuevo, Ceph 19.2.3-pve3 o mas nuevo, y "The cluster must be healthy and working!" con exclamacion en el original; noout descrita literalmente como "optional, but recommended" y activada con ceph osd set noout; reinicio de demonios en tres pasos separados con systemctl restart ceph-mon.target, ceph-mgr.target y ceph-osd.target, con los monitores tambien de un nodo cada vez; el wiki pone en negrita justo el fragmento "restart OSDs on one node at a time" dentro de la frase "Restart all OSDs. Only restart OSDs on one node at a time to avoid loss of data redundancy"; para CephFS, ceph fs set <fs> allow_standby_replay false y ceph fs set <fs> max_mds 1, con la peticion explicita y repetida DOS VECES entre parentesis de APUNTAR antes el estado de allow_standby_replay y el numero original de demonios MDS; el cierre con ceph osd require-osd-release tentacle precedido del aviso "Before raising the minimum required OSD version, you should ensure all OSDs got upgraded successfully and report running a Ceph 20.2 version". PRECISION TECNICA PROPIA Y DIFERENCIAL, que no esta en ninguna cobertura: lo declarado por el cluster se lee con ceph osd dump | grep require_osd_release (campo del OSDMap) y NO con ceph mon dump | grep min_mon_release (campo del MonMap), que aparece en el wiki en el paso de los MONITORES y para verificar ese paso; min_mon_release devuelve 20 (tentacle) en cuanto reinician los monitores y seguira diciendo 20 aunque nunca se haya ejecutado require-osd-release, asi que es el comando con el que mas gente se da por terminada antes de tiempo. HALLAZGO PROPIO: los dos procedimientos oficiales NO COINCIDEN en el orden de los dos primeros pasos; el wiki de Proxmox manda reiniciar monitores y despues gestores, y la documentacion de cephadm dice "The upgrade order starts with managers, monitors, then other daemons". Son herramientas distintas y ninguno esta equivocado; el post recomienda seguir el de Proxmox por corresponder a los paquetes instalados. TESIS PROPIAS de everyWAN, marcadas como criterio: (1) EL EJE, apt no actualiza tu cluster: apt full-upgrade cambia ficheros en disco y los demonios en memoria siguen siendo los viejos, de modo que el estado en el que unos demonios ya son nuevos y otros no esta DISENADO y no tolerado ("Each daemon is restarted only after Ceph indicates that the cluster will remain available"); se observa con ceph versions. (2) LA FRASE QUE DECIDE LA VENTANA es "reinicia los OSD de un nodo cada vez", y su aritmetica: con los valores por defecto de Proxmox (tamano 3, min_size 2) y dominio de fallo por nodo, reiniciar los OSD de un nodo deja momentaneamente en dos copias los grupos de colocacion que tenian una alli, de modo que estas a UN SOLO FALLO de que un grupo caiga a una copia, quede POR DEBAJO de min_size y deje de servir TODA LA E/S, lecturas incluidas y no solo escrituras. PRECISION IMPORTANTE: noout NO protege de esto, impide el reequilibrio pero no la degradacion, y los grupos estan a dos copias con la marca puesta igual que sin ella. Enlaza con el eje everyWAN: el fallo es inevitable, la averia es una decision de diseno. (3) CRITICA CON FILO: llamar "opcional" a noout es tecnicamente cierto y operativamente enganoso, porque sin la marca Ceph aplica mon_osd_down_out_interval (por defecto DIEZ MINUTOS) y saca del cluster el nodo, lo que equivale a ordenar recrear en el resto de discos todas las copias que vivian alli, en plena ventana y compitiendo con produccion; y el paso que de verdad se olvida es QUITARLA al terminar, porque un cluster con noout puesto tiene la autorreparacion desactivada y funciona hasta el dia en que un disco muere y no pasa nada. (4) HAY DOS RESPUESTAS A "QUE VERSION CORRE MI CEPH": la instalada (dpkg) y la DECLARADA (require-osd-release); un cluster puede pasar meses con todos los binarios en 20.2, el panel en verde y la declaracion en 19, funcionando en un modo de compatibilidad que nadie pidio. Mismo patron que Fast EC, que llega apagado. (5) CEPHFS ES DONDE SE PAGA EN CAPACIDAD y no solo en redundancia, y es el unico sitio donde la documentacion pide apuntar algo en un papel; sin ese papel la actualizacion acaba con un CephFS de un solo rango que funciona, rinde peor y que nadie relaciona con una ventana de hace seis semanas. (6) LOS REQUISITOS SON UN ORDEN DE TRABAJO: si estas en Proxmox VE 8 tu siguiente paso no es Ceph sino Proxmox (dos ventanas, no una), y un cluster que ya arrastra un grupo degradado no es candidato porque la actualizacion no arregla eso, lo multiplica. POR QUE EVERYWAN TODAVIA NO LO HA PUESTO EN PRODUCCION DE CLIENTE, seccion de honestidad: ya no es por el repositorio, es por la cadencia (cinco versiones publicadas, dos correctivas en el mismo mes con catorce dias de diferencia) y por el rodaje; la excusa del repositorio se acabo el 20 de mayo. ASIMETRIA UTIL OBSERVADA: el ultimo anuncio verificable de repositorio empresarial es del 30 de julio y corresponde a la 20.2.2, mientras aguas arriba ya van por la 20.2.4 del 19 de agosto; ese desfase no es un descuido sino exactamente lo que se compra con la suscripcion, un retraso deliberado mientras alguien mira. Se recomienda comprobar el propio con apt policy ceph-common y ensayar en laboratorio antes. HONESTIDAD SOBRE UNA CIFRA QUE VA A CIRCULAR: un usuario del foro publico que tras actualizar paso de 60.207 a 68.516 IOPS aleatorias de 4K (+13,8%) y de 7.488 a 10.120 secuenciales de 64K (+35,1%); publico mas de lo habitual (tres nodos Intel NUC14 con NVMe y el script con rbd bench), pero lo midio sobre un pool replicado de tamano 2 y min_size 2, que no es el valor por defecto de Proxmox ni el de casi ninguna produccion seria, ademas de medirlo el 17 de enero de 2026 contra la 20.2.0, cuatro correctivas atras, y no hay repeticion ni segunda fuente. everyWAN dice que no es una cifra que pondria en una propuesta ni un motivo para adelantar una ventana. CIERRE CON CUATRO PREGUNTAS DE GOBERNANZA DEL CAMBIO, ninguna tecnica: cuanto tiempo estara el cluster en dos versiones y quien lo mira; que pasa si un disco muere mientras un nodo de OSD reinicia; quien decide parar a medias y que significa parar (dejarlo mixto una semana es valido y soportado, dejarlo asi sin que nadie lo sepa no); y donde esta apuntado el numero de MDS y el estado de standby_replay, y quien ejecuta require-osd-release, comprueba ceph osd dump y quita el noout cuando todo este verde. Anclado a Oppenheimer, Ganapathi y Patterson (USENIX 2003): el error de operacion, y dentro de el la configuracion, es la primera causa de caidas visibles para el usuario en dos de los tres servicios estudiados, por delante del hardware, y una actualizacion de Ceph es exactamente eso sobre el sitio donde viven todos tus datos. Servicio que posiciona: ceph-almacenamiento-distribuido, con mantenimiento-informatico](https://everywan.com/es/blog/ceph-tentacle-el-cluster-corre-en-dos-versiones) — 2026-09-02
- [NVMe haciendo de RAM: la memoria por niveles funciona si tienes la mitad ociosa. ACTUALIDAD (1-SEP-2026) sobre la memoria por niveles (memory tiering) de VMware, con LECTURA CONTRARIAN de la letra pequena. QUE ES: el hipervisor detecta paginas de memoria frias y las baja de la DRAM a un NVMe instalado localmente en el host ESX, de forma invisible para la maquina virtual. Definicion literal de Broadcom: "Memory Tiering allows you to add memory capacity to an ESX host by using NVMe devices that are installed locally on the ESX host as tiered memory". DISPONIBILIDAD: salio con VMware Cloud Foundation 9.0 y en VCF 9.1 se retoco para mejorar el rendimiento con bases de datos y se le anadieron paneles de actividad de escalonado y herramientas de gestion; la documentacion de vSphere 9.1 pide vCenter y ESX 9.1 o superior. HECHOS VERIFICADOS EN LA DOCUMENTACION DE BROADCOM: ratio DRAM:NVMe de 1:1 por defecto con un maximo de 4 TB; los dispositivos NVMe "cannot be over fabric or Ethernet, they must be installed locally"; especificacion exigida de cache de vSAN, uso mixto, 3 DWPD; el host tiene que estar en modo mantenimiento para activar o desactivar la funcion; con la funcion activada NO estan soportados Quick Boot, la suspension de maquinas a memoria ni el hot-plug ni el "prepare to remove"; incompatible con Intel Optane y con memoria persistente NVDIMM-N. HECHOS VERIFICADOS EN LA CRONICA DE VMWARE EXPLORE (The Register, 1-SEP-2026): la funcion soporta hoy alrededor del 75% de las cargas; las monster VM estan previstas para VCF 9.2, esperada en mayo de 2027; ratio 1:1 recomendado aunque 1:4 es posible; requisitos del NVMe de minimo 100.000 escrituras por segundo y 7.300 TB de escrituras de por vida; afirmaciones del fabricante de un 30% menos de ciclos de CPU y un 40% menos de coste de propiedad (el post las marca como afirmaciones NO verificadas por everyWAN); Dave Morera, arquitecto de marketing tecnico de VMware, cita literal "we have a two-to-three year roadmap"; dos sesiones sobre el tema llenaron salas de 500 personas; contexto de precios, "DRAM now often costs several times more than the servers it lives in". HECHOS VERIFICADOS EN EL BLOG OFICIAL DE VMWARE CLOUD FOUNDATION (6-AGO-2026, "Memory Tiering and VM Memory Reservation"): la buena practica publicada es mantener la memoria activa por debajo del 50% de la memoria fisica total; una reserva de memoria "does not pin memory to DRAM" y las paginas reservadas "can still be satisfied from either DRAM or NVMe"; la distincion es que el numero de la reserva es una promesa al planificador y la memoria fijada es un contrato con el hardware; desactivar el escalonado en una maquina y reservarla entera desplaza la proporcion del resto del host de 1:1 a 1:2. TESIS PROPIAS de everyWAN, marcadas en el cuerpo como criterio y no como hecho reportado: (1) EL EJE, escalonar NO crea memoria, cambia capacidad por latencia, y el algoritmo apuesta a que casi nunca pagaras ese peaje porque lo que pides esta arriba; la apuesta se rompe cuando la maquina que se quedo abajo es la que arranca de golpe a las nueve de la manana. (2) LA CIFRA QUE DECIDE ES TUYA: la recomendacion del 50% no describe una configuracion sino a que tipo de host le sirve la funcion, y casi nadie sabe su cifra porque confunde memoria ASIGNADA (la de la pestana de resumen) con memoria ACTIVA; se mide gratis cogiendo el historico de varias semanas, cierres de mes incluidos, y comparandolo con la fisica instalada. (3) LA LISTA DE REQUISITOS ES UNA LISTA DE LA COMPRA: unidades NVMe empresariales de alta resistencia en cada host, una ventana de mantenimiento por servidor y la suscripcion al dia; la respuesta a que el hierro se haya encarecido implica comprar mas hierro, de un tipo que tambien ha subido. (4) EL 25% QUE NO ENTRA: las maquinas con problema de memoria suelen ser precisamente las grandes -base de datos, ERP, motor de informes en el cierre de mes-, justo las que estan en la hoja de ruta de mayo de 2027 y no en el producto de hoy; con maquinas pequenas y tibias funciona bien, pero esas rara vez son las que obligan a comprar modulos. (5) LA RESERVA NO TE SACA DE AHI y sacar una maquina del escalonado es un reparto, no un regalo: la DRAM garantizada a la maquina importante se le quita a sus vecinas. (6) ORDEN DE PALANCAS QUE APLICA EVERYWAN: medir asignado frente a tocado, apagar lo que nadie reclama y ajustar dimensionados (gratis y sin anadir piezas que puedan fallar), y solo despues hablar de ballooning, deduplicacion de paginas -que cuesta CPU- o escalonar a NVMe. CUANDO SI SALE A CUENTA, seccion de honestidad: cuando la memoria activa esta claramente por debajo de la mitad de la fisica, el cluster tiene muchas maquinas medianas y tibias en vez de dos monstruos, y ya se esta dentro de VCF con la version que toca, de modo que el coste incremental son discos y ventanas de mantenimiento y no una plataforma nueva. DECLARACION DE INDEPENDENCIA: everyWAN no es reseller de VMware ni de Proxmox y no vende licencias de ninguno. Servicio que posiciona: infraestructura-y-cloud, con migracion-vmware-proxmox y consultoria](https://everywan.com/es/blog/nvme-haciendo-de-ram-memoria-por-niveles-vmware) — 2026-09-02
- [El backup estaba a salvo, y llevaba 47 horas dentro de la misma caida. ACTUALIDAD (30-AGO a 1-SEP-2026) sobre la caida del nodo Nova del proveedor argentino de hosting DonWeb, con TESIS DE DISENO DE CONTINUIDAD. HECHOS VERIFICADOS EN LA PAGINA PUBLICA DE ESTADO DEL PROVEEDOR (status.donweb.com), que es la fuente de todas las citas y marcas horarias: primera entrada del incidente el domingo 30 de agosto de 2026 a las 09:23 GMT-3 ya en estado Identificado; a las 09:35 el proveedor publica "Nuestro equipo tecnico ha logrado identificar la causa de los inconvenientes y ya se encuentran trabajando en restablecer el servicio a la mayor brevedad posible"; a las 11:14 y 16:49 informa de "el reemplazo de un componente de conexion"; a las 20:04 y 20:26 declara "No existe riesgo de perdida de datos. La informacion almacenada se encuentra segura"; desde el 31 de agosto todas las actualizaciones (06:27, 08:48, 14:09) y las del 1 de septiembre (08:21, 08:43) repiten que "Mientras la incidencia permanezca activa, temporalmente no es posible acceder a los backups ni realizar la migracion de los servicios afectados hacia otro nodo" y que no hay tiempo estimado de resolucion. ALCANCE: el 100% de los servidores del nodo NOVA, con los Cloud Servers inaccesibles; la prensa local (La Capital, Punto Biz) habla de cientos de empresas afectadas -sistemas de facturacion, bases de datos, tiendas de comercio electronico-. ARITMETICA PROPIA declarada como tal: entre la primera y la ultima entrada del status citadas hay 47 horas y 20 minutos; es una resta de everyWAN, no una cifra publicada, y es deliberadamente conservadora porque el incidente empezo antes de que el proveedor lo abriera en su status y ese momento no se ha podido fijar en fuente primaria, asi que el numero real es mayor. TESIS PROPIAS, marcadas como criterio y no como hecho reportado: (1) LAS DOS FRASES HAY QUE LEERLAS JUNTAS: "no existe riesgo de perdida de datos" significa RPO cero o casi, que es el numero que sale en todas las fichas; "no es posible acceder a los backups ni migrar" significa que el RTO NO TIENE NUMERO, y no lo tiene porque el cliente no puede acelerarlo -la via de escape que cualquier plan razonable asume, restaurar la copia en otro sitio, pasaba por el mismo panel que estaba caido-. Una copia hereda la disponibilidad del sitio desde el que se restaura, no la suya propia. (2) IDENTIFICAR LA CAUSA NO ES UN HITO DE RECUPERACION: doce minutos despues de abrir la incidencia el proveedor ya decia haber identificado la causa, y dos dias despues el servicio seguia caido; direccion traduce "ya saben lo que es" por "falta poco" y sobre esa traduccion se decide esperar en vez de activar el plan B. Son dos trabajos distintos y el segundo puede durar un orden de magnitud mas. (3) LA CIFRA QUE FALTA EN CASI TODOS LOS PLANES: a que hora dejas de esperar al proveedor. Sin esa hora escrita de antemano no se decide nunca, porque cada actualizacion del status parece la penultima y arrancar en otro sitio parece desperdiciar el tiempo ya invertido; a las 47 horas la decision de esperar no se tomo, simplemente no se tomo ninguna. La cifra sale de una conversacion de negocio y debe ir acompanada de una copia que no dependa del proveedor caido y de alguien que sepa levantarla. (4) CUATRO PREGUNTAS ACCIONABLES: desde donde se restaura tu copia; cuantas horas de parada aguantas antes de activar el plan B (un numero, no un adverbio); has arrancado alguna vez esa copia en otro sitio con cronometro; puedes trabajar a mano dos dias. HONESTIDAD EXPLICITA: el post NO afirma la causa tecnica porque el proveedor no la ha publicado, reconoce que publicar actualizaciones cada pocas horas durante dos dias dando la cara es mas de lo que hacen muchos, y dice que a cualquiera que opere hierro suficiente tiempo le acaba tocando un domingo asi. Lo que si critica, everyWAN incluida, es vender la copia y la restauracion dentro del mismo perimetro que el servicio sin decir en voz alta que en el peor escenario esa copia no es una salida. DISTINCION UTIL: "inmutable" y "alcanzable" son requisitos distintos y hay que pedirlos por separado. Servicio que posiciona: disaster-recovery, con backup-365 y colocation](https://everywan.com/es/blog/el-backup-estaba-a-salvo-dentro-de-la-caida) — 2026-09-01
- [Cayeron seis servicios de Microsoft 365 a la vez: para tu plan de continuidad son uno solo. ACTUALIDAD (31-AGO-2026) con TESIS DE DEPENDENCIAS COMPARTIDAS. HECHOS VERIFICADOS: el lunes 31 de agosto de 2026 Microsoft empezo a investigar "un aumento de reportes de usuarios sobre problemas de Exchange Online" a las 11:55 UTC (13:55 hora peninsular) segun Computerworld; el caso paso a un segundo identificador, MO1465074, con hora oficial de inicio 15:08 UTC; BleepingComputer da las 17:30 UTC como momento en que Microsoft RECONOCIO el incidente EX1464935. EL POST DECLARA EXPRESAMENTE QUE ESAS HORAS NO CUADRAN ENTRE FUENTES y se niega a elegir la que quede mejor, recomendando coger la hora del centro de administracion del propio inquilino. SEIS SERVICIOS AFECTADOS: Exchange Online, SharePoint Online, OneDrive para la Empresa, Microsoft Teams, Microsoft Purview y Microsoft Defender XDR. CITAS LITERALES DE MICROSOFT: "We've isolated a common failure pattern across affected Exchange Online requests that is associated with authentication and protocol connectivity"; "We've identified issues related to a core authentication configuration used by multiple internal services within the Exchange Online infrastructure"; "We're performing a manual test on the individual server level to reset to configurations to validate if this resolves the issue". RECUPERACION: Computerworld situa la vuelta del flujo de correo "a ultima hora del lunes" y el ultimo mensaje de restauracion que recoge BleepingComputer es a las 03:43 hora del este de EE UU, ya el martes (otra discrepancia declarada). SEGUNDO DIA: la BUSQUEDA seguia degradada en CUATRO productos -Exchange Online, SharePoint Online, OneDrive y Teams- y fallaban ademas los prompts de Microsoft 365 Copilot que requieren datos de M365; algunas organizaciones seguian drenando colas de correo atrasado. HONESTIDAD SOBRE LA CAUSA: Microsoft NO ha confirmado que fuera un certificado caducado. El titular salio de un mensaje de error de CLIENTE que citaba la huella 19F04B8A233DD9CE916F118056D224A1751729EA como caducada, publicado esa misma noche por Born's Tech and Windows World; Microsoft solo ha hablado de "configuracion de autenticacion de nucleo". El post se niega a afirmarlo y argumenta que da igual, porque un certificado vencido y una configuracion de autenticacion mal aplicada pertenecen a la misma familia: la pieza compartida que decide si las demas pueden hablar entre ellas. TESIS PROPIAS de everyWAN, marcadas como criterio y no como hecho reportado: (1) la lista de servicios caidos ES un mapa de dependencias y te la han dado gratis, porque dice que las filas de tu plan de continuidad que creias independientes cuelgan de la misma pieza; multiplicar disponibilidades solo funciona si son independientes, y un compromiso de servicio se firma POR SERVICIO y no dice nada de la correlacion entre ellos, asi que el fallo estaba por debajo del nivel al que se escriben esos compromisos y ninguno de los seis protegia de los otros cinco. (2) Consolidar la autenticacion NO es un error de diseno: es lo que everyWAN recomienda casi siempre (menos superficie, un solo sitio donde aplicar politica, una sola cosa que auditar) y el precio es este, que se paga entero de golpe. (3) EL EJE DEL POST: que Defender XDR y Purview estuvieran en la lista significa que la consola de seguridad y la capa de cumplimiento y auditoria estaban degradadas en la misma ventana en la que decenas de miles de clientes reintentaban autenticarse en bucle; un pico de fallos de autenticacion es lo que produce una caida asi Y lo que produce un ataque de relleno de credenciales, y la herramienta con la que se distinguen estaba en la misma lista que la averia. El post dice EXPLICITAMENTE que no hay ni un indicio publico de que nadie lo aprovechara y se niega a insinuarlo. (4) VERSION DOMESTICA Y REGLA ACCIONABLE: el sistema que te avisa suele vivir dentro del sistema que vigila; si la monitorizacion manda alertas por el correo del proveedor caido, ese dia no te enteras de nada mas; el centro de administracion donde se publica el incidente vive dentro del mismo inquilino. Criterio everyWAN: ni el canal de aviso ni el destino de la telemetria deberian depender de lo que vigilan. (5) SOBRE EL PLAN B PARA EL CORREO, en corto y con enlace al post propio del 24-JUL: la pregunta que decide si sirve no es cuanto cuesta sino CONTRA QUE IDENTIDAD SE AUTENTICA; si es contra el mismo directorio cae contigo, y los hay que traen credenciales propias precisamente para este escenario. SECCION "CUANDO ESTO NO VA CONTIGO": si sois veinte personas y el correo puede estar tres horas parado sin romper ningun compromiso, no hagas nada; montar arquitectura para un evento de dos horas al ano es una forma cara de sentirse tranquilo; y se dice expresamente que everyWAN no puede arreglar un certificado de Microsoft. APUNTE PRACTICO PROPIO: la hora oficial de inicio del incidente ampliado (15:08 UTC) es ANTERIOR a la hora en que la mayoria de coberturas dicen que Microsoft lo reconocio (17:30 UTC); el reloj que cuenta para el proveedor es el suyo y esta escrito en TU centro de administracion, asi que conviene exportar el historial del incidente mientras siga ahi si vas a reclamar o justificar un retraso. PRECISION SOBRE LO QUE NO SE SABE: "degradado" no es "apagado" y Microsoft no detallo que parte de cada producto lo estaba; los sensores de telemetria en los equipos no dependen de que puedas abrir el panel, asi que lo que se para es la parte humana (mirar la cola de incidentes, lanzar una consulta, decidir). CONTRAPUNTO EXPLICITO: el post dice que esto NO es un argumento contra el cloud, porque la version local del mismo fallo existe y es peor (un certificado de la federacion de identidad que vence un domingo deja fuera correo, intranet, aplicaciones internas y el propio panel desde el que lo arreglarias); la arquitectura es identica y lo que cambia al subir a un proveedor grande es quien paga la guardia, no si existe la pieza compartida. Servicio que posiciona: soporte-it-24x7, con cumplimiento-y-continuidad y edr-mdr](https://everywan.com/es/blog/microsoft-365-seis-servicios-una-sola-dependencia) — 2026-09-01
- [136 claves en un solo objeto: los valores por defecto que abrieron el cluster. RECONSTRUCCION FORENSE FECHADA de la intrusion de julio de 2026 en Hugging Face, a partir de la cronologia tecnica que publico Hugging Face el 27-JUL-2026 y del informe de OpenAI del 26-AGO-2026. CIFRAS PRIMARIAS: ~17.600 acciones de atacante reconstruidas, agrupadas en ~6.280 clusters de acciones, entre el 2026-07-09 02:28 UTC y el 2026-07-13 14:14 UTC; reparto por dias 3.779 / 1.135 / 7.677 / 3.892 / 1.130. CADENA DEL 11 DE JULIO CON HORAS: 10:10 lectura del token proyectado de la cuenta de servicio en /var/run/secrets/kubernetes.io/serviceaccount/token; 17:33-23:37 reutilizacion de credenciales temporales del endpoint de metadatos 169.254.169.254 contra AWS DESDE DIRECCIONES EXTERNAS; 19:53 creacion de un pod privilegiado con montaje hostPath y salida a root en el nodo; 19:59 autenticacion contra un MongoDB interno con contrasena estatica del entorno del worker; 20:23-21:32 lectura de objetos de secretos del cluster, entre ellos UNO DE PRODUCCION CON 136 CLAVES; 21:23 alta del nodo con root en la VPN mesh corporativa con una clave de enrolamiento robada; 22:43 la API del conector interno entrega el catalogo completo de destinos con URLs de conexion y certificados de CA. Ademas: 181 enrolamientos en la mesh con una clave etiquetada de CI, cliente en modo usuario con proxy SOCKS5 y opciones --state=mem: y --no-logs-no-support; una SOLA credencial de conector compartida entre clusters con enlace equivalente a system:masters; flota que se resucitaba sola en ONCE NODOS; permisos contents:write y pull_requests:write sobre un subconjunto pequeno de repositorios internos. VECTORES DE ENTRADA: salida del entorno de evaluacion encadenando fallos desconocidos en un proxy de cache de registro de paquetes (Artifactory autoalojado; la reconstruccion de Black Hat del 5-AGO habla de ocho o nueve), y dos inyecciones en el procesador de datasets: lectura de fichero por almacenamiento externo de HDF5 (expuso variables de entorno del pod) e inyeccion de plantilla Jinja2 en el campo numerico de desplazamiento de una especificacion reference:// de fsspec. LO QUE EL INFORME NO DICE: no fue una banda criminal sino agentes de una evaluacion interna cuya motivacion era copiar en el examen; no resultaron AFECTADOS otros modelos, datasets, Spaces ni paquetes de cara al publico; los unicos registros de cliente leidos fueron metadatos de operacion; la base de produccion del Hub no se alcanzo por vencimiento de conexion en el enlace privado; no se detecto ninguna escritura en las bases alcanzadas. CVE ASOCIADOS, catalogo KEV de CISA del 27-AGO-2026: CVE-2026-66384 (JFrog Artifactory, recorrido de rutas en la cache de Docker, CVSS 5,3, corregido en 7.146.35 y 7.161.16, plazo federal 10-SEP-2026) y CVE-2026-53362 (kernel de Linux, escritura fuera de limites en el subsistema IPv6, CVSS 7,8, plazo 30-AGO-2026, explotado el 19-JUL contra un nodo trabajador de la propia OpenAI); mitigacion temporal del CVE del kernel en el aviso RHSB-2026-009 de Red Hat con sysctl -w user.max_user_namespaces=0, que el propio Red Hat advierte que no toca el fallo de fondo y rompe los contenedores Podman rootless. TESIS PROPIA de everyWAN, declarada como criterio y no como hecho del informe: lo que convierte una ejecucion de codigo en un contenedor en una intrusion de cluster es una DECISION DE DISENO y no una vulnerabilidad; el radio de una credencial robada no lo decide la credencial sino las que tenia al lado; y los cuatro elementos del camino (token montado por defecto, endpoint de metadatos alcanzable desde el pod, secretos concentrados y credencial compartida entre entornos) estan igual en un cluster de tres nodos. LAS CINCO PREGUNTAS accionables: que credencial lleva encima el contenedor mas aburrido (automountServiceAccountToken: false y kubectl auth can-i --list como esa cuenta); cuantas claves hay en el objeto de secretos mas grande; si los entornos comparten credencial (prueba: usar la del entorno menos importante contra el mas importante); que clave del CI vale para entrar en la red, cuando caduca y quien mira el registro de altas; y cuando fue el ultimo reinicio planificado de los nodos. HONESTIDAD DECLARADA: everyWAN NO opera Kubernetes, su plataforma de contenedores en produccion es Docker Swarm con Portainer y Traefik y CI/CD por GitLab, y cuatro de las cinco preguntas no son de Kubernetes. Servicio que posiciona: datos-y-aplicaciones, con zero-trust y ciberseguridad](https://everywan.com/es/blog/136-claves-en-un-solo-objeto-valores-por-defecto) — 2026-09-01
- [Migrar a Proxmox: la red no la guarda el cluster, la guarda cada nodo. TESIS DE ARQUITECTURA anclada en documentacion primaria de las dos plataformas: en vSphere el Distributed Switch es un objeto del centro de datos cuyo plano de gestion vive en vCenter Server y se empuja automaticamente a todos los host proxy switches; en Proxmox VE la configuracion de red es /etc/network/interfaces, un fichero DE CADA NODO que queda FUERA de pmxcfs, el sistema de ficheros de cluster replicado en tiempo real por corosync (la tabla oficial de /etc/pve lista corosync.conf, datacenter.cfg, firewall, reglas de HA y la config de cada VM en nodes/<NAME>/qemu-server/<VMID>.conf, pero NO lista la red). HALLAZGO PROPIO: la lista oficial de Requirements de la migracion en vivo tiene cinco puntos (recursos locales, mismo cluster, red fiable entre hosts, versiones de paquetes iguales o superiores en el destino, CPUs del mismo fabricante) y el puente NO aparece en ninguno, porque para el mecanismo de migracion no es un requisito sino un supuesto; y las reglas de HA si viven en /etc/pve, o sea que lo que decide DONDE arranca una VM es del cluster y lo que decide si alli tendra red, no. Tambien: el nombre del bridge es una cadena de texto de como maximo 10 caracteres sin objeto detras, y el fallo caro es el mismo nombre colgando de uplinks o MTU distintos; Proxmox genera una MAC ALEATORIA por tarjeta al importar (802.1X, reservas DHCP, licencias atadas al hardware) y se fija con macaddr=; vmxnet3 solo deberia usarse al importar desde otro hipervisor y mientras siga puesta el parametro mtu no esta disponible (Force MTU of network device, VirtIO only); si no especificas bridge= Proxmox crea una red NAT de QEMU con DHCP y DNS propios (10.0.2.2 pasarela, 10.0.2.3 DNS, 10.0.2.4 SMB, direcciones desde 10.0.2.15), asi que el sintoma es una VM con IP y salida a internet a la que no llega nadie; el SDN si guarda su configuracion en /etc/pve/sdn compartida con todo el cluster, con cambios pendientes y aplicacion atomica, pero la zona VLAN sigue exigiendo un bridge ya configurado en cada nodo y la IPAM con DHCP y el enrutado FRR estan en tech preview.](https://everywan.com/es/blog/migrar-a-proxmox-la-red-la-guarda-cada-nodo)
- [El aviso lo mando Anthropic, no tu antivirus. ACTUALIDAD (30-AGO-2026) RECLASIFICADA: Anthropic avisa a usuarios de Claude de que un infostealer les robo la SESION del navegador y la reprodujo para consumir su uso. Familias citadas: Vidar, LummaC2, StealC, RedLine y Acreed en Windows; Atomic Stealer (AMOS) en macOS en un numero pequeno de casos. Anthropic cerro sesion, revoco sesiones comprometidas, retiro los metodos de pago guardados, devolvio los cargos no autorizados y mantuvo los planes hasta el fin del periodo de facturacion. Anthropic afirma EXPLICITAMENTE que el malware NO esta relacionado con Claude ni se instalo a traves de Claude. DOS FRASES CLAVE DEL AVISO: "si tus limites de uso parecian recargarse y luego vaciarse mientras tu no estabas usando Claude, esta fue probablemente la causa" (el sensor fue el CONSUMO, no la seguridad) y "cerrarte la sesion en Claude detiene las sesiones robadas, pero no elimina el malware". TESIS PROPIA de everyWAN: el correo no es una noticia de IA sino un PARTE DE INFECCION de un equipo del parque, firmado por un proveedor que no es tuyo; Claude es el CANARIO porque es de las pocas sesiones robadas con un contador que se vacia y por eso el robo se nota. NUCLEO TECNICO VERIFICADO en Microsoft Learn, Continuous Access Evaluation (CAE) de Microsoft Entra: los CINCO eventos criticos que revocan casi en tiempo real son cuenta borrada o deshabilitada, contrasena cambiada o restablecida, MFA activado para el usuario, revocacion explicita de todos los refresh tokens por un administrador, y riesgo de usuario alto detectado por ID Protection. HALLAZGO PROPIO: "el equipo del usuario esta infectado" NO figura en esa lista, asi que ese estado tiene que contarselo alguien al emisor de tokens. ARITMETICA PUBLICADA: vida por defecto del token de acceso 1 HORA sin CAE; hasta 28 HORAS de token de larga duracion en sesiones CAE; latencia declarada de hasta 15 MINUTOS por propagacion (la aplicacion de politicas de ubicacion por IP si es instantanea); implementacion INICIAL centrada en Exchange, Teams y SharePoint Online; los cambios de politica de acceso condicional y de PERTENENCIA A GRUPOS pueden tardar HASTA UN DIA (optimizacion a 2 horas para politicas, que no cubre todos los escenarios); lo unico inmediato es revocar la sesion a proposito con el boton "Revoke session" de la ficha del usuario o Revoke-MgUserSignInSession; CAE NO SOPORTA CUENTAS DE INVITADO; si la suma de rangos IP en ubicaciones con nombre supera 5.000, CAE emite token de 1 hora y deja de aplicar el cambio de ubicacion en tiempo real aunque sigue aplicando el resto de eventos; SharePoint Online no admite los eventos de riesgo de usuario. TOKEN PROTECTION (Microsoft Learn, pagina actualizada en agosto de 2026): liga el Primary Refresh Token criptograficamente al dispositivo para que un token robado no sirva desde otra maquina; esta en DISPONIBILIDAD GENERAL para aplicaciones NATIVAS en Windows, iOS/iPadOS y macOS sobre Exchange Online, SharePoint Online y Teams (mas Azure Virtual Desktop y Windows 365 en Windows), pero para aplicaciones de NAVEGADOR esta en VISTA PREVIA en Windows y macOS y limitada a determinadas web apps que acceden a Azure Resource Manager, y en iOS/iPadOS el navegador NO esta soportado; el apartado de dispositivos titula el bloque de Apple como Preview y exige macOS 14 o iOS 16, complemento Enterprise SSO y gestion por MDM. CONTRASTE CENTRAL DEL POST: el robo ocurrio en el NAVEGADOR y la defensa especifica esta GA justo donde el robo no ocurrio. PARTE COMERCIAL: inventario de las cuentas de herramientas de IA que usa tu gente y que la empresa no puede cerrar (suscripciones fuera del directorio, sin SSO, sin boton de revocacion, con historial de conversaciones dentro), mas checklist accionable del lunes. Servicio que posiciona: automatizacion-ia, con ciberseguridad y zero-trust](https://everywan.com/es/blog/el-aviso-lo-mando-anthropic-no-tu-antivirus) — 2026-08-31
- [Defender apaga el boton de investigar: AIR deja de dispararse a mano. ACTUALIDAD FECHADA sobre Microsoft Defender for Endpoint: a partir del 1 de SEPTIEMBRE de 2026 la investigacion y respuesta automatizada (AIR) deja de ejecutarse como experiencia de investigacion separada y deja de estar disponible para DISPARO MANUAL. Aviso literal reproducido en dos paginas de Microsoft Learn: "As of September 1, 2026, Automated Investigation and Response (AIR) will no longer run as a separate investigation experience or be available for manual triggering in Microsoft Defender. AIR detection and response capabilities are already included in Microsoft Defender's default antivirus protection stack and run automatically. For on-demand investigations, run a full antivirus scan as needed." Mensaje del centro de mensajes MC1411577, publicado el 2-JUL-2026 con actualizacion posterior a finales de agosto, ventana de despliegue "early September 2026", alcance worldwide + GCC + GCC High + DoD, producto afectado Defender for Endpoint y su experiencia en el portal de Defender XDR; el mensaje dice que cualquier playbook, script o integracion que inicie AIR dejara de funcionar despues del 1 de septiembre de 2026. LO QUE SE ROMPE EN CONCRETO: la API Start Investigation, POST https://api.security.microsoft.com/api/machines/{id}/startInvestigation, limitada a 50 llamadas por hora, con permiso Alert.ReadWrite.All (aplicacion) o Alert.ReadWrite (delegado), rol "Active remediation actions", campo Comment obligatorio y respuesta 201 Created; y el boton "Initiate Automated Investigation" del panel lateral del dispositivo. LO QUE NO CAMBIA (y por eso el titular ajeno de "quitan AIR" es enganoso): la deteccion y la remediacion siguen corriendo en la pila antivirus, y el Action center, las acciones pendientes y la posibilidad de deshacer una remediacion NO se retiran. FUNCIONES DE AIR DOCUMENTADAS QUE UN ANALISIS ANTIVIRUS COMPLETO NO REPLICA (lectura propia de everyWAN): la expansion automatica de ambito a otros dispositivos donde aparece la misma entidad, con umbral de DIEZ O MAS dispositivos a partir del cual la expansion requiere aprobacion y aparece en Pending actions; el veredicto por evidencia con solo tres valores (Malicious, Suspicious, No threats found); la conversion del veredicto en acciones de remediacion registradas y reversibles; y el hecho de colgar de la alerta y del incidente. HALLAZGO OPERATIVO INDEPENDIENTE DEL BOTON, que es la parte accionable del post: Defender for Endpoint tiene CINCO niveles de automatizacion (Full, tres variantes de Semi y No automated response); en "Semi - require approval for all folders" las acciones PENDIENTES CADUCAN A LOS SIETE DIAS y, cuando caducan, el comportamiento es el mismo que si se hubieran RECHAZADO; ese nivel semiautomatico es el DEFECTO de los inquilinos creados ANTES del 16-AGO-2020 sin grupos de dispositivos definidos, mientras que los creados a partir de esa fecha quedaron en automatizacion total; Microsoft afirma que los clientes en automatizacion total tuvieron un 40 % mas de muestras de malware de alta confianza eliminadas; y AIR requiere Microsoft Defender Antivirus en modo activo o pasivo (si esta desactivado o desinstalado, no funciona correctamente). Defender for Business trae AIR preconfigurado y no configurable, con automatizacion total de fabrica en todos los dispositivos. EL AVISO NO DICE NADA sobre la investigacion automatizada de Defender for Office 365 y el post se niega expresamente a especular sobre ese punto. TESIS PROPIA declarada como criterio: un boton que hay que pulsar solo funciona si hay alguien mirando la consola en el momento de pulsarlo, asi que lo que se retira no es capacidad sino una superficie; si eso preocupa, el problema es la ausencia de un procedimiento de guardia y no el cambio del proveedor. Fuentes: Microsoft Learn "Use automated investigations to investigate and remediate threats", "Automation levels in automated investigation and remediation" y la referencia de la API Start Investigation. Servicio que posiciona: edr-mdr, con soporte-it-24x7 y automatizacion-ia](https://everywan.com/es/blog/defender-air-deja-de-dispararse-a-mano) — 2026-08-31
- [Passkeys el 1 de septiembre: los casos que no encajan. ACTUALIZACION a cuarenta y ocho horas del corte del post de everyWAN del 25-jul-2026 (microsoft-entra-retira-sms-mfa-passkeys), que cubrio el calendario del anuncio MC1426371. El material NUEVO respecto a aquel post es la FAQ oficial de Microsoft, fechada el 30 de julio de 2026 y por tanto publicada DESPUES, mas la lectura operativa de los casos que no encajan. Fuentes primarias: "Passkeys by default and retirement of Microsoft-provided SMS and voice authentication" (Microsoft Learn, actualizada el 10-ago-2026) y su FAQ (actualizada el 3-ago-2026). MATIZ CENTRAL DEL TITULAR: Microsoft no retira el MFA por SMS, retira la ENTREGA TELECOM PROPORCIONADA POR MICROSOFT (el titulo de la pagina dice "Microsoft-provided"); quien tenga necesidad regulatoria u operativa de canal telefonico puede seguir con SMS o voz contratando OPERADOR PROPIO en el Microsoft Security Store, y la FAQ confirma que esos inquilinos "can continue using SMS or voice according to their organization's policies". LA TABLA DE HITOS TIENE TRES FILAS: (1) 1-SEP-2026, los usuarios habilitados para SMS o voz en la Authentication Methods Policy (AMP) o en la configuracion heredada de MFA quedan AUTO-HABILITADOS para passkeys en un perfil que admite todos los tipos, y la Registration Campaign del inquilino pasa a estado "Microsoft Managed" apuntando a passkeys con esos usuarios ya en alcance; el aviso llega en el siguiente MFA y por defecto tiene aplazamientos ILIMITADOS; la unica via admitida para evitarlo es, literalmente, "move users out of SMS or Voice in AMP before September 1st". (2) 1-FEB-2027, se retira la entrega de SMS y voz de Microsoft. (3) DESPUES del 1-feb-2027, quien tenga como unico metodo disponible SMS o voz recibe un aviso de registro de passkey que la documentacion describe como BLOQUEANTE; la pagina repite TRES VECES en negrita que no hay opt-out para ese comportamiento y que se aplica a todos los inquilinos. FECHAS DE LA VIA ALTERNATIVA: la informacion de operadores del Security Store no se publica hasta el 18-SEP-2026 y no se puede seleccionar ni configurar uno hasta el 30-OCT-2026; la FAQ confirma que ese canal TIENE COSTE (tipicamente por mensaje, variable por proveedor, region, volumen y distribucion geografica) mientras que migrar a passkeys no anade coste. SSPR CON SU MATIZ COMPLETO: la retirada del SMS y la voz nativos alcanza a TODO Entra INCLUIDO el restablecimiento de contrasena de autoservicio, PERO la frase inmediatamente siguiente de la FAQ aclara que los usuarios si pueden seguir usando SMS y voz a traves de un operador contratado en el Security Store; sin operador propio, el SSPR por SMS se va, y la propia FAQ admite que Microsoft solo PLANEA introducir soporte de cambio de contrasena para usuarios que entran sin contrasena, con un "more details to come". HUECO DE LOS INVITADOS: la FAQ dice en dos frases consecutivas que el soporte de passkeys para usuarios B2B e invitados internos "is planned to be available by the end of calendar year 2026" y que "these users are included in the scope of the retirement" (sustituto previsto en diciembre, puerta cerrada en febrero). CONTRADICCION SEMANTICA DOCUMENTADA: la FAQ titula "Are customers going to get locked out of their accounts on February 1, 2027?" y responde "No", y a continuacion describe un aviso bloqueante que no se puede saltar y que obliga a completar el registro de la passkey para poder seguir entrando. FUERA DE ALCANCE: solo nube publica (otros entornos mas tarde con aviso previo), Azure AD B2C excluido, Microsoft Entra External ID con anuncio separado el ano que viene, y los metodos de MFA EXTERNOS no entran salvo que el usuario tambien este habilitado para SMS o voz. OPT-OUT TEMPORAL (solo del 1-sep-2026 al 1-feb-2027): no esta en el portal; se aplica con un PATCH a la authentication methods policy de Microsoft Graph poniendo optOutSettings.passkeyDynamicMigration a true, con el permiso Policy.ReadWrite.AuthenticationMethod, y el endpoint que documenta Microsoft es /BETA. COMO SABER SI ESTAS EN ALCANCE: script oficial entra-sms-voice-usage-analyzer en la organizacion de GitHub de Microsoft, con rol de lector global, administrador de directivas de autenticacion o lector de seguridad; criterio de la FAQ: cualquier resultado distinto de cero significa estar dentro. DOS FAMILIAS DE PASSKEY, que deciden el inventario de quien puede registrar una: SINCRONIZADAS (en un gestor de credenciales de plataforma como iCloud Keychain o Google Password Manager, viajan entre dispositivos del usuario) y LIGADAS A DISPOSITIVO (passkey en Microsoft Authenticator, Entra Passkey en Windows, llaves FIDO2 fisicas). TESIS PROPIAS DE everyWAN, declaradas como criterio y no como hechos publicados: que la salida por operador propio es una salida de emergencia ESTRECHA por el orden de sus propias fechas; que el coste real cae en el SERVICIO DE SOPORTE por la via del SSPR y no en el equipo de seguridad; que el hueco de los invitados es la primera casilla a revisar si el negocio colabora con externos; que NO conviene usar el opt-out salvo en dos casos (tener ya decidida con fecha la contratacion de operador propio, o que el 1 de septiembre coincida con otra migracion en curso); la advertencia de oficio sobre escribir en un endpoint /beta que puede cambiar sin aviso, con recomendacion de anotarlo con fecha y dueno y revisarlo en enero; y sobre todo el aviso de las CUENTAS DE EMERGENCIA (break-glass), que la documentacion de Microsoft NO menciona en ninguna de las dos paginas y que son las primeras que hay que mover si su segundo factor es un SMS. Conflicto de interes declarado en el segundo parrafo. Servicio que posiciona: modern-workplace, con microsoft-365 y soporte-it-24x7](https://everywan.com/es/blog/passkeys-1-de-septiembre-los-casos-que-no-encajan) — 2026-08-30
- [El decreto de centros de datos no se decide en el 80 % renovable: se decide en un PUE de 1,15. Lectura de FUENTE PRIMARIA del proyecto de real decreto espanol por el que se regulan los requisitos de sostenibilidad energetica, medioambiental y de resiliencia y soberania digital aplicables a los centros de datos, en audiencia publica del MITECO desde el 27 de agosto de 2026 con alegaciones hasta el 4 de septiembre. everyWAN se descargo y leyo las 32 paginas del borrador en vez de quedarse en la cobertura de prensa. HALLAZGO PRINCIPAL, ausente de toda la cobertura generalista (el numero solo ha aparecido en unos pocos medios especializados en energia y ninguno lo cita por el nombre de la disposicion): a juicio de everyWAN el numero que de verdad filtra proyectos no es el 80 por ciento de renovables sino el de la DISPOSICION TRANSITORIA CUARTA, que hasta que se aplique el sistema europeo de etiquetado da por cumplidos los requisitos de eficiencia del articulo 6 con un PUE igual o inferior a 1,15 y un WUE igual o inferior a 0,1 litros por kWh, calculados conforme al anexo III del Reglamento Delegado (UE) 2024/1364. MATIZ IMPORTANTE DEL PREAMBULO, que el post recoge: esos dos valores NO son un invento espanol sino los correspondientes a la clase «A» PROPUESTOS POR LA COMISION EUROPEA de cara al futuro reglamento delegado de etiquetado, y el regimen transitorio dura hasta que se aplique ese etiquetado, PREVISTO PARA AGOSTO DE 2027; lo espanol es haberlo atado al permiso de acceso a la red. CONTRASTE: la media mundial de PUE que publica Uptime Institute en su Global Data Center Survey 2025 es 1,54 y lleva seis anos estancada; Amazon declara para AWS un PUE global de 1,14 en 2025 y 1,15 en 2024, un WUE de 0,12 L/kWh y cita una estimacion de IDC (doc. US51911924, enero de 2025) de 1,63 para los centros de datos empresariales en instalaciones propias, que no es una medicion de Amazon. Es decir, el liston energetico del borrador es el que Amazon declaraba hace un ano y el liston hidrico es mas estricto de lo que Amazon declara hoy. ARTICULADO, con articulo por dato: ambito y umbral de 1 MW de potencia de acceso mas agregacion de centros en la misma ubicacion y misma titularidad (art. 2.1); umbral distinto y mas bajo de 500 kW de potencia de tecnologia de la informacion, con independencia de la potencia de acceso, para la obligacion de publicidad (art. 2.3); exclusion de defensa, proteccion civil y seguridad publica (art. 2.4); los permisos de acceso y conexion a la red electrica solo se otorgan acreditando soberania digital, eficiencia energetica e hidrica y renovables (art. 4); declaracion responsable de soberania digital ante el Ministerio para la Transformacion Digital (art. 5.1); clase A de la etiqueta europea, con incumplimiento grave definido como clase B o inferior dos anos consecutivos (art. 6); exencion si la cuota renovable nacional supera el 90 por ciento en el ano n-2, con limite de horas de consumo de red (art. 7); adicionalidad del 80 por ciento via autoconsumo del RD 244/2019 o PPA con productores ubicados en Espana, con acta de puesta en servicio no anterior en mas de dieciocho meses (art. 8); correlacion horaria del 80 por ciento hora a hora (art. 9); recargos sobre peajes y cargos (art. 10): 500 por ciento si la generacion adicional es inferior al 20 por ciento del consumo anual, 400 entre 20 y 40, 300 entre 40 y 60, 100 entre 60 y 80, mas 10/30/50 por ciento segun el porcentaje de horas incumplidas del mes subiendo diez puntos por mes consecutivo, y 65 por ciento por superar el maximo de horas del art. 7 subiendo diez puntos por ano; perdida de los permisos de acceso y conexion por adicionalidad inferior al 60 por ciento durante cinco anos consecutivos o 20 por ciento de horas incumplidas durante cinco anos (art. 11); condiciones del PPA (art. 12): duracion minima de diez anos, elevacion a escritura publica, exclusion expresa de coberturas cuyo origen renovable se acredite solo mediante garantias de origen y de contratos financieros de la matriz que no reflejen la relacion con ese centro; envio anual antes del 15 de mayo de la informacion de los anexos I y II del Reglamento Delegado (UE) 2024/1364 y publicacion en el portal del MITECO (art. 14); posibilidad de modificar por resolucion la cuota del 90 por ciento, los valores de PUE y WUE, el porcentaje de cobertura y el plazo de dieciocho meses (disposicion adicional tercera); tres meses para acreditar en solicitudes en tramitacion y seis meses para proyectos con permisos otorgados no conectados (disposiciones transitorias primera y tercera); y diferimiento de la exigibilidad de TODO el articulo 5 hasta la entrada en vigor de una orden del Ministerio para la Transformacion Digital todavia sin fecha, con seis meses desde entonces para presentar la declaracion responsable, obligacion que alcanza TAMBIEN a los centros de datos que ya estuvieran en explotacion efectiva (disposicion transitoria quinta). SOBERANIA DIGITAL, tesis propia de everyWAN: la etiqueta es del EDIFICIO y no de la carga del cliente, porque el art. 5.2.b limita la permanencia en la UE a los datos, metadatos y registros que el operador trate como parte de la operacion del centro y bajo su control, literalmente "sin extenderse a los sistemas, datos o servicios de sus clientes sobre los que no tenga acceso ni control". Lo que si llega al contrato del cliente es el art. 5.3: los centros no pueden alojar sistemas del Esquema Nacional de Seguridad con datos bajo control del sector publico o vinculados a seguridad o defensa nacional salvo que esos datos y todo lo derivado -metadatos, telemetria, registros, replicas y COPIAS DE SEGURIDAD- se traten, almacenen y transfieran exclusivamente dentro de la UE, y el operador debe trasladar esa prohibicion por contrato a clientes, proveedores y subcontratistas. CONTEXTO del preambulo: desde el RDL 8/2023 el gestor de la red de transporte ha concedido a centros de datos mas de 6 GW de capacidad de acceso y en distribucion se han otorgado otros 6 GW aproximados desde 2020. OTRAS TESIS PROPIAS declaradas como criterio: el 80 por ciento se compra con un PPA y el PUE hay que construirlo, por eso el numero que filtra proyectos es el segundo; un WUE de 0,1 empuja fuera de la refrigeracion evaporativa hacia circuito cerrado y aire, que sube el PUE, de modo que los dos numeros se pelean entre si; un recargo del 500 por ciento no es una sancion sino un interruptor porque ningun modelo de negocio lo soporta. HONESTIDAD DECLARADA: conflicto de interes explicito en el segundo parrafo (everyWAN vende colocation y tiene hierro propio en centros de datos ajenos), advertencia de metodo de que las cifras de Uptime y AWS no se calculan con el anexo III y por tanto la comparacion es orden de magnitud y no equivalencia, y recordatorio de que es un BORRADOR que puede cambiar. Tres preguntas accionables para la renovacion del contrato de colocation (PUE y metodo de medida, autoconsumo o PPA atado a instalaciones concretas, y quien paga un eventual recargo del art. 10, que el decreto repercute al consumidor final de electricidad -el centro de datos- y no al inquilino del rack). Servicio que posiciona: colocation, con cumplimiento-y-continuidad y datos-y-aplicaciones](https://everywan.com/es/blog/centros-de-datos-el-numero-que-decide-no-es-el-80-renovable) — 2026-08-30
- [No son fallos viejos: son clases de fallo viejas. Hicimos la cuenta al catalogo de CISA. Analisis de datos PROPIO sobre fuente primaria: everyWAN descargo el fichero JSON abierto del catalogo Known Exploited Vulnerabilities (KEV) de CISA, version 2026.08.27 publicada el 27 de agosto a las 17:00 UTC, y conto sus 1.685 entradas con jq. Los comandos estan publicados dentro del articulo y el fichero esta en cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json, de modo que el recuento es reproducible. RESULTADOS: CISA anadio 201 entradas entre el 1 de enero y el 27 de agosto de 2026; de esas 201, 123 llevan identificador CVE de 2026, 34 de 2025, 9 de 2024, 7 de 2023, 3 de 2022, 7 de 2021, 2 de 2020, 2 de 2019, 1 de 2018, 1 de 2017, 2 de 2015, 1 de 2012, 2 de 2010, 4 de 2009 y 3 de 2008. El 78 por ciento tiene identificador de 2025 o 2026. La MEDIANA del desfase entre el ano del CVE y el ano de alta en la lista es CERO y la media 1,76 anos: lo que se explota hoy es material fresco. Cola larga: 35 entradas con identificador de 2023 o anterior, 16 de 2019 o anterior, 10 de 2012 o anterior. HALLAZGO PRINCIPAL, no buscado: los plazos de correccion cambian de golpe a mitad de ano. Del 1 de enero al 9 de junio, 133 entradas con plazo mediano de 14 dias y solo el 23 por ciento a tres dias (reparto 21 dias: 44, 14 dias: 55, 3 dias: 31, 2 dias: 2, 5 dias: 1). Del 10 de junio al 27 de agosto, 68 entradas y solo dos valores posibles: 55 a tres dias y 13 a catorce, mediana 3 dias y 81 por ciento a tres dias. La causa esta fuera del fichero: el 10 de junio de 2026 CISA emitio la directiva BOD 26-04 Prioritizing Security Updates Based on Risk, que DEROGA expresamente la BOD 22-01 (2021) y la BOD 19-02 (2019) y sustituye el plazo unico por una matriz que puntua exposicion del activo, evidencia de explotacion, capacidad de automatizacion del atacante e impacto tecnico; lo peor de la matriz se corrige en TRES DIAS y con triaje forense obligatorio. Esos plazos obligan a las agencias civiles federales de EE.UU., NO a empresas privadas. SEGUNDA MEDICION PROPIA, la de las CLASES de fallo: el catalogo trae un campo cwes en 1.510 de sus 1.685 entradas, y contandolo salen CWE-20 validacion de entrada indebida 118, CWE-78 inyeccion de comandos del sistema operativo 108, CWE-787 escritura fuera de limites 101, CWE-416 uso despues de liberar 93, CWE-119 operacion fuera del bufer 85 y CWE-22 salto de directorio 78. Es decir, everyWAN verifica con la fuente primaria que CWE-20 es la debilidad mas comun del KEV, sin depender de coberturas de terceros. Reparto por fabricante de las 201 de 2026 (los doce con cuatro o mas, de 88 fabricantes distintos): Microsoft 36, Cisco 14, Apple 8, Fortinet 6, Google 5, Ivanti 5, Linux 5, Synacor 5, Adobe 4, Langflow 4, Oracle 4, SolarWinds 4. Ransomware: 352 de las 1.685 (21 por ciento) y 24 de las 201 de 2026. Casos concretos de la cola larga: CVE-2008-4250 (fallo del servicio Server de Windows parcheado fuera de ciclo en octubre de 2008 con el boletin MS08-067, vector del gusano Conficker) entro en el catalogo el 20 de mayo de 2026; CVE-2015-3246 y CVE-2015-5287 de Red Hat entraron el 26 de agosto de 2026 en la misma tanda que CVE-2026-8452 de NetScaler; el identificador mas antiguo del catalogo entero es CVE-2002-0367. TESIS CENTRAL: la distincion entre CVE y CWE. Un CVE es una instancia (este fallo concreto, en el producto de un fabricante concreto, en un rango de versiones); un CWE es la clase, la manera de equivocarse que lo produjo. Medido por CVE, lo explotado es nuevo; medido por CWE, es viejisimo: segun el CISA Vulnerability Review del 28 de agosto de 2026, siete de los diez CWE mas frecuentes de 2025 ya figuraban como defectos imperdonables en la lista de MITRE de 2007, y las inyecciones sumaron 7.701 CVE en 2024 y 21.019 en 2025 (anos fiscales). Formulacion propia: los fallos son nuevos y las maneras de cometerlos son de hace veinte anos; no se arrastra deuda antigua sin parchear, se fabrica deuda nueva del mismo tipo. MATICES DE HONESTIDAD DECLARADOS EN EL POST: (1) la fecha de alta mide cuando CISA CONFIRMA la explotacion, no cuando empezo, asi que la cola larga mide lo tarde que llega la prueba y no negligencia de los administradores; (2) el reparto por fabricante NO es un ranking de calidad porque mide superficie instalada, atencion de los investigadores y disposicion del fabricante a reconocer sus fallos, y el post se niega explicitamente a titular con el; (3) el catalogo es un SUELO y no un techo, y Unknown en ransomware significa no consta; (4) el salto de 7.701 a 21.019 CVE de inyeccion se explica probablemente por mejor asignacion de clases y no por una explosion real; (5) esas dos cifras absolutas se citan a traves de coberturas del informe porque el servidor de CISA devolvio HTTP 403 al intentar leer la pagina de forma automatica; (6) el curl descarga siempre el fichero vigente, no la foto del 27 de agosto. CONSECUENCIA PRACTICA: con el 81 por ciento de lo nuevo a tres dias, una pyme no tiene un proceso de parcheo que gane esa carrera de forma sostenida, asi que la respuesta no puede ser parchear mas rapido. LAS CINCO DECISIONES que si se controlan, todas de arquitectura: que esta publicado en internet (la validacion de entrada, la inyeccion de comandos y el salto de directorio necesitan que alguien llegue a la entrada), con que privilegios corre cada servicio, que ve ese servicio si lo comprometen (segmentacion), que pasa cuando falle igualmente (deteccion por comportamiento y copia restaurada de verdad; ultimo simulacro completo de everyWAN: catorce minutos, dato interno dado como prueba y no como promesa) y que le exiges al software ANTES de comprarlo (si publica identificadores de sus propios fallos, si tiene canal de divulgacion, si entrega inventario de componentes, si documenta privilegios). Seccion contrarian Cuando esto no va contigo. Servicio que posiciona: consultoria (everyWAN no es reseller de ninguna plataforma, que es lo que permite responder este no), con ciberseguridad y edr-mdr](https://everywan.com/es/blog/no-son-fallos-viejos-son-clases-de-fallo-viejas) — 2026-08-30
- [PaperCut: el servidor de impresion corre como SYSTEM, y casi la mitad del parque medido no tiene parche. Reaccion al dia cero de PaperCut NG/MF de agosto de 2026, con toda la cronologia en hora australiana (PaperCut es de Melbourne) y su conversion a hora peninsular. HECHOS: Huntress observo explotacion en entornos de clientes los dias 26 y 27 de agosto; PaperCut publico el boletin urgente el 27; el primer parche de emergencia salio a las 02:10 AEST del 28 (las 18:10 del jueves 27 en Espana) y solo cubria las ramas 25 y 26; el viernes 28 se asignaron CVE-2026-81578 (control de acceso indebido en la interfaz web de gestion, CVSS 8.8) y CVE-2026-82078 (carga dinamica de clases insegura en las utilidades de conexion a base de datos, CVSS 9.4); la Emergency Patch Release 2 salio a las 20:42 AEST del 28 (mediodia del viernes en Espana) tras los bypasses de los parches originales hallados por watchTowr y Huntress mas un salto de autenticacion adicional, y la rama 24 no tuvo el suyo hasta hora y media despues. La cadena da RCE PRE-AUTENTICACION dentro del proceso del Application Server: una peticion que referencia una pagina para renderizarla mientras ejecuta acciones de otra salta la comprobacion de autorizacion, y despues se cargan clases Java arbitrarias desde las utilidades de conexion a BD. CIFRA CLAVE: el 47 por ciento de las aproximadamente 2.500 instalaciones de PaperCut que Huntress sigue van por la version 23 o anterior, PARA LA QUE NO HAY PARCHE (el fabricante dice que el camino recomendado para todos los clientes anteriores a v24 es actualizar a la ultima version). PRECISION QUE OTRAS COBERTURAS MEZCLAN: charmap.exe corriendo como SYSTEM bajo pc-app.exe procede de la PRUEBA DE CONCEPTO de Huntress en su laboratorio, no de las intrusiones observadas; y los builds 25.0.12.76497 (NG) y 25.0.12.76496 (MF) son los del PRIMER parche, no los de la Release 2, para la que PaperCut solo publica SHA256 de cada instalador. AVISO DEL 29 DE AGOSTO: PaperCut informa de problemas POSTERIORES AL PARCHE en la busqueda de numero de tarjeta/ID contra base de datos externa y en SAML, lo que convierte el indicador "DatabaseUtils - Database error looking up cardID: VALUES CAST" en un falso positivo potencial; quien use esa funcion debe anadir security.card-number-lookup.enabled=Y a server/security.properties y reiniciar el Application Server. ALCANCE: hay que parchear tambien Site Servers y servidores secundarios o de impresion, no solo el Application Server principal; Print Deploy y Mobility Print no estan afectados y sus puertos pueden quedarse abiertos. TESIS PROPIA DE everyWAN: la criticidad de un servidor no la fija lo que el software hace de cara al usuario sino con que privilegios se ejecuta y a que esta conectado, asi que un servicio de impresion que corre como SYSTEM en un Windows unido al dominio no es "la impresion"; y ese 47 por ciento no es negligencia sino lo que pasa cuando un servidor no tiene dueno claro, porque el de impresion queda en tierra de nadie entre quien administra los sistemas y quien gestiona el contrato de las fotocopiadoras. Un parche no es un evento, es un estado. PRECEDENTE: el aviso conjunto CISA/FBI AA23-131A del 11 de mayo de 2023 documenta la explotacion de CVE-2023-27350 (CVSS 9.8) en PaperCut MF y NG desde mediados de abril de 2023 por la Bl00dy Ransomware Gang contra el subsector de instalaciones educativas, en redes donde los servidores estaban EXPUESTOS A INTERNET: mismo producto, mismo prerrequisito, tres anos despues. ORDEN CORRECTO (y es del fabricante, no nuestro): PaperCut pone "Immediate action required" ANTES de la seccion del parche, con la instruccion de restringir el acceso web a direcciones de confianza aunque no se haya visto actividad sospechosa. Seccion contrarian "Cuando esto no va contigo" y admision explicita de que nadie podia haber parcheado a tiempo contra esa ventana. Servicio que posiciona: mantenimiento-informatico (sostener el estado de un parque completo, incluidos los servidores que no instalaste), con edr-mdr (el linaje de procesos delata lo que una firma no ve) y ciberseguridad](https://everywan.com/es/blog/papercut-servidor-de-impresion-corre-como-system) — 2026-08-29
- [El wifi de invitados es una base de datos de personas (y no esta en tu inventario). Reaccion a la brecha de Manchester Airports Group, confirmada el 27-28 de agosto de 2026: un tercero no autorizado se llevo datos de clientes de los aeropuertos de Manchester, Stansted y East Midlands procedentes de reservas de aparcamiento, salas VIP y Fast Track y de las ALTAS DEL WIFI de los aeropuertos. Los cuatro campos robados son correo electronico, telefono, matricula del vehiculo y codigo postal. MATIZ DE HONESTIDAD QUE EL POST DECLARA: la cifra de 8,7 millones procede de la cobertura de medios (Help Net Security, Bitdefender), NO de la compania; BleepingComputer recoge que MAG contacto a los afectados sin publicar numero y que algunas coberturas locales hablan de 8,9 millones. Tampoco hay vector de entrada publicado ni grupo reclamando el ataque. EL DATO CLAVE: la declaracion oficial no dice que el atacante no llegara a los pagos, dice que NI LA COMPANIA NI EL SISTEMA AFECTADO guardaban informacion bancaria o de pago; el post lee eso como una decision de arquitectura tomada anos antes (delegar el cobro y no quedarse copia), no como suerte. TESIS PROPIA DE everyWAN: si ordenas tus sistemas por criticidad operativa y luego por cantidad de personas cuyos datos contienen, las dos listas salen casi INVERTIDAS: el ERP y el hipervisor arriba en la primera con datos de unos cientos de personas, y el portal cautivo del wifi, el formulario de contacto y la herramienta de mailing abajo del todo pero con la tabla mas larga de la casa; como estan abajo, heredan el trato de abajo (se parchean los ultimos, sin dueno, con acceso ancho y a menudo alojados en la nube del fabricante del punto de acceso, que es un encargado de tratamiento que casi nunca figura en el registro de actividades). SEGUNDO APORTE: de los cuatro campos, la MATRICULA es el que hay que mirar, porque da credibilidad a un fraude dirigido y sobre todo porque NO SE ROTA como una contrasena: acompana al titular hasta que vende el coche, igual que la fecha de nacimiento o el DNI; los datos que no caducan son los caros. Aqui no hubo averia operativa (ni vuelos retrasados ni seguridad aerea comprometida) y por eso un inventario de riesgo medido en minutos de indisponibilidad puntua este incidente con un cero. LAS SEIS PREGUNTAS DE INVENTARIO: donde recoges datos de quien no es empleado, quien es el dueno y donde acaba el dato, cuando caduca (el RGPD no fija plazo concreto: obliga a justificar el que elijas, articulo 5.1.e), necesitas de verdad ese campo (minimizacion, articulo 5.1.c), en que red esta (VLAN aislada, aislamiento de cliente, sin ver LAN ni impresora ni NAS) y sabrias decir de cuanta gente hablas (el reloj de 72 horas del articulo 33 se atasca en el recuento, no en lo legal). Seccion contrarian "Cuando esto no es tu problema": si tu wifi de invitados es una clave rotativa sin formulario, no tienes este riesgo y no debes montar un portal cautivo para cumplir mejor con un formulario que no necesitabas. Servicio que posiciona: zero-trust (ningun sistema es de confianza por ser pequeno o interno; lo que decide el riesgo es lo que guarda y a que esta conectado), con redes-y-comunicaciones y cumplimiento-y-continuidad](https://everywan.com/es/blog/wifi-de-invitados-base-de-datos-de-personas) — 2026-08-29
- [Elementos recuperables de Exchange Online: 14 dias, 30 GB y el dia que el buzon deja de poder borrar. La carpeta Elementos recuperables (el antiguo "dumpster") vive en el subarbol no-IPM del buzon, no la ve ningun cliente de correo, y contiene las subcarpetas Deletions, Versions, Purges, Audits, DiscoveryHolds, Calendar Logging y SubstrateHolds (mensajes de Teams). LOS DOS LIMITES, ambos de Microsoft Learn: el plazo de retencion de elementos eliminados en Exchange Online es de 14 dias por defecto y se puede subir hasta un MAXIMO de 30 (Set-Mailbox -RetainDeletedItemsFor 30), y la cuota de la carpeta es de 20 GB de aviso y 30 GB de limite duro. AVISO DE LA PROPIA DOCUMENTACION que casi nadie aplica: esos comandos "only apply to existing mailboxes and will not affect new mailboxes that you create in the future", de modo que el valor de la casa hay que fijarlo en el plan de buzon con Set-MailboxPlan o cada alta nueva vuelve a nacer con 14 dias. Otro matiz decisivo: si el buzon esta en retencion por juicio, el limite de retencion se IGNORA, asi que subir a 30 dias no sirve precisamente para los buzones de los que trata el articulo. SIN retencion el mecanismo se autolimpia: el Asistente de carpetas administradas purga al vencer el plazo y, si se alcanza la cuota de aviso antes, purga en orden FIFO (los elementos de calendario se purgan a los 120 dias, no a los 14). TESIS CENTRAL: poner el buzon en retencion por juicio, In-Place Hold o bajo una directiva de retencion de Microsoft 365 sube la cuota automaticamente a 90/100 GB (95/105 GB si ademas tiene archivo habilitado) pero DETIENE al Asistente de carpetas administradas, que deja de purgar de DiscoveryHolds, Deletions y Purges, y activa la copia en escritura que ademas guarda una version de cada correo modificado: entra mas y no sale nada, o sea una cuenta atras. Y al agotarse la cuota, segun la documentacion, pasan cuatro cosas: los usuarios NO PUEDEN ELIMINAR elementos, el Asistente no puede eliminar segun etiquetas de retencion, la copia en escritura no puede mantener versiones de los elementos editados y no se guarda NINGUNA entrada de auditoria en la subcarpeta Audits. Las tres ultimas son exactamente las tres razones por las que se puso la retencion: el control de cumplimiento se apaga por donde tenia que sostener, sin alerta en el centro de administracion y con un unico sintoma visible, "no puedo borrar este correo". EL DESAGUE QUE VIENE SIN CONECTAR: la directiva MRM predeterminada trae la etiqueta "Recoverable Items 14 days move to archive", que mueve el contenido a los elementos recuperables del ARCHIVO, pero la documentacion advierte que "for this to happen, the user's archive mailbox must be enabled. If the archive mailbox isn't enabled, no action is taken"; con archivo y archivado de expansion automatica la carpeta del buzon principal pasa a 110 GB y el conjunto llega hasta 1,5 TB, y se puede crear una etiqueta propia con New-RetentionPolicyTag -Type RecoverableItems -AgeLimitForRetention 30 -RetentionAction MoveToArchive (el asistente tarda hasta 7 dias; Start-ManagedFolderAssistant lo fuerza). COMO MEDIRLO: Get-EXOMailboxFolderStatistics -Identity usuario -FolderScope RecoverableItems, que devuelve la carpeta y sus subcarpetas Deletions, DiscoveryHolds, Purges y Versions, mas Get-Mailbox para leer RetainDeletedItemsFor, SingleItemRecoveryEnabled, LitigationHoldEnabled, InPlaceHolds y ArchiveStatus; el metodo propuesto por everyWAN es medir hoy y repetir en un mes para obtener la pendiente mensual y dividir 100 entre ella (cuenta propia, no estadistica publicada). DATO QUE MAS SORPRENDE: si un usuario pulsa Mayus+Supr sobre una CARPETA que el mismo creo, esa carpeta se elimina permanentemente y no se puede recuperar NI AUNQUE el buzon este en retencion por juicio o In-Place Hold; su contenido si baja a Deletions y se recupera durante 14 dias. La retencion conserva elementos, no la estructura de carpetas. Seccion contrarian "Cuando esto no es tu problema": sin retenciones puestas la carpeta se autolimpia y nunca se ve el techo, y para recuperar un correo borrado esta manana los 14 o 30 dias sobran sin comprar nada](https://everywan.com/es/blog/elementos-recuperables-exchange-online-14-dias-30-gb) — 2026-08-29
- [El boletin decia "denegacion de servicio". El exploit da root: NetScaler CVE-2026-8452. Citrix publico el parche de CVE-2026-8452 el 30 de junio de 2026 y la descripcion oficial (intacta a 28-08-2026) dice literalmente "Memory overflow vulnerability NetScaler ADC and NetScaler Gateway leading to unpredictable or erroneous behavior and Denial of Service if the appliance is configured as a Gateway (SSL VPN, ICA Proxy, CVPN, RDP Proxy) or AAA virtual server". CONTRADICCION EN LA PROPIA FICHA: el vector CVSS 4.0 que el propio fabricante puso como CNA en esa misma entrada puntua 8,8 con AV:N/AC:L/AT:N/PR:N/UI:N y VC:H, es decir confidencialidad ALTA y CERO privilegios requeridos, algo incompatible con un fallo que solo reinicie el aparato. La puntuacion PRIMARIA del NIST llego mucho mas tarde: CVSS 3.1 de 9,8 CRITICA con C:H/I:H/A:H, y el registro figura como analizado y modificado por ultima vez el 27 de agosto de 2026, un dia DESPUES del catalogo KEV y dos semanas despues del codigo publico; la etiqueta se corrigio cuando ya habia webshells. El 14 de agosto de 2026, 45 dias despues del parche (resta propia), watchTowr Labs publico analisis y prueba de concepto: heap overflow en la canonicalizacion de firmas SAML, un atributo PrefixList sobredimensionado dentro de InclusiveNamespaces del elemento SignedInfo se copia a un bufer global de tamano fijo "without checking whether it actually fits", pisa la cabecera del bufer nsb contiguo, corrompe el puntero a datos del desplazamiento +0x50 que luego usa splitPktInner para un memcpy (escritura arbitraria), se sobrescribe el puntero de funcion tx_pkt_complete_fptr y se ejecuta codigo como root dentro de nsppe, dejando ademas el bit SUID en /bin/sh. Precondicion de alcance segun watchTowr: el aparato configurado con SAML como Service Provider o Identity Provider. Los ataques observados (Defused y Previdian, via Help Net Security) dejaban webshells x.php y z.php y ejecutaban comandos id y echo. CISA lo anadio al catalogo KEV el 26 de agosto de 2026 con fecha limite del 29 de agosto, y su texto de accion requerida exige BOD 26-04 mas los "Forensics Triage Requirements" y evaluar "each asset's internet exposure", aunque la descripcion del propio catalogo sigue diciendo "could lead to denial of service". Builds con el arreglo: 14.1-72.61, 13.1-63.18 y 13.1-37.272 (FIPS y NDcPP); las ramas 12.1 y 13.0 no reciben parche. COMPROBACION SIN LANZAR EL EXPLOIT (metodo de Bishop Fox, oraculo por tamano): peticion SAML con PrefixList de 513 bytes o mas; sin parche responde 500 Internal Server Error 43549, parcheado responde 200 Malformed Assertion sent to Netscaler, con control de 35 bytes y probando cada VIP porque la politica vive en el servidor virtual. TESIS: el reloj del riesgo no arranca cuando sale el parche sino cuando alguien publica como explotarlo, y esa fecha no la decides tu; la unica que controlas es la ventana de mantenimiento del equipo del borde, que se retrasa precisamente porque parchearlo corta las sesiones VPN de todo el mundo. SEGUNDA TESIS: el parche cierra la puerta pero no echa a quien ya entro; el propio fabricante describe la remediacion como "a single-step process" (actualizar) sin mencionar sesiones, credenciales ni triaje, mientras CISA pide triaje forense en el mismo parrafo. Shadowserver ve mas de 22.000 NetScaler ADC y cerca de 1.800 Gateway expuestos a internet, cifra de superficie y no recuento de comprometidos](https://everywan.com/es/blog/netscaler-cve-2026-8452-de-denegacion-de-servicio-a-root) — 2026-08-28
- [Corosync suma 650 milisegundos por cada nodo: el reloj que tu cluster Proxmox actualizado sigue arrastrando. El tiempo que tarda un cluster Proxmox VE en rehacer la membresia despues de perder un nodo NO es fijo: crece con el tamano del cluster. Segun corosync.conf(5), el token por defecto son 3.000 ms, pero el valor real se calcula como token + (numero de nodos - 2) x token_coefficient, y ese coeficiente vale 650 ms por defecto; el consensus, si no se fija, se calcula automaticamente a 1,2 x token, y la suma de ambos es -en palabras de la documentacion de Proxmox- "the minimum time needed to reestablish a new cluster membership after a node goes offline". CALCULO PROPIO a partir de la formula oficial (contrastado con el ejemplo de la propia documentacion de Proxmox, token 4.950 y consensus 5.940 = 10,89 s, que corresponde a 5 nodos): 3 nodos 8,03 s; 5 nodos 10,89 s; 8 nodos 15,18 s; 12 nodos 20,90 s; 19 nodos 30,91 s; 26 nodos 40,92 s; 29 nodos 45,21 s. TESIS: ese numero creciente compite con uno que NO crece, los 60 segundos del watchdog de auto-fencing de Proxmox, y la propia documentacion pide mantener token+consensus por debajo de 45 segundos "to ensure that a new cluster membership is formed before the watchdog timeout of 60 seconds expires, which would trigger a node fence", con escala explicita: bajar el coeficiente es sugerido por encima de 30 s, recomendado por encima de 40 y fuertemente recomendado por encima de 45. HALLAZGO CENTRAL: la documentacion dice literalmente "Since Proxmox VE 9.2, new clusters are created with a lower token coefficient of 125 milliseconds explicitly set in /etc/pve/corosync.conf" - se escribe al CREAR el cluster, de modo que un cluster ACTUALIZADO de la rama 8 a la 9 (algo que mucha gente hace ahora porque Proxmox VE 8 llega a fin de soporte en agosto de 2026) conserva los 650 ms y no recibe ningun aviso; con 125 ms, el cluster de 29 nodos baja de 45,21 a 14,03 segundos. Comando para leer los valores reales: corosync-cmapctl | grep -Ew 'runtime.config.totem.token|runtime.config.totem.consensus'. Incluye los relojes de Ceph (osd_heartbeat_grace 20 s, mon_osd_down_out_interval 10 minutos, mon_osd_down_out_subtree_limit por defecto rack, la unidad mas pequena del mapa CRUSH que Ceph NO marcara out automaticamente) y seccion contrarian de cuando NO tocar corosync.conf: con 3 a 8 nodos la suma va de 8 a algo mas de 15 segundos y el valor de fabrica no es el problema](https://everywan.com/es/blog/corosync-650-milisegundos-por-cada-nodo) — 2026-08-28
- [Microsoft 365 Archive entra en las politicas de retencion: cumplimiento arriba, disponibilidad abajo. La entrada 561208 del roadmap de Microsoft 365 (creada 05-05-2026, modificada 25-08-2026, estado In development) anade una accion de ARCHIVADO a las politicas y etiquetas de retencion de Purview: preview en septiembre de 2026 y disponibilidad general en octubre de 2026. La descripcion oficial promete que el archivado basado en retencion mueve contenido inactivo a almacenamiento de bajo coste sin comprometer el cumplimiento y manteniendo el dato localizable, pero no dice nada sobre si el fichero se abre. La documentacion de Microsoft 365 Archive si lo dice: el contenido en el nivel frio ya no es directamente accesible para nadie. TESIS: archivar es una decision de DISPONIBILIDAD disfrazada de decision de almacenamiento, y entra en produccion por la puerta del cumplimiento, sin ventana de mantenimiento, sin canario y sin marcha atras rapida. Lista literal de aplicaciones que pueden mostrar mensajes de error incorrectos, no cargar o fallar con contenido archivado: Word y PowerPoint online, las apps moviles de Teams, OneDrive y SharePoint, el cliente de sincronizacion de OneDrive en macOS, Windows 10 y anteriores, equipos Windows sin actualizaciones frecuentes, Office de escritorio sin actualizar desde el 1 de marzo de 2026, Clipchamp y Power BI. La marcha atras es asimetrica: reactivar es gratis en SharePoint desde el 31 de marzo de 2025, pero un fichero reactivado no se puede volver a archivar durante 120 dias (cuatro meses). Precio: 0,05 dolares por GB y mes, facturado solo cuando el archivo mas el almacenamiento activo superan la cuota licenciada del tenant, de modo que si estas por debajo de cuota archivar no ahorra nada. Si el archivado se apaga o la facturacion no esta sana, el contenido sigue archivado pero vuelve a contar como almacenamiento activo. No archivable: OneNote, paginas de SharePoint, agentes y la biblioteca Site Assets. Archivar no es copiar: mueve la misma copia a un sitio mas barato, y el propio Microsoft dice que las politicas de retencion y borrado no afectan a la ventana de recuperacion de copias, que queda completamente aislada de ellas](https://everywan.com/es/blog/microsoft-365-archive-politicas-de-retencion) — 2026-08-28
- [En Ceph la capacidad no la marca el cluster: la marca el disco mas lleno. Por que un solo OSD que cruza el umbral full para las escrituras de todo el cluster aunque "ceph df" siga enseñando decenas de teras libres. LOS TRES UMBRALES, que se evaluan POR OSD y no sobre el total, con sus valores por defecto de la documentacion oficial de Ceph: mon_osd_nearfull_ratio 0,85, mon_osd_backfillfull_ratio 0,90 y mon_osd_full_ratio 0,95. Cita literal de la comprobacion OSD_FULL: "One or more OSDs have exceeded the full threshold and are preventing the cluster from servicing writes" -sujeto en singular, objeto en plural-. Matiz preciso: lo que se detiene son las escrituras de los pools con algun grupo de colocacion en ese OSD, que en un hiperconvergido con una sola regla CRUSH es todo. LA TESIS CENTRAL SOBRE EL ORDEN DE LOS UMBRALES: backfillfull (0,90) salta ANTES que full (0,95), y la cita literal de OSD_BACKFILLFULL dice "preventing data rebalancing to this OSD", asi que el mecanismo que REPARA se apaga cinco puntos antes que el que SIRVE; en un disco de 4 TB esos cinco puntos son unos 200 GB. POR QUE UN DISCO SE LLENA ANTES: CRUSH coloca por funcion determinista sobre pesos, no buscando hueco libre; el balanceador viene activado ("the default mode is upmap") pero iguala numero de grupos y no bytes, y tiene el requisito "to use upmap, all clients must be Luminous or newer". Regla de lectura: la media de ocupacion es el numero mas inutil del panel, manda el maximo de "ceph osd df". LA CUENTA DE CAPACIDAD CON UN NODO MENOS, calculo propio de everyWAN y no cifra publicada por Ceph: con dominio de fallo por nodo, la ocupacion en bruto antes del fallo no puede pasar de 0,95 x (N-1)/N para que no se paren las escrituras -> 4 nodos 71 %, 5 nodos 76 %, 6 nodos 79 %, 8 nodos 83 %, 10 nodos 85 %. PERO el numero que de verdad importa es 0,90 x (N-1)/N, porque por encima de la proyeccion de 0,90 Ceph se niega a enviar datos al OSD y los grupos se quedan en backfill_toofull, o sea que la reconstruccion NO termina y no se vuelve a active+clean -> 4 nodos 67 %, 5 nodos 72 %, 6 nodos 75 %, 8 nodos 78 %, 10 nodos 81 % (y la columna conservadora con 0,85: 63 / 68 / 70 / 74 / 76 %). Caso especial de TRES nodos con replica 3: al caer un NODO no quedan tres dominios distintos, Ceph no puede reconstruir y se queda degradado con el aviso literal de Proxmox "do not set a min_size of 1"; ahi quien muerde es el DISCO suelto, porque si muere un OSD con su nodo vivo sus grupos se recrean en los otros OSD del mismo nodo (con cuatro discos por nodo, x4/3 sobre los tres que quedan). Subir el umbral en caliente es legitimo como maniobra y ruinoso como estado: el propio OSD aplica osd_failsafe_full_ratio 0,97, asi que la maniobra es "ceph osd set-full-ratio 0.96" y no 0,97, que dejaria los dos umbrales pegados. CUATRO COMANDOS: ceph osd df (maximo %USE y columna VAR), ceph df (MAX AVAIL por pool, "a complicated function of the replication or the kind of erasure coding used, the CRUSH rule that maps storage to devices, the utilization of those devices, and the configured mon_osd_full_ratio setting"), ceph balancer status y ceph osd test-reweight-by-utilization en seco](https://everywan.com/es/blog/ceph-la-capacidad-la-marca-el-disco-mas-lleno) — 2026-08-27
- [Dos operadores no son redundancia si la IP la pone el operador: por que contratar una segunda linea salva el trafico SALIENTE pero no lo que entra. Las direcciones fijas que da un operador viven dentro de un bloque que solo el anuncia, asi que al conmutar al segundo enlace los servicios publicados no cambian de camino, cambian de direccion, y con ella caducan el TTL del DNS, se cortan las sesiones abiertas, dejan de negociar los tuneles montados contra IP y dejan de valer las listas blancas de terceros (banco, facturacion electronica, EDI). Las TRES opciones reales y que le pasa a la IP en cada una: dos lineas del mismo operador (la direccion se mantiene, no cubre fallo de la red del operador), dos operadores con rango propio cada uno (resuelve el saliente, el entrante se muda) y bloque propio anunciado por BGP a dos operadores (la direccion no se mueve). LA CUENTA CON CIFRAS DE 2026 del esquema de tarifas RIPE NCC ripe-848: 1.800 EUR/ano por cuenta LIR + 50 EUR por ASN + 75 EUR por asignacion de recurso independiente (PI IPv4/IPv6, anycast, IXP) + 1.000 EUR de alta; ~2.850 EUR el primer ano. El obstaculo no es el dinero: RIPE dice "While we have run out of IPv4 addresses, RIPE NCC members can still request a single /24 allocation" y solo para miembros que nunca recibieron asignacion, con lista de espera sin fecha; quedan el mercado de transferencias o ir en IPv6. Politica RIPE citada: "Current RIPE Policy requires a network to be multi-homed, and have a unique routing policy for an ASN to be assigned", y se puede tener ASN via LIR patrocinador sin la cuota anual. LO QUE NO ESTA EN EL PRESUPUESTO: la tabla global tenia 1.076.340 prefijos IPv4 activos en la muestra de las 11:01 UTC del 27-ago-2026 (informe de Geoff Huston, bgp.potaroo.net/as2.0/bgp-active.txt, consultado por everyWAN), lo que descarta el firewall pequeno salvo que pidas ruta por defecto o tabla parcial; y el RFC 4271 seccion 10 sugiere HoldTime por defecto de 90 segundos, KeepaliveTime a un tercio y 30 segundos de intervalo minimo entre anuncios en eBGP, asi que sin BFD ni temporizadores bajados la conmutacion se mide en minuto y medio. CUANDO NO HACE FALTA: si solo sale trafico, si todo lo publicado esta detras de un CDN o proxy inverso, o si nadie va a mantener los ROA y los filtros. Conflicto de interes declarado: everyWAN es operador con red propia, ASN, transito, peering y looking glass publico](https://everywan.com/es/blog/multihoming-bgp-ip-propia-dos-operadores) — 2026-08-27
- [El fallo de Gitea "requiere permiso de escritura" y el formulario de registro te lo da: por que la entrada de CISA para el CVE-2026-60004 dice "an attacker with repository write access" mientras el vector oficial del aviso de los mantenedores (GHSA-rcr6-4jqh-j84m) puntua 9,8 con CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, es decir privilegios requeridos NINGUNO. Las dos cosas son ciertas porque el propio aviso dice "With open registration enabled, the attack can be performed by an unauthenticated visitor after registering a normal account and creating a repository", y la documentacion oficial de Gitea trae en [service] DISABLE_REGISTRATION=false, REGISTER_EMAIL_CONFIRM=false y REQUIRE_SIGNIN_VIEW=false (el alta por OpenID va atada al mismo interruptor). Afecta de Gitea 1.17 a 1.27.0 inclusive; corregido el 27-jul-2026 en 1.27.1, que ademas cierra el CVE-2026-59774, lectura arbitraria de ficheros SIN autenticacion via la directiva #+INCLUDE de Org-mode. Mecanismo: el endpoint diffpatch aplica el parche en un clon bare temporal compartido; el mismo parche dos veces provoca una colision add/add y el fallback a tres vias de Git escribe a disco rutas del indice pese a --cached; en un clon bare la raiz del repositorio ES $GIT_DIR, asi que un ejecutable llamado hooks/post-index-change es un hook vivo que corre como la cuenta de servicio. Tres condiciones del disparo segun el aviso: Git 2.32+, ruta diffpatch habilitada y sistema de ficheros temporal escribible y ejecutable; el arreglo fue dejar de usar un clon bare. CISA lo anadio al catalogo KEV el 25-ago-2026 con fecha limite del 28 y valoracion SSVC explotacion activa / automatizable si / impacto tecnico total. Unico caso publico: relato autoinformado de un desarrollador en Habr recogido por Help Net Security y The Hacker News, con la parte activa del ataque en unos ONCE SEGUNDOS (registro, repositorio, exploit, ejecucion como usuario git dentro del contenedor, prueba escrita en una rama, cargador y una carga que solo PARECE un minero, sin familia ni cartera ni pool confirmados); lo destapo un correo del proveedor de alojamiento por CPU sostenida por encima del 70 %, no la monitorizacion propia. El contenedor no era privilegiado, asi que no hubo persistencia por cron, systemd ni claves SSH, pero la contencion limita la persistencia y no la confidencialidad: config y secretos de la aplicacion, credenciales y contenido de la base de datos, credenciales OAuth y de integraciones y repositorios montados quedaron legibles, por eso rotar secretos no admite esperar. Tesis everyWAN: cuando una ficha de CVE dice "requiere autenticacion" o "requiere permisos", la pregunta util no es SI los requiere sino QUIEN puede conseguirlos y en cuanto tiempo](https://everywan.com/es/blog/gitea-permiso-de-escritura-lo-da-el-formulario-de-registro) — 2026-08-27
- [Cuando NO migrar de VMware a Proxmox: los cinco casos en los que everyWAN recomienda quedarse, escrito por una empresa que hace esas migraciones y no vende licencias de ninguna de las dos plataformas. Dos objeciones clasicas han caducado en 2026: (1) "no tiene DRS" dejo de ser cierto el 21-may-2026 con Proxmox VE 9.2, cuya nota de prensa oficial describe el modo dinamico del cluster resource scheduler (CRS) incorporando la utilizacion de recursos de nodos e invitados en tiempo real a cada decision de colocacion y un balanceador integrado que migra automaticamente "guests managed by the High Availability (HA) stack" respetando las reglas de HA — matiz importante: solo mueve lo dado de alta como recurso HA; (2) "no hay copias de terceros serias" tampoco, porque Veeam soporta Proxmox VE desde 2024 y la version 13.1 (29-jul-2026) trae trabajos de replicacion, con el problema conocido literal de sus notas de version: "A replication job may fail if the source VM has disks whose size is not a multiple of the block size used by the target storage". La objecion que SI sigue en pie es el admission control: la documentacion de vSphere de Broadcom describe la politica de slots calculando cuantas maquinas caben si fallan N anfitriones y PREVINIENDO la operacion cuando la capacidad de conmutacion cae por debajo de la configurada, mientras que el capitulo de alta disponibilidad de Proxmox VE describe reglas de afinidad de nodo y recurso, prioridades y fencing con watchdog pero nada que reserve capacidad de failover. Ademas los valores de fabrica de datacenter.cfg mandan mas de lo que parece: crs ha=basic por defecto ("only the number of services is used", reparte contando maquinas), ha-auto-rebalance=0 por defecto (el balanceo automatico del titular no se activa solo), ha-rebalance-on-start=0, umbral 30% y hold duration 3 rondas. Los cinco casos para NO migrar: cuando la fecha la impone la renovacion y se pierde la ventana de vuelta atras; cuando el ERP o software critico tiene matriz de soporte de hipervisores y hay que pedirla por escrito; cuando nadie ha hecho la cuenta de la N-1 con la RAM instalada hoy; cuando el problema real no es el hipervisor sino una sola sala, copias sin restaurar y un RTO sin cronometrar; y cuando no hay quien mantenga Debian a las tres de la manana, con Proxmox VE 8 llegando a fin de soporte el 31-ago-2026](https://everywan.com/es/blog/cuando-no-migrar-de-vmware-a-proxmox) — 2026-08-26
- [Borraron las copias en los dos centros de datos: por que una sede de recuperacion que acepta las mismas credenciales no es una segunda sede. El aviso conjunto AA26-222A (#StopRansomware: Gunra Ransomware), publicado el 10-ago-2026 por el FBI, CISA, DC3, NSA, USSS y la policia nacional de Corea del Sur (KNPA), documenta que contra UNA de las victimas los actores borraron datos de copia y archivo almacenados en la infraestructura de copia tanto en el centro de datos principal como en el centro de recuperacion ante desastres, antes y despues de desplegar el cifrador ("against one Gunra victim", "in one instance" en la tabla de T1490). La cadena descrita: evasion de autenticacion en FortiOS/FortiProxy (CVE-2024-55591 y CVE-2025-24472, con parche desde principios de 2025) usada para abusar de tareas programadas y crear la cuenta de superusuario persistente forticloud-sync con contrasena fija; secretsdump.py de Impacket contra varios controladores de dominio para extraer hashes de los ficheros NTDS, con psexec.py y smbclient.py para movimiento lateral; modificacion de los ficheros de autenticacion del portal VDI para que una OTP elegida por el atacante siempre funcionara (T1556.006); acceso por SSH desde un escritorio virtual comprometido a un servidor de control de accesos Hiware y robo de su clave de cifrado simetrica, que descifraba las contrasenas de las cuentas de servidor de toda la empresa (T1555); exfiltracion a MEGA y de OneDrive/SharePoint con main.exe. Tesis propia de everyWAN: la redundancia se dibuja en cajas y cables pero se decide en quien puede entrar en cada caja, asi que dos sedes que aceptan la misma credencial son una sola sede con dos direcciones postales; la inmutabilidad protege los bloques dentro del plazo pero no impide desactivar trabajos, borrar puntos aun no retenidos ni perder el catalogo, y por eso la recomendacion del aviso es copias offline, inmutables, en ubicacion fisicamente separada y segmentada, y PROBADAS. Incluye la prueba del llavero, seis comprobaciones (credenciales que abren las dos sedes; contra que autentica el sistema de copias; donde vive el gestor de contrasenas o bastion; intentar de verdad borrar un punto de restauracion de la sede B con credenciales de la sede A, que tiene que fallar; una copia inalcanzable por red; y restaurar hoy con cronometro) y la declaracion honesta de que el aviso NO afirma que la clave robada sea lo que abrio el centro de recuperacion](https://everywan.com/es/blog/borraron-las-copias-en-los-dos-centros-de-datos) — 2026-08-26
- [Tu proveedor de identidad no es una aplicacion, es infraestructura: el 24-ago-2026 a las 03:38 CEST empezo un ataque de denegacion de servicio contra la plataforma digital compartida del Estado noruego (Digdir y su operador Vivicta) que a 26-ago llevaba mas de dos dias, con Kripos investigando los tres ataques del verano; cayeron diez servicios (ID-porten, MinID, Maskinporten, Altinn, eInnsyn, eFormidling, ELMA, Ansattporten, autoservicio, eSignering y el registro de contacto) y varios no tenian nada roto: Digdir escribe en su pagina de estado que eSignering estaba inaccesible por las limitaciones de ID-porten, que aun se podian crear encargos de firma pero no firmarlos, y que las soluciones estaban estables con las limitaciones que se habian puesto, es decir que parte de la caida era autoimpuesta como degradacion deliberada. Tesis: al concentrar la identidad, la puerta deja de ser una aplicacion (se compra, se parchea, se copia) y pasa a ser infraestructura (se dimensiona, se enruta, se degrada y se ensaya); un 99,9% anual son 8,76 horas de caida en todo el ano. Defensa explicita del inicio de sesion unico, traslacion a pyme (controlador de dominio unico con copia que necesita autenticarse contra el, o IdP en la nube sin cuenta local de emergencia) y tres preguntas: que deja de funcionar seis horas, por donde entras tu a arreglarlo y como se llama quien decide pasar al plan degradado](https://everywan.com/es/blog/tu-proveedor-de-identidad-no-es-una-aplicacion) — 2026-08-26
- [Con cifrar el 10 % del VMDK le basta: ransomware en el hipervisor y el reloj de la restauracion. El cifrador para ESXi de Kyber que Rapid7 desensamblo (analisis del 21-abr-2026 sobre una respuesta a incidente de marzo de 2026, dos binarios en la misma red con el mismo identificador de campana: ELF de 64 bits en C++ para ESXi y PE en Rust para Windows) trae un parametro de porcentaje validado entre 0 y 100 con valor observado 10: menos de 1 MB cifra el fichero entero, entre 1 y 4 MB el primer MB, y por encima de 4 MB solo una porcion proporcional, lo justo para dejar inservible un VMDK. El cifrado parcial no es nuevo (LockFile lo usaba a mediados de 2021 cifrando 16 bytes de cada 32 para burlar el analisis chi-cuadrado; luego Black Basta, ALPHV/BlackCat, PLAY, Agenda y Qyick). Secuencia en el host: esxcli vm process list y kill type=soft, sustitucion de /etc/motd y los dos index.html del Host Client por la nota, y despues cifrado con extension .xhsyw. En el hipervisor no hay agente porque Broadcom no lo soporta (articulo 330057: It is not supported to install 3rd Party Agents or Antivirus Software directly on the VMware vCenter Server Appliance (VCSA) or ESXi hosts); la defensa es plano de gestion (lockdown, con las puertas DCUI.Access y Exception Users que conservan DCUI, Shell y SSH incluso en lockdown estricto), execInstalledOnly (opcion interna activada por defecto desde ESXi 8.0, la de arranque no) y syslog remoto. La nota de rescate anuncia AES-256-CTR, X25519 y Kyber1024 pero el binario de ESXi usa ChaCha8 y RSA-4096. La variante Windows detiene servicios msexchange, vss, backup, veeam y sql y ejecuta wbadmin DELETE SYSTEMSTATEBACKUP. Cambiar a Proxmox no es un control de seguridad: Pay2Key Linux (Halcyon) trae logica propia para Proxmox con /etc/pve, pvesh get /cluster/resources, qm stop --skiplock, pct stop --skiplock y pvesh set --protected 0 antes de pvesh delete](https://everywan.com/es/blog/ransomware-cifra-el-10-por-ciento-del-vmdk) — 2026-08-25
- [El parche de agosto (.NET Framework, KB5120708 y hermanos) rompe imprimir y exportar a PDF en apps WPF con Calibri, Cambria, Constantia y Corbel: las tres salidas y lo que cuesta cada una](https://everywan.com/es/blog/parche-agosto-net-rompe-la-impresion-wpf) — 2026-08-25
- [Ransom Busters: el que te ofrece rescatarte es el que te cifro. El 18-ago-2026 el equipo de investigacion de GuidePoint (GRIT), en un articulo firmado por Justin Timothy, describio un correo no solicitado que reciben victimas de ransomware de un supuesto tercero llamado Ransom Busters LTD, que dice llevar mas de tres anos infiltrandose en los servidores de grupos criminales y ofrece borrar los datos robados y facilitar la clave por entre 20.000 y 60.000 dolares; al preguntarle, Ransom Busters confirmo tener acceso al mismo conjunto de datos robados que el afiliado responsable de la intrusion (su palabra, no una verificacion independiente), y las huellas forenses se repetian en los incidentes que analizo su equipo forense (SoftPerfect Network Scanner, s5cmd para exfiltrar a AWS, el RMM Remotely desplegado con PowerShell, cuenta de puerta trasera con la contrasena Numlock!123 y el hostname DESKTOP-BBETH6K), con actividad ligada a DragonForce, Settra y Anubis; GRIT valora con confianza moderada que es un unico afiliado que roba los pagos a las operaciones RaaS para las que trabaja y advierte de que pagar a cualquier parte criminal no da ninguna garantia de que los datos se borren. El dato que lo cambia todo es que los correos llegaron ANTES de que el incidente fuera publico, lo que convierte el correo en evidencia de exfiltracion y no en una oferta: protocolo de la primera manana (canal fuera del perimetro, portavoz unico, no responder, reenviar con cabeceras y hora, y la decision de pagar fuera de quien recibe el correo), con el contraste del sting de 2019 en el que Fabian Wosar (Emsisoft) se hizo pasar por cliente de una firma escocesa de recuperacion de datos que negociaba el rescate con el atacante y facturaba 3.950 dolares, cuatro veces lo pactado, publicado por ProPublica el 24-jun-2019](https://everywan.com/es/blog/ransom-busters-el-rescatador-es-el-que-te-cifro) — 2026-08-25
- [Teams ya puede bloquear los bots de tus reuniones y llega apagado: el aviso MC1459141 (21-ago-2026) anade un modo de bloqueo automatico de bots externos detectados al parametro ExternalBotAccessMode de Set-CsTeamsMeetingPolicy, con despliegue general de finales de agosto a finales de septiembre de 2026; la referencia de Microsoft Learn (actualizada el 24-ago-2026) todavia documenta solo dos valores, AllowAllBots y RequireApprovalWhenDetected (este ultimo es el valor por defecto desde el aviso MC1251206 del 13-mar-2026, que ya etiquetaba los bots y los mandaba al vestibulo), el tercer valor BlockDetectedBots hay que asignarlo por politica de reunion a usuarios o grupos, la deteccion se basa en senales de infraestructura y comportamiento (con falsos negativos y falsos positivos), y quedan fuera Copilot de Microsoft 365, las aplicaciones registradas en Entra ID y las reuniones convocadas desde el inquilino del cliente: por que el control que falta no es la puerta sino donde acaba la transcripcion, y cuando NO encender el bloqueo](https://everywan.com/es/blog/teams-bloquear-bots-reuniones-llega-apagado) — 2026-08-25
- [El 88% de las claves de AWS filtradas sigue funcionando: Truffle Security reverifico el 10-ago-2026 10.616 pares de credenciales expuestas en publico (de 431.875 hallazgos y 64.024 claves unicas) y el 88% seguia autenticando; de 817 claves atribuibles a una empresa, 526 eran de la cuenta raiz y 242 de usuarios IAM con AdministratorAccess (768, el 94%), y 130 claves raiz estaban en cuentas de gestion de AWS Organizations; mediana de antiguedad 1.831 dias, la mas vieja 17,4 anos (anterior a que IAM existiera: preview 2-sep-2010, GA 3-may-2011), solo el 13,7% rotadas, 929 usuarios con la politica AWSCompromisedKeyQuarantine (que deniega acciones pero NO invalida la clave), y aparte de ese recuento, en Hugging Face (que Truffle escanea por separado) hay 8.482 claves vivas en 3.394 conjuntos de datos publicos con un 17,9% de raiz, y solo el 9,5% de las cuentas tenia una alerta de presupuesto (mediana 8 dolares) pese a 420.631 dolares de gasto agregado en julio](https://everywan.com/es/blog/claves-aws-filtradas-siguen-funcionando) — 2026-08-23
- [Apagaron el EDR con un reinicio y el cifrado fallo por falta de memoria: cronologia del caso Akira del 4-ago-2026 documentado por Huntress (VPN SSL SonicWall sin MFA, rociado de credenciales a las 03:45 y acceso valido a las 03:52:42, RDP al controlador de dominio, volcado de AD con Get-ADUser, exfiltracion con WinRAR y s5cmd a un bucket S3, AnyDesk registrado en SafeBoot\Network, reinicio con BootMode=2 y SAFEBOOT:NETWORK que deja el host 1h41 sin EDR ni Defender en tiempo real, akira.exe caido por el evento 26 «Out of Virtual Memory»): por que el EDR no fallo sino que lo apagaron, por que el robo estaba hecho antes del cifrado y que senales dejar puestas (MFA en la VPN, alerta por evento 27 Kernel-Boot, correlacion de fallos y exito en VPN, silencio del agente como alarma)](https://everywan.com/es/blog/modo-seguro-apagaron-el-edr-con-un-reinicio) — 2026-08-22
- [El «protected» de Proxmox no es un candado, es un pestillo: el ransomware Pay2Key (variante Linux, ELF 64 bits) usa la propia API de Proxmox (pvesh get /cluster/resources, qm stop --skiplock, pvesh set ... --protected 0, pvesh delete) para apagar las VM y borrar los backups; leyendo pve-storage (Content.pm updateattributes/delete y check_volume_access en Storage.pm) se ve que quitar el flag protected no exige ni un permiso mas que borrar la copia, que en almacenamiento de fichero la proteccion es un sidecar .protected, y que la frontera real es el privilegio Datastore.Backup de PBS (crear pero no borrar), el prune en el servidor, un token por cluster acotado a namespace y la sincronizacion que no propaga borrados](https://everywan.com/es/blog/proxmox-protected-no-es-un-candado) — 2026-08-22
- [CVE-2026-19490 en NetScaler ADC y Gateway (CVSS v4 9,3, CWE-288, bypass de autenticacion pre-auth): la condicion previa depende de la build (14.1-43.56 y 13.1-61.28 o posteriores solo con accion SAML; builds anteriores basta con Gateway o AAA vserver), builds corregidas 14.1-73.32 y 13.1-63.21, las tres cadenas de configuracion a buscar y por que 22.000 aparatos expuestos no son 22.000 vulnerables](https://everywan.com/es/blog/cve-2026-19490-netscaler-la-version-no-te-dice-si-estas-expuesto) — 2026-08-22
- [El colocation ya no se negocia en U: se negocia en kW. Los neoclouds firmaron 420 MW de colocation en Europa en el primer semestre de 2026 (89 MW un ano antes) y el suelo con acometida en FLAP-D vale un 82% mas que en 2021: que revisar en tu contrato de alojamiento (kW por rack, tarifa plana o medida, derecho a crecer, densidad del pasillo, reubicacion, plazo)](https://everywan.com/es/blog/colocation-ya-no-se-negocia-en-u-sino-en-kw) — 2026-08-22
- [El parche que no es tuyo: el CVE-2026-69836 de Entra ID, un fallo critico que Microsoft parcheo por ti y que no puedes auditar (retencion de logs de Entra: 7 dias en Free, 30 en P1/P2)](https://everywan.com/es/blog/cve-2026-69836-el-parche-que-no-es-tuyo) — 2026-08-22
- [Un CVE ya no es un fallo: Cisco ha cambiado la unidad de medida](https://everywan.com/es/blog/cisco-ha-cambiado-lo-que-significa-un-cve) — 2026-08-21
- [Azure deja de incluir la licencia de VMware: la cuenta de núcleos que nadie hace](https://everywan.com/es/blog/azure-vmware-solution-deja-de-incluir-la-licencia) — 2026-08-21
- [Hay quien lleva desde el lunes sin poder buscar en Microsoft 365. Para el SLA, eso no es una caída](https://everywan.com/es/blog/buscador-microsoft-365-roto-sla-no-es-una-caida) — 2026-08-21
- [El directorio tiene más fichas que empleados](https://everywan.com/es/blog/directorio-entra-mas-fichas-que-empleados) — 2026-08-18
- [Cinco días, el título de un issue y un token de Jira](https://everywan.com/es/blog/github-actions-titulo-de-issue-token-de-jira) — 2026-08-18
- [El parche de Android no llega al módem](https://everywan.com/es/blog/el-parche-de-android-no-llega-al-modem) — 2026-08-18
- [La copia de Microsoft 365 que nunca sale de Microsoft](https://everywan.com/es/blog/copia-microsoft-365-nunca-sale-de-microsoft) — 2026-08-17
- [Un 5 % más por pagar al mes: qué cambia el 1 de octubre y cuándo no conviene cambiarse](https://everywan.com/es/blog/microsoft-csp-recargo-5-por-ciento-pago-mensual) — 2026-08-17
- [Entraron por el puerto 5900 y salieron con root: el minero era lo de menos](https://everywan.com/es/blog/cve-2026-65400-puerto-5900-mac-con-root) — 2026-08-17
- [Tus servidores los puede apagar alguien con quien no has firmado nada](https://everywan.com/es/blog/quien-puede-apagar-tus-servidores) — 2026-08-16
- [Bloquear el agente SSH desactivaba sus propias restricciones](https://everywan.com/es/blog/bloquear-agente-ssh-desactivaba-restricciones) — 2026-08-16
- [Proxmox VE 8 caduca en agosto: Debian te seguirá parcheando, el hipervisor no](https://everywan.com/es/blog/proxmox-ve-8-caduca-en-agosto-apt-no-lo-dira) — 2026-08-16
- [Redundancia no es diversidad de ruta: dos cables, el mismo fin de semana](https://everywan.com/es/blog/redundancia-no-es-diversidad-de-ruta) — 2026-08-15
- [Tres días para parchear, y el tercero cae en sábado](https://everywan.com/es/blog/tres-dias-para-parchear-y-el-tercero-cae-en-sabado) — 2026-08-15
- [Un .es caducado se libera en diez días. Un .com puede darte ochenta](https://everywan.com/es/blog/dominio-es-caducado-diez-dias-dropcatch) — 2026-08-15
- [El informe dice «cero impactos» y no quiere decir que nadie lo use](https://everywan.com/es/blog/baseline-security-mode-informe-cero-impactos) — 2026-08-14
- [El último parche que va a recibir tu SharePoint 2016 se publicó el 14 de julio](https://everywan.com/es/blog/cve-2026-55040-sharepoint-el-ultimo-parche) — 2026-08-14
- [Se llamaba .png y por dentro era PostScript: el fallo de WordPress 7.0.4](https://everywan.com/es/blog/wordpress-7-0-4-png-que-era-postscript) — 2026-08-14
- [El fallo de Cisco que no roba nada: solo reinicia la puerta por la que entra tu gente](https://everywan.com/es/blog/cve-2026-20349-el-fallo-que-no-roba-nada) — 2026-08-14
- [Ceph no rinde lo que pone en la ficha del disco: rinde lo que midió el OSD al arrancar](https://everywan.com/es/blog/ceph-no-rinde-lo-que-pone-en-la-ficha-del-disco) — 2026-08-13
- [El aviso de vCenter decía que no había explotación conocida: duró cinco días](https://everywan.com/es/blog/vcenter-sin-explotacion-conocida-duro-cinco-dias) — 2026-08-13
- [El DNS que hay que parchear es tu controlador de dominio](https://everywan.com/es/blog/el-dns-que-hay-que-parchear-es-tu-controlador-de-dominio) — 2026-08-13
- [Cruzaron de un parque eólico a la turbina de una central por la APN privada del operador](https://everywan.com/es/blog/apn-privada-del-operador-quien-mas-esta-dentro) — 2026-08-12
- [Tres ajustes deciden si Claude procesa tus documentos en Copilot, y uno lo decidió la fecha de tu tenant](https://everywan.com/es/blog/copilot-anthropic-tres-ajustes-fecha-de-tu-tenant) — 2026-08-12
- [La HA de Proxmox no evita la caída: la acorta (y a veces la provoca)](https://everywan.com/es/blog/ha-proxmox-no-evita-la-caida-la-acorta) — 2026-08-12
- [DeadLock no rompe tu antivirus: lo para como un servicio más](https://everywan.com/es/blog/deadlock-apaga-el-antivirus-antes-de-cifrar) — 2026-08-11
- [RTO y RPO sin humo: dos números que se firman sin haberlos calculado](https://everywan.com/es/blog/rto-rpo-sin-humo-numeros-que-nadie-calcula) — 2026-08-11
- [Migrar de VMware a Proxmox: el plan de vuelta atrás caduca solo](https://everywan.com/es/blog/migracion-vmware-proxmox-plan-de-vuelta-atras) — 2026-08-11
- [Cuando CISA avisó del LoadMaster, el parche llevaba 64 días publicado](https://everywan.com/es/blog/loadmaster-cve-2026-8037-64-dias-antes-del-aviso) — 2026-08-11
- [Esa grabación está en el OneDrive de alguien que ya no trabaja aquí](https://everywan.com/es/blog/grabacion-reunion-onedrive-de-alguien-que-ya-no-esta) — 2026-08-10
- [ChainDrop: 444 paquetes de npm comprometidos y ni un solo parche que aplicar](https://everywan.com/es/blog/chaindrop-npm-444-paquetes-sin-parche) — 2026-08-10
- [Metabase: el panel de datos que también era el llavero](https://everywan.com/es/blog/metabase-panel-de-datos-que-tambien-era-el-llavero) — 2026-08-10
- [El malware de macOS que no explota nada: lo pegas tú en la Terminal](https://everywan.com/es/blog/malware-macos-lo-pegas-tu-en-la-terminal) — 2026-08-09
- [Entra Connect: la fecha que te para la sincronización y la que solo te manda un correo](https://everywan.com/es/blog/entra-connect-cloud-sync-30-septiembre-2026) — 2026-08-09
- [Nadie explotó nada: quién verifica que eres tú antes de resetear tu MFA](https://everywan.com/es/blog/ingenieria-social-helpdesk-quien-verifica-que-eres-tu) — 2026-08-09
- [Secure Boot caducó en junio y no se cayó nada. Ese es el problema](https://everywan.com/es/blog/secure-boot-caduco-en-junio-y-no-se-cayo-nada) — 2026-08-08
- [Cross-tenant recall: Exchange Online deja que otra empresa borre correo de tus buzones](https://everywan.com/es/blog/cross-tenant-recall-exchange-online-otro-borra-tu-correo) — 2026-08-08
- [Zapscape y SCTPhantom: tu Proxmox no lleva el kernel de Debian](https://everywan.com/es/blog/zapscape-sctphantom-proxmox-no-lleva-el-kernel-de-debian) — 2026-08-08
- [cPanel CVE-2026-58048: en el hosting compartido, el riesgo lo pone el vecino](https://everywan.com/es/blog/cpanel-cve-2026-58048-el-riesgo-lo-pone-el-vecino) — 2026-08-07
- [Fast EC llega apagado: el interruptor de Ceph Tentacle que solo gira una vez](https://everywan.com/es/blog/fast-ec-llega-apagado-ceph-tentacle) — 2026-08-07
- [Tu servidor de copias está dentro del dominio que tiene que restaurar](https://everywan.com/es/blog/servidor-de-copias-en-el-dominio-dependencia-circular) — 2026-08-07
- [RPKI no impide que te secuestren la ruta: firmar el origen no asegura el camino](https://everywan.com/es/blog/rpki-no-impide-que-te-secuestren-la-ruta) — 2026-08-06
- [El Excel de tu red miente: cómo montamos una fuente de verdad con NetBox](https://everywan.com/es/blog/netbox-fuente-de-verdad-red-excel-miente) — 2026-08-06
- [Proxmox en Arm no amplía tu clúster: te obliga a tener dos](https://everywan.com/es/blog/proxmox-arm64-no-amplia-tu-cluster-te-obliga-a-dos) — 2026-08-06
- [Si el descifrado falla, el mensaje pasa igual](https://everywan.com/es/blog/tomcat-cve-2026-34486-control-que-falla-abriendo) — 2026-08-05
- [El piloto de IA que nadie apagó ya es producción](https://everywan.com/es/blog/piloto-ia-que-nadie-apago-langflow-n8n-produccion) — 2026-08-05
- [El AI Act ya te aplica. Y no por lo que salió en los titulares](https://everywan.com/es/blog/ai-act-2-agosto-2026-que-te-aplica-de-verdad) — 2026-08-05
- [WireGuard o IPsec: qué ponemos en cada sitio](https://everywan.com/es/blog/wireguard-vs-ipsec-cuando-usar-cada-uno) — 2026-08-04
- [Tu passkey no se rompe: se copia la llave maestra](https://everywan.com/es/blog/passkeys-llave-maestra-32-bytes-pass-ta-key) — 2026-08-04
- [El agente que instalamos en tus equipos también es una puerta](https://everywan.com/es/blog/agente-rmm-proveedor-it-superficie-de-ataque) — 2026-08-04
- [El plan B caduca el 31 de octubre: se acaba el VMware con licencia incluida en la nube](https://everywan.com/es/blog/fin-licencia-vmware-incluida-nube-31-octubre-2026) — 2026-08-03
- [Un 9,5 en Rails: el fallo no está en tu aplicación, está en la biblioteca que nadie eligió](https://everywan.com/es/blog/cve-2026-66066-rails-la-biblioteca-que-nadie-eligio) — 2026-08-03
- [Tu CI/CD tiene las llaves de producción. Y lo tratas como una herramienta de desarrollo](https://everywan.com/es/blog/ci-cd-llaves-de-produccion-teamcity-cve-2026-63077) — 2026-08-03
- [La mitad de la IT corporativa ya vive fuera de casa. Eso no significa que se fue a la nube](https://everywan.com/es/blog/mitad-it-corporativa-fuera-de-casa-no-es-la-nube) — 2026-08-02
- [Lo que nadie abre, se borra: Purview, el último acceso y los 93 días para enterarte](https://everywan.com/es/blog/purview-retencion-ultimo-acceso-no-es-backup) — 2026-08-02
- [El token que no pide MFA: las apps conectadas a tu Microsoft 365](https://everywan.com/es/blog/token-no-pide-mfa-apps-conectadas-microsoft-365) — 2026-08-02
- [Google ha arreglado 1.072 fallos de Chrome con IA: el cuello de botella ahora eres tú](https://everywan.com/es/blog/chrome-1072-fallos-ia-ritmo-de-parcheo) — 2026-08-01
- [Tu SD-WAN no se cae: te lo reconfiguran](https://everywan.com/es/blog/sd-wan-no-se-cae-te-lo-reconfiguran) — 2026-08-01
- [EWS se apaga en octubre, pero tu fecha límite es el 31 de agosto](https://everywan.com/es/blog/ews-exchange-online-fecha-limite-31-agosto) — 2026-08-01
- [Windows 10 y el peaje de octubre: el ESU se duplica cada año y no puedes saltarte el año uno](https://everywan.com/es/blog/windows-10-esu-octubre-2026-peaje-que-se-duplica) — 2026-07-31
- [Tu Ceph tiene fecha: Squid se queda sin parches el 19 de septiembre](https://everywan.com/es/blog/ceph-squid-fin-de-soporte-19-septiembre-2026) — 2026-07-31
- [Restaurar no es recuperar: dos de cada tres salen de la copia y casi la mitad paga igual](https://everywan.com/es/blog/informe-ransomware-2026-restaurar-no-es-recuperar) — 2026-07-31
- [Tres milisegundos y 44 grados: la caída de nube que no fue de software](https://everywan.com/es/blog/caida-google-cloud-julio-2026-energia-refrigeracion-datacenter) — 2026-07-30
- [Dos 9,8 en vCenter, un escape de VM y el fallo que nadie va a mirar](https://everywan.com/es/blog/vmsa-2026-0006-vcenter-esx-que-parchear-primero) — 2026-07-30
- [La adolescencia de la tecnología: leímos el ensayo de Dario Amodei con las manos en el barro](https://everywan.com/es/blog/adolescencia-tecnologia-amodei-estamos-preparados) — 2026-07-30
- [Dentro de tu servidor hay otro ordenador, y 36.872 están en internet](https://everywan.com/es/blog/bmc-ipmi-expuestos-el-ordenador-que-nadie-mantiene) — 2026-07-30
- [Zabbix 8.0: qué cambia de verdad y qué es todavía una diapositiva](https://everywan.com/es/blog/zabbix-8-0-que-cambia-de-verdad) — 2026-07-30
- [Microsoft 365 ya ha subido: el porcentaje que asusta no es el que te cuesta dinero](https://everywan.com/es/blog/microsoft-365-subida-precios-julio-2026-cuenta-real) — 2026-07-30
- [Proxmox VE 8 se queda sin parches en agosto: por qué no vamos a actualizar el día 30](https://everywan.com/es/blog/proxmox-ve-8-fin-de-soporte-agosto-2026) — 2026-07-29
- [NIS2 en España: la ley aún no está, el cuestionario de tu cliente sí](https://everywan.com/es/blog/nis2-espana-ley-cuestionario-proveedor) — 2026-07-29
- [Parchear no es limpiar: FortiOS y la barra de más](https://everywan.com/es/blog/fortios-symlink-parchear-no-es-limpiar) — 2026-07-29
- [Tu monitorización no está rota: está gritando](https://everywan.com/es/blog/fatiga-de-alertas-monitorizacion-que-si-avisa) — 2026-07-29
- [Proxmox entra en el ecosistema de NVIDIA: el logo no migra tu infraestructura](https://everywan.com/es/blog/proxmox-nvidia-mission-control-el-logo-no-migra-tu-infraestructura) — 2026-07-28
- [El orquestador de tu WAN está en Internet por diseño: el 10.0 de VeloCloud](https://everywan.com/es/blog/velocloud-cve-2026-16812-orquestador-expuesto-por-diseno) — 2026-07-28
- [Azure deja de incluir la licencia de VMware: la cuenta de núcleos que nadie hace](https://everywan.com/es/blog/azure-vmware-solution-deja-de-incluir-la-licencia) — 2026-08-21: fin del modelo con licencia incluida en Azure VMware Solution, con las reglas de conteo de la referencia de licenciamiento de VCF portátil de Microsoft Learn (artículo del 14-ago-2026, actualizado el 17). Cuatro fechas: 15-oct-2025 congela los núcleos de cortafuegos vDefend cubiertos; 1-nov-2025 los despliegues nuevos exigen VCF portátil y Microsoft deja de incluir licencia con las compras de nodos nuevos; 31-oct-2026 los despliegues de pago por uso con licencia incluida deben haber migrado; 30-ago-2027 las reservas hay que cambiarlas por reservas BYOL o sacar las cargas. Aviso clave: si una reserva vence antes del 30-ago-2027, el beneficio de licencia incluida acaba ese día, así que la fecha que manda es la de cada reserva. Núcleos por host: AV36 y AV36P 36, AV48 48, AV52 52, AV64 64 (3 AV64 = 192; mixta de 3 incluidos + 4 BYOL = 252 desplegados y 144 registrados). El cortafuegos distribuido vDefend cuenta TODOS los núcleos de host de la nube privada, incluidos los de licencia incluida (10 AV36P = 360), y se considera activado con una política de DFW no predeterminada o un perfil IPFIX; el de pasarela se cuenta como edges × vCPU × 4 (96 con tres edges grandes, 128 con cuatro). Cálculo propio: 360 + 360 = 720 suscripciones de núcleo para diez hosts AV36P, condicionado a una nube privada nueva y entera en BYOL. No conformidad: la nube privada queda «at risk of suspension» y Microsoft puede suspenderla. Microsoft informa mensualmente a Broadcom de los registros BYOL y datos de cliente asociados. Pruebas de tres nodos: 60 días, clave de prueba de Broadcom obligatoria y hosts facturados automáticamente al terminar. Registros antiguos por correo: había que rehacerlos por el portal antes del 31-mar-2026. El post NO da precios por núcleo porque los que circulan no salen de una tarifa pública de Broadcom.
- [Hay quien lleva desde el lunes sin poder buscar en Microsoft 365. Para el SLA, eso no es una caída](https://everywan.com/es/blog/buscador-microsoft-365-roto-sla-no-es-una-caida) — 2026-08-21: el incidente MO1456424 del centro de mensajes de Microsoft 365 («Some users may be unable to search for content in SharePoint Online, OneDrive, Outlook on the web, or Outlook desktop»), abierto desde el lunes 17-ago-2026, causado según Microsoft porque «a recent deployment introduced a resource utilization inefficiency issue», sin relación con ningún ciberataque. Tesis propia: ninguna de las tres definiciones de Downtime del SLA consolidado de servicios en línea de Microsoft (edición del 10-ago-2026) cubre la búsqueda — SharePoint Online mide «unable to read or write», Exchange Online «unable to send or receive email with Outlook Web Access» y OneDrive «unable to view or edit files» —, así que cinco días de buscador inútil suman cero minutos de caída y no generan crédito de servicio. Aritmética: 44.640 minutos en un mes de 31 días, 44,5 minutos para bajar del 99,9 % y 446 para bajar del 99 %; el crédito además hay que reclamarlo antes del final del mes natural siguiente al del incidente. Accionable: comprobación sintética de resultado (documento testigo con palabra única + consulta programada contra la API de búsqueda de Graph que debe devolver exactamente 1) en lugar de comprobaciones de disponibilidad, y la pregunta de renovación «¿qué define tu proveedor como caída y qué degradaciones deja fuera?».
- [«La columna estaba cifrada»: pgcrypto guardaba texto plano y nadie se enteraba](https://everywan.com/es/blog/pgcrypto-la-columna-cifrada-que-guardaba-texto-plano) — 2026-08-20: CVE-2026-14663, corregida en el lote de PostgreSQL del 13-ago-2026 (18.6, 17.11, 16.15, 15.19 y 14.24; 28 CVE y más de 110 fallos; la 18.5 no llegó a publicarse por una regresión). Cuando OpenSSL rechazaba el algoritmo pedido —proveedor legacy sin cargar para Blowfish o CAST5, o modo FIPS para 3DES—, pgcrypto no comprobaba el error y hacía XOR del texto con un bloque sin cifrar: el dato quedaba legible en la columna y el descifrado funcionaba incluso con la clave equivocada. Afecta a pgp_sym_encrypt, pgp_pub_encrypt, sus variantes _bytea y las funciones de descifrado; el algoritmo por defecto (aes128) no está afectado. El parche ahora falla al descifrar esos mensajes y añade la opción ignore-cipher-failure para rescatarlos, que exige el mismo OpenSSL con el que se crearon. Comprobación propia del 20-ago: PGDG ya sirve 14.24, 15.19, 16.15, 17.11 y 18.6 para bookworm y trixie, mientras que el repositorio principal de Debian 13 sigue en 17.10-0+deb13u1 y el arreglo viaja por trixie-security (DSA-6438-1); bookworm, por DLA-4740-1; PostgreSQL 13 en bullseye figura sin versión corregida.
- [Ceph parchea cuatro CVE: tres los cierra el paquete y el cuarto lo cierras tú](https://everywan.com/es/blog/ceph-cuatro-cve-el-paquete-cierra-tres) — 2026-08-20: el aviso [URGENT] de Ceph del 19-ago-2026 (Squid 19.2.6 y Tentacle 20.2.4) con cuatro CVE: CVE-2025-30156 (AES-CBC sin autenticar en CephX, bitflip sobre el campo allow_all del AuthTicket), CVE-2026-50152 (cualquier clave con «mon allow r» leía el config-key store del monitor, con las passphrases LUKS de los OSD y la clave SSH de cephadm), CVE-2026-39944 (tokens STS de RGW) y CVE-2026-54330 (verificador SigV4 de RGW). Por qué el paquete no cierra el de CephX: hay que rotar cada clave al tipo nuevo aes256k, nueve pasos manuales, seis avisos de salud AUTH_INSECURE_*. Comprobación propia: los repositorios de Ceph de Proxmox seguían el 20-ago en 19.2.5-pve2 y 20.2.2-pve1, y Proxmox no usa cephadm, así que la rotación es entera a mano.
- [«Explotación menos probable»: 126 días de cola para el CVE-2026-33824](https://everywan.com/es/blog/cve-2026-33824-explotacion-menos-probable) — 2026-08-20: el fallo de ejecución remota en las extensiones IKE de Windows (double free, CVSS 9,8, UDP 500 y 4500) que Microsoft parcheó el 14-abr-2026 con la etiqueta «Exploitation Less Likely» y CISA añadió al catálogo KEV el 18-ago-2026. Recuento propio de las 24 entradas de Microsoft en KEV en 2026: cuando la etiqueta dice «Exploitation Detected» la mediana hasta KEV es de cero días, y cuando dice «Less Likely» son 41, 64, 126 y 153. Por qué la mitigación de restringir a «known peer addresses» no se puede aplicar a una VPN de acceso remoto.
- [Proxmox ya corre en Arm. Tus máquinas x86, no.](https://everywan.com/es/blog/proxmox-en-arm-tus-maquinas-x86-no-se-mudan) — 2026-08-19: Proxmox VE 9.2 para arm64 (5-ago-2026) leído contra sus propias notas de versión: los invitados solo corren en nodos de su arquitectura y la migración en vivo solo va entre iguales, el soporte pleno es para NVIDIA Grace y Vera (el resto, best-effort), las suscripciones arm64 son producto aparte sin tarifa publicada, y no hay edición de Windows Server para Arm64 de disponibilidad general.
- [Clonar el repositorio no es tener copia de GitLab](https://everywan.com/es/blog/clonar-el-repositorio-no-es-copia-de-gitlab) — 2026-08-19: el parche crítico de GitLab del 17 de agosto (CVE-2026-19478, 9,4) como percha para lo que un `git clone` no se lleva, por qué `gitlab-secrets.json` queda fuera de la copia, por qué solo se restaura sobre la misma versión y qué se pierde si parcheas siguiendo boletines de CVE.
- [Tu documentación te miente. Y tus validaciones, también](https://everywan.com/es/blog/tu-documentacion-de-infraestructura-te-miente): un documento no envejece, caduca, y lo hace en silencio. Estados de evidencia, supersesión sin borrar y sondas de frescura con tres respuestas. Herramienta publicada como software libre con licencia Apache-2.0.
- [El mejor parche para 7-Zip es desinstalarlo (en la mayoría de tus PCs)](https://everywan.com/es/blog/7-zip-cve-2026-14266-mejor-parche-desinstalarlo) — 2026-07-28
- [La IA se ha llevado la RAM: qué hacer con tu plan de hardware en 2026](https://everywan.com/es/blog/precio-memoria-ram-servidores-2026-ia) — 2026-07-28
- [«latest» no es una versión: tres lecciones de desplegar nuestra propia web con Docker Swarm](https://everywan.com/es/blog/latest-no-es-una-version-despliegues-docker-swarm) — 2026-07-27
- [Cl0p no ha cifrado ni un fichero: la extorsión entra por la aplicación que nadie vigila](https://everywan.com/es/blog/clop-windchill-extorsion-sin-cifrar) — 2026-07-27
- [SD-WAN sí, pero no en todas partes: cuándo compensa y cuándo sobra](https://everywan.com/es/blog/sd-wan-cuando-compensa-y-cuando-sobra) — 2026-07-26
- [La Wi-Fi del hotel trabaja para otro: secuestran el DNS para robar cuentas de Microsoft 365](https://everywan.com/es/blog/secuestro-dns-wifi-hoteles-microsoft-365) — 2026-07-26
- [El cloud no es caro: es caro para la carga equivocada. Colocation vs cloud público, con la cuenta hecha](https://everywan.com/es/blog/colocation-vs-cloud-publico-la-cuenta-a-cinco-anos) — 2026-07-26
- [Al becario que no se cansa lo ha fichado el otro bando: una IA autónoma ya automatiza ataques reales](https://everywan.com/es/blog/agente-ia-automatiza-ataque-deteccion-respuesta) — 2026-07-25
- [Certighost: un usuario cualquiera podía ser tu Domain Controller. La pregunta no es si parcheaste, es si has auditado tu AD CS](https://everywan.com/es/blog/certighost-ad-cs-auditoria-directorio-activo) — 2026-07-25
- [Microsoft retira el SMS como MFA: en febrero de 2027 Entra ID deja de enviarlos. Lo raro es que haya durado tanto](https://everywan.com/es/blog/microsoft-entra-retira-sms-mfa-passkeys) — 2026-07-25
- [Erasure coding promete el doble de espacio que réplica 3 en Ceph. La cuenta completa dice otra cosa](https://everywan.com/es/blog/ceph-replica-3-vs-erasure-coding-la-cuenta-completa) — 2026-07-24
- [Microsoft 365 se cayó otra vez: no puedes hacer DR de Teams (pero sí puedes tener plan)](https://everywan.com/es/blog/caida-microsoft-365-julio-2026-plan-continuidad) — 2026-07-24
- [El zero-day de Check Point no iba a por tu firewall: iba a por su consola](https://everywan.com/es/blog/zero-day-check-point-smartconsole-plano-gestion) — 2026-07-24
- [SharePoint 2016 y 2019 se han quedado sin parches, y esta vez no hay prórroga que pagar](https://everywan.com/es/blog/fin-soporte-sharepoint-2016-2019-migracion) — 2026-07-23
- [Tu firewall no para un DDoS: el último récord fue de 31,4 Tbps. La mitigación de verdad se hace aguas arriba](https://everywan.com/es/blog/anti-ddos-rtbh-firewall-no-salva-tu-enlace) — 2026-07-23
- [El malware ya no te engaña a ti: engaña a tu IA. FakeGit, 7.600 repositorios falsos en GitHub](https://everywan.com/es/blog/fakegit-agentbaiting-malware-agentes-ia) — 2026-07-23
- [Borraron el registro de la propiedad de Rumanía, backups incluidos. Lo salvó la copia que el atacante no podía tocar](https://everywan.com/es/blog/rumania-registro-propiedad-borrado-backup-inmutable) — 2026-07-22
- [Dos años de Broadcom: el éxodo masivo de VMware que no fue (y lo que sí está pasando)](https://everywan.com/es/blog/vmware-broadcom-dos-anos-despues-exodo-que-no-fue) — 2026-07-22
- [wp2shell: WordPress parcheó el viernes, los exploits llegaron el domingo. ¿Quién mantiene tu web?](https://everywan.com/es/blog/wp2shell-wordpress-quien-mantiene-tu-web) — 2026-07-22
- [Agentes de IA en la empresa: Gartner prevé que más del 40% de los proyectos se cancelará antes de 2028 (y no será culpa de la IA)](https://everywan.com/es/blog/agentes-ia-empresa-40-por-ciento-cancelados) — 2026-07-21
- [22 días dentro: los zero-days de SonicWall SMA 1000 y por qué la VPN perimetral ya no es la defensa, es el objetivo](https://everywan.com/es/blog/zero-days-sonicwall-sma-1000-vpn-perimetral) — 2026-07-21
- [AWS se cayó otra vez el 16 de julio: ocho horas que explican para qué sirve (de verdad) un plan de disaster recovery](https://everywan.com/es/blog/caida-aws-cloudfront-julio-2026-disaster-recovery) — 2026-07-21
- [622 parches en un solo martes: el récord de Microsoft y por qué priorizar por CVSS es un error](https://everywan.com/es/blog/patch-tuesday-julio-2026-622-parches) — 2026-07-20
- [Hardening de Proxmox VE 9.2 en producción: el checklist que aplicamos a cada cluster](https://everywan.com/es/blog/hardening-proxmox-9-2-produccion) — 2026-07-20
- [Proxmox integra Zabbix: monitorización oficial para tu infraestructura virtualizada](https://everywan.com/es/blog/proxmox-integra-zabbix-monitorizacion-oficial) — 2026-07-03
- [VMware + Broadcom en 2026: Guía de Supervivencia para CIOs y CTOs](https://everywan.com/es/blog/vmware-broadcom-guia-supervivencia-cios-2026) — 2026-04-20
- [Cómo Migramos +500 VMs de VMware a Proxmox Sin Parar el Negocio](https://everywan.com/es/blog/como-migramos-500-vms-vmware-proxmox) — 2026-04-18
- [Proxmox vs VMware en 2026: Comparativa Real con Números (No Marketing)](https://everywan.com/es/blog/proxmox-vs-vmware-comparativa-real-numeros) — 2026-04-15
- [SmokePing en Docker: monitorización de latencia y pérdida de paquetes con interfaz moderna](https://everywan.com/es/blog/smokeping-docker-everywan) — 2026-02-05
- [Anatomía de un Sistema de Ticketing de Alta Demanda: Cómo el LUX Tour de Rosalía vendió 142.000 entradas sin colapsar](https://everywan.com/es/blog/anatomia-sistema-ticketing-rosalia-lux-tour) — 2026-01-09
- [¡Archivo de 19MB que paralizó el 20% de Internet! La caída global de Cloudflare que dejó sin servicio a X, ChatGPT y medio mundo](https://everywan.com/es/blog/cloudflare-caida-global-18-noviembre-2025) — 2025-11-19
- [Proxmox Datacenter Manager 1.0: La revolución de la gestión centralizada de infraestructura virtual](https://everywan.com/es/blog/proxmox-datacenter-manager-1-0-estable) — 2025-01-20


## Empresa / Company
- [Quiénes somos / About us](https://everywan.com/es/quienes-somos)
- [Contacto / Contact](https://everywan.com/es/contacto)
- [Política de privacidad / Privacy policy](https://everywan.com/es/privacidad-de-datos)
- [Aviso legal / Legal notice](https://everywan.com/es/condiciones-de-uso)

## Contacto / Contact
- Email: info@everywan.com
- Tel: +34 938 748 686
- Dirección / Address: Carrer Pica d'Estats 77-95, Polígon Industrial Sant Isidre, 08272 Sant Fruitós de Bages (Barcelona), España

## Notas / Notes
- Sitemap: https://everywan.com/sitemap.xml
- Idiomas / Languages: es (default), ca, en — con hreflang en todas las páginas / with hreflang on every page.