CISA alerta de credenciales embebidas en relés Schneider Easergy MiCOM Px40: el fallo no tumba la red, pero sí abre una puerta que no debería existir

Una credencial embebida en un relé de protección no suena, de entrada, a gran catástrofe. CVSS 5,3, exposición limitada a “información básica del dispositivo” por SNMP, nada de impacto directo en integridad o disponibilidad. Sobre el papel, un incidente de gravedad media. En una subestación, una red de distribución o un entorno industrial con años de deuda técnica encima, la historia cambia bastante.

Eso es lo que hay detrás del aviso publicado por CISA este julio de 2026 para la serie Schneider Electric Easergy MiCOM Px40, identificado como ICSA-26-190-03. La vulnerabilidad es CVE-2026-4832, clasificada como CWE-798 Use of Hard-coded Credentials. El problema: un atacante no autenticado puede interrogar el puerto SNMP y obtener acceso no autorizado a información sensible del dispositivo. Schneider lo describe como exposición de “basic device identification”. Esa expresión, tan tranquilizadora en apariencia, merece traducción a lenguaje operativo: modelo, versión, identidad del equipo y otros metadatos que facilitan inventario hostil, fingerprinting y preparación de ataques posteriores.

No es un detalle menor. Los relés de protección no son periféricos decorativos; son equipos que participan en funciones de protección eléctrica de media, alta y extra alta tensión. El propio aviso sitúa el producto en sectores de energía, transporte y fabricación crítica. Quien haya visto una red OT real sabe que el reconocimiento es la mitad del trabajo. A veces más.

La lista de versiones afectadas es amplia: P14x anteriores a B4A, P24x anteriores a D3A, P341 anteriores a E3F, P342/P343/P344/P345 anteriores a B3F, P442/P444 anteriores a E3A, P443/P445/P446/P543/P544/P545/P546 anteriores a H6A, P841 anteriores a G6A, P643 anteriores a B3F, P642/P645 anteriores a B4A, P741/P742/P743 anteriores a B2A, P746 anteriores a B4E y también anteriores a C4E, y P849 anteriores a B4A. En otras palabras: si tienes MiCOM Px40 desplegados y no llevas una gobernanza seria de firmware, conviene asumir exposición hasta demostrar lo contrario.

El aviso añade un matiz que no pasa desapercibido: para los clientes que no necesitan SNMP, Schneider propone contactar con su centro de soporte para actualizar a una versión de firmware sin funcionalidad SNMP. Eso ya dice bastante. Cuando la remediación pasa por extirpar la función, no por endurecerla, el mensaje implícito es que el problema no se resuelve con una simple casilla de configuración.

Lo relevante no es el 5,3 de CVSS, sino lo que permite hacer antes del siguiente movimiento

La puntuación CVSS 3.1 de 5,3 se apoya en el vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N. Traducido: explotación remota por red, baja complejidad, sin privilegios previos, sin interacción del usuario y con impacto de confidencialidad bajo. Integridad y disponibilidad, cero. Es un score correcto para describir el efecto inmediato. También es insuficiente para estimar el riesgo operativo en entornos industriales.

Este es uno de esos casos donde la matemática de CVSS y la realidad de OT viven en pisos distintos. CVSS mide el impacto directo de la vulnerabilidad aislada. Un operador eléctrico, un responsable de ciber OT o un CISO de infraestructuras críticas tienen que medir otra cosa: qué valor tiene esa información dentro de una cadena de ataque.

SNMP, incluso cuando solo “filtra identificación”, es oro para un atacante que busca moverse con precisión. Saber el modelo exacto del relé, su versión de firmware y su presencia en una red concreta permite:

• Confirmar que el activo existe y está accesible desde un segmento determinado.
• Relacionar el equipo con documentación pública, manuales, MIBs, boletines previos o configuraciones por defecto.
• Construir un mapa de dependencias técnicas para identificar HMIs, gateways, concentradores o estaciones de ingeniería asociadas.
• Priorizar ataques posteriores contra equipos con firmware obsoleto o arquitecturas de administración heredadas.

En IT, la filtración de banner y versión ya es valiosa. En OT lo es aún más, porque el parque tecnológico suele tener vidas útiles largas, ventanas de parcheo estrechas y una mezcla peculiar de segmentación deseada y segmentación realmente implantada. La ironía regulatoria aquí es conocida: muchas organizaciones han aprendido a redactar muy bien sus políticas de segmentación y todavía están trabajando en aplicarlas donde más importa.

Además, el aviso menciona una condición clave: el atacante puede interrogar el puerto SNMP sin autenticación. Si ese puerto es visible más allá del segmento estrictamente controlado, la organización ya ha perdido una capa de defensa antes de empezar. No porque el CVE sea devastador por sí solo, sino porque demuestra que un activo crítico responde donde no debería y cómo no debería.

Qué implica realmente una CWE-798 en un relé de protección

CWE-798 no es una rareza exótica; es una de las debilidades de diseño más incómodas porque mezcla dos problemas. El primero es técnico: hay un secreto embebido o fijo que no se gestiona como credencial rotatoria normal. El segundo es de gobernanza: la organización usuaria no tiene control real sobre ese secreto, o lo tiene de forma limitada, porque viene impuesto por el fabricante o por la implementación del producto.

En el caso de MiCOM Px40, CISA y Schneider hablan de hard-coded credentials que permiten acceso no autorizado a información sensible del dispositivo cuando un atacante interroga el puerto SNMP. No se describe, al menos en el aviso, una toma de control del equipo ni una capacidad de modificación de ajustes. Conviene no exagerar. Pero tampoco conviene trivializarlo.

Los relés de protección ocupan un punto delicado en la pirámide OT. No suelen ser el mejor lugar para empezar una intrusión compleja, pero sí son activos donde un adversario quiere visibilidad. Saber qué relés hay, dónde están, qué familia ejecutan y qué firmware usan permite modelar el sistema de protección y su superficie de administración. Para un actor que persiga disrupción o sabotaje, ese conocimiento no es accesorio. Es preparación.

Hay otro ángulo menos comentado: la persistencia de SNMP en OT por razones operativas y de legado. Muchas organizaciones mantienen SNMP porque lo usan en supervisión, inventario, gestión de alarmas o integración con herramientas históricas. Desactivarlo no siempre es trivial. Cambiar firmware a una versión sin SNMP, como propone Schneider para quien no lo necesite, puede ser razonable en teoría y costoso en planta si la función está incrustada en procedimientos, cuadros de mando o integraciones con SCADA y NMS.

Aquí aparece la tensión de siempre entre ciberseguridad y continuidad operativa. Lo nuevo no es la tensión. Lo interesante es que el propio fabricante la reconoce al ofrecer dos caminos distintos: uno para quien puede prescindir de SNMP y otro, puramente mitigador, para quien no puede.

La remediación de Schneider tiene un detalle incómodo: si no necesitas SNMP, te pide eliminarlo

El texto de mitigación distingue dos escenarios.

Para clientes que no requieren SNMP, Schneider indica que contacten con su Customer Care Center para actualizar el firmware a una versión sin funcionalidad SNMP. Es una recomendación más agresiva de lo habitual y, precisamente por eso, útil. No se limita al clásico “restrinja acceso y monitorice”. Dice algo más relevante: si la función no aporta valor operativo, mejor quitarla del mapa.

Para clientes que sí requieren SNMP, no se ofrece en el aviso una corrección funcional equivalente. Se repiten tres mitigaciones inmediatas:

• Usar los relés solo en un entorno de red protegido.
• Aplicar firewalls para proteger y separar la red de control del resto de redes.
• Utilizar túneles VPN si se necesita acceso remoto.

Esto tiene varias lecturas operativas.

La primera: en determinados despliegues, la solución real no es parchear sino reducir exposición. La segunda: si tu arquitectura depende de SNMP abierto o accesible desde segmentos amplios, la deuda no está en el boletín, está en el diseño. La tercera, bastante menos cómoda: si necesitas SNMP por razones legítimas, probablemente tendrás que convivir con el riesgo residual y demostrar que tus controles compensatorios son sólidos.

Y aquí suele empezar el problema serio, porque “red protegida” y “firewall de separación” suenan estupendamente hasta que alguien pregunta por reglas concretas, listas de control de acceso, activos autorizados a consultar SNMP, inventario de saltos remotos, registros de cambios y evidencias de revisión. En ese momento aparece la diferencia entre la segmentación dibujada en PowerPoint y la segmentación que sobrevive a una revisión técnica.

Si tu programa OT depende de SNMP, esta vulnerabilidad te obliga a hacer preguntas incómodas

La pregunta correcta no es solo si tienes un MiCOM Px40 afectado. La pregunta útil es quién puede llegar a su puerto SNMP, desde dónde, con qué justificación y con qué trazabilidad.

Un equipo de seguridad razonablemente maduro debería revisar, como mínimo, cinco frentes muy concretos.

1. Exposición real del puerto SNMP

No basta con revisar la configuración del relé. Hay que validar la ruta de red. ¿El puerto SNMP responde solo desde una estación de supervisión autorizada? ¿Responde desde otros segmentos OT? ¿Existe visibilidad desde la red corporativa, desde una zona DMZ industrial o, peor aún, desde un acceso remoto de terceros? En OT, la topología efectiva suele haber evolucionado a base de excepciones “temporales” que se volvieron permanentes hace años.

2. Dependencias operativas

Antes de desactivar SNMP o migrar a una versión sin esa funcionalidad, conviene identificar qué sistemas lo usan de verdad. Herramientas de monitorización, plataformas de gestión de red, colectores de eventos, pasarelas o scripts internos pueden depender de consultas SNMP sin que eso esté bien documentado. Cortarlo a ciegas es una forma estupenda de descubrir dependencias en producción. No recomendable.

3. Versionado y ventana de actualización

La lista de versiones afectadas obliga a una tarea nada glamourosa: inventario fino por familia y release. No “tenemos Px40”. Hay que saber si es P643 anterior a B3F, P741 anterior a B2A o P443 anterior a H6A. Sin esa granularidad no hay priorización posible. Y sin priorización, todo se convierte en una cola eterna de OT donde nada caduca porque nadie quiere tocar el equipo.

4. Acceso remoto de proveedores e integradores

El aviso insiste en el uso de VPN cuando el acceso remoto sea necesario. Tiene lógica, pero se queda corto si no se traduce en controles concretos: autenticación fuerte, cuentas nominativas, sesiones temporales, revisión de logs y restricciones por activo. Muchos entornos industriales siguen arrastrando accesos remotos genéricos para soporte que funcionan porque “siempre se hizo así”. Ese tipo de herencia tecnológica suele llevarse mal con las credenciales embebidas.

5. Detección y telemetría

Si no puedes eliminar SNMP, al menos deberías poder detectar consultas anómalas al servicio. Eso exige telemetría de red OT, umbrales básicos y capacidad para distinguir tráfico operativo legítimo de sondeos inesperados. No hace falta convertir una subestación en un laboratorio de SIEM hipervitaminado. Sí hace falta saber si alguien está interrogando relés fuera del patrón normal.

El contexto regulatorio: no es DORA, pero la lógica de control es exactamente la misma

Esta alerta de CISA no nace de una norma europea, pero encaja de lleno en la dirección que marcan varios marcos regulatorios y de cumplimiento en 2026. No porque exista un artículo mágico que diga “no deje SNMP expuesto en sus relés”, sino porque la combinación de inventario, segmentación, gestión de vulnerabilidades y control de terceros ya no es opcional en sectores críticos.

Si operas en la UE y estás bajo NIS2, el punto de enganche más evidente es el artículo 21, que obliga a medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar los riesgos de la seguridad de redes y sistemas. Entre ellas figuran la gestión de incidentes, la continuidad, la seguridad de la cadena de suministro, la seguridad en adquisición, desarrollo y mantenimiento, y políticas para evaluar la eficacia de las medidas. Una vulnerabilidad OT con credenciales embebidas, acceso por SNMP y mitigación basada en segmentación no es un caso teórico de manual; es justo el tipo de escenario donde el artículo 21 deja de ser una frase bonita y se convierte en preguntas de auditoría.

Si además hablamos de operadores energéticos o industriales con servicios esenciales, la lógica de gestión de vulnerabilidades y exposición se cruza también con obligaciones nacionales de transposición, supervisión sectorial y esquemas internos de control. El regulador no necesita que hayas sufrido un incidente para preguntarte por qué un activo crítico responde por SNMP desde un segmento no previsto.

En entornos financieros, DORA no aplica directamente a relés eléctricos salvo que formen parte de servicios prestados a entidades financieras o infraestructuras de mercado en escenarios específicos, pero el razonamiento es idéntico al de DORA artículo 8 sobre identificación, clasificación y documentación de funciones, activos y dependencias TIC, al artículo 9 sobre protección y prevención, y al artículo 10 sobre detección. La moraleja es la misma: si no conoces el activo, su versión, su exposición y quién accede a él, no estás gestionando resiliencia; estás cruzando los dedos con método.

También conviene mirar a NIST CSF 2.0, muy usado como lenguaje común entre OT, IT y compliance. Aquí el caso encaja con funciones y categorías de Identify, Protect y Detect: inventario de activos, gestión de configuraciones seguras, control de acceso remoto y monitorización de eventos. No porque CISA lo diga en abstracto, sino porque esta vulnerabilidad muestra con crudeza un patrón clásico: un servicio heredado con utilidad operativa real pero con controles de exposición insuficientes.

Lo que este aviso revela sobre la seguridad OT de fabricante: la deuda no siempre está en el cliente

Hay una tendencia incómoda en ciber OT: desplazar casi toda la responsabilidad al operador final con el repertorio habitual de firewall, segmentación, VPN y sentido común. Todo eso es necesario. También es insuficiente si el producto llega con decisiones de diseño débiles.

Una credencial embebida es, por definición, un problema que nace en la concepción o implementación del producto. No en la mala administración del cliente. Luego el cliente debe mitigar, sí. Pero la cadena de responsabilidad empieza antes. Por eso este tipo de avisos enlazan de forma natural con marcos como el Cyber Resilience Act europeo, que este año 2026 ya condiciona de forma mucho más visible las expectativas del mercado sobre seguridad por diseño, gestión de vulnerabilidades y soporte del fabricante a lo largo del ciclo de vida.

No hace falta forzar la comparación jurídica para ver el cambio de fondo. Hace unos años, muchos boletines de ICS se limitaban a describir el fallo y a recomendar aislamiento. Ahora la pregunta del comprador maduro es otra: qué ha hecho el proveedor para eliminar la funcionalidad insegura, acotar su superficie o facilitar una remediación técnicamente viable.

En este caso, Schneider al menos ofrece una ruta clara para quienes no necesitan SNMP: actualización a firmware sin esa función. Es una respuesta pragmática. También deja una conclusión menos amable: si la mejor solución es quitar la característica, esa característica no estaba en condiciones de convivir con el riesgo aceptable actual.

Para responsables de compras, ingeniería y ciber OT, el aviso aporta una lección útil para futuros pliegos y renovaciones: las preguntas de seguridad de producto deben incluir no solo si existe SNMP, sino cómo se autentica, si puede deshabilitarse por completo, cómo se gestiona su exposición, qué telemetría deja y qué compromiso contractual asume el fabricante ante vulnerabilidades de diseño.

La lista de afectados es lo bastante amplia como para convertir el inventario en prioridad inmediata

Cuando un aviso incluye más de una docena de familias afectadas, el riesgo operativo principal no es el CVE. Es el desorden del inventario. Muchas organizaciones industriales pueden decir que tienen relés MiCOM. Muchas menos pueden afirmar, en el mismo día, cuántos, en qué sedes, con qué firmware y con qué dependencias de gestión.

Ese hueco de visibilidad es precisamente el tipo de debilidad que multiplica el coste de respuesta. Porque la remediación aquí no se limita a “aplique el parche”. Exige decidir equipo por equipo si SNMP es necesario, si puede eliminarse, si hay que programar intervención, si existen ventanas de mantenimiento seguras y si el cambio afecta a supervisión o integración.

El detalle de P746 apareciendo con dos referencias de versión previas distintas, B4E y C4E, es un buen recordatorio de por qué no conviene fiarse de inventarios superficiales o nombres comerciales genéricos. En OT, el riesgo se juega en el firmware exacto y en la variante exacta. No en la familia de producto escrita en una hoja Excel mantenida con optimismo.

Si tu organización gestiona activos distribuidos en múltiples emplazamientos, la prioridad práctica es construir una imagen verificable de tres cosas: qué versión ejecuta cada relé, dónde está expuesto SNMP y qué salto de red existe hasta ese puerto. Sin esas tres respuestas, todo lo demás es ruido administrativo.

No basta con “poner un firewall”: qué controles compensatorios son defendibles de verdad

Los avisos de CISA suelen incluir recomendaciones genéricas de buena práctica industrial: aislar redes de control, controlar el acceso físico, no dejar controladores en modo programa, escanear medios extraíbles, minimizar exposición a Internet y usar VPN para acceso remoto. Son recomendaciones sensatas. También son tan generales que, por sí solas, no bastan para defender una postura de riesgo ante auditoría o ante un incidente.

Si una organización decide convivir temporalmente con la vulnerabilidad porque necesita SNMP, los controles compensatorios que de verdad pesan son más específicos.

Primero, listas de control de acceso de red que limiten SNMP a orígenes nominados y estrictamente necesarios. No “desde la red de operaciones”, sino desde hosts o subredes concretas identificadas por función.

Segundo, segregación entre red corporativa, DMZ industrial y red de control con reglas revisadas y justificadas. En demasiados entornos, el firewall existe pero el set de reglas cuenta una historia bastante menos edificante.

Tercero, revisión de accesos remotos de terceros con caducidad, MFA y trazabilidad por sesión. Un túnel VPN sin gobierno de identidades es, siendo generosos, una puerta con cerradura pero sin registro de llaves.

Cuarto, monitorización específica de consultas SNMP hacia los relés afectados. No hace falta inspección perfecta del contenido para detectar un patrón anómalo de sondeos desde un origen inesperado o en una franja horaria fuera de operación.

Quinto, decisión documentada de riesgo residual por activo o por emplazamiento. Si no puedes aplicar firmware ni desactivar SNMP, alguien con autoridad debe aceptar el riesgo sobre la base de dependencias operativas, controles compensatorios y fecha de revisión. Lo contrario es el clásico limbo organizativo donde nadie asume la excepción pero todos conviven con ella.

Esto no es burocracia. Es capacidad de explicar, con hechos, por qué el riesgo está contenido. Cuando llegue la pregunta del regulador, del auditor o del comité de riesgos, la frase “tenemos firewalls” no impresionará a nadie.

Qué deberían hacer ahora los equipos de OT, ciber y compliance

La respuesta sensata en 2026 no pasa por dramatizar ni por ignorar el aviso porque el CVSS no asusta. Pasa por una secuencia muy concreta de decisiones.

La primera es confirmar alcance. Identificar si existen equipos de la serie Easergy MiCOM Px40 en las familias afectadas y con versiones previas a las indicadas por Schneider. Esto exige inventario técnico, no inventario contractual.

La segunda es verificar necesidad de SNMP. Si no aporta una función operativa indispensable, la mejor respuesta probablemente sea seguir la recomendación del fabricante y actualizar a una versión sin SNMP. Reducir superficie gana casi siempre frente a tratar de domesticar una función débil.

La tercera es medir exposición de red real. Qué activos pueden interrogar el puerto, qué rutas lo permiten, qué terceros llegan hasta ahí y qué registros dejan. Este análisis de exposición vale más que diez reuniones sobre concienciación.

La cuarta es definir controles compensatorios defendibles allí donde SNMP deba mantenerse. No controles genéricos, sino reglas, orígenes permitidos, telemetría, revisión de cuentas remotas y plazos de reevaluación.

La quinta es escalar la cuestión a gobierno de riesgo si la remediación técnica no puede completarse pronto. Los riesgos OT rara vez se resuelven solo en ciberseguridad; afectan a operación, mantenimiento, proveedor y continuidad de servicio. Si la organización sigue tratándolos como tickets aislados, el problema no es el CVE, es el modelo de decisión.

Compliance también tiene trabajo aquí. No para recitar marcos, sino para pedir evidencia concreta: inventario de afectados, acta de análisis de impacto, decisión sobre necesidad de SNMP, cambios de reglas de red, validación de acceso remoto y fecha de revisión del riesgo residual. Eso sí es trazabilidad útil.

La lección de fondo: en infraestructuras críticas, la “información básica” nunca es tan básica

El aviso de CISA sobre CVE-2026-4832 no describe un escenario apocalíptico. Describe algo más común y, por eso mismo, más peligroso: un fallo de diseño que no destruye nada por sí solo, pero facilita el trabajo a quien quiera entender tu entorno mejor de lo que tú mismo lo entiendes.

En seguridad industrial, ese tipo de ventaja táctica importa mucho. La cadena de ataque contra OT rara vez empieza intentando abrir interruptores o alterar protecciones a ciegas. Empieza identificando activos, versiones, rutas de acceso y debilidades explotables con bajo ruido. Un relé que responde por SNMP con información accesible sin autenticación encaja demasiado bien en esa fase como para despacharlo con un “medium” y seguir adelante.

Hay además una lección incómoda para el mercado. Durante años, la seguridad OT ha tolerado demasiadas excepciones heredadas bajo el argumento de la continuidad operativa. Algunas son inevitables. Otras simplemente han sobrevivido porque nadie quería enfrentarse al coste político y técnico de cambiarlas. Esta vulnerabilidad vuelve a plantear la pregunta esencial: si una función no puede exponerse de forma segura, por qué sigue activa y quién se beneficia realmente de mantenerla así?

El regulador, el auditor y el atacante tienen algo en común: tarde o temprano harán esa misma pregunta. Conviene llegar con una respuesta mejor que “siempre se hizo así”.

Y una última cosa. Cuando un fabricante te ofrece un firmware sin SNMP porque no lo necesitas, no lo leas como una recomendación cosmética. Léelo como una pista bastante clara sobre cuál es el estado natural deseable del sistema. En ciberseguridad industrial, la mejor superficie expuesta sigue siendo la que ya no existe.