Desbordamiento de búfer en EPICS Base, corregido en 7.0.11 (CVE-2026-114595)

TL;DR

• Cuatro fallos de seguridad de memoria en EPICS Base, el framework open source que sostiene los sistemas de control de aceleradores y telescopios, permiten que un nodo de red sin autenticación corrompa la memoria de un Input/Output Controller. El peor, CVE-2026-114595, alcanza un CVSS v3.1 de 9.8 (Critical). CISA publicó el aviso ICSA-26-300-01 y Cipher Research publicó los hallazgos el 27 de octubre de 2026.
• Todas las versiones de EPICS Base iguales o anteriores a 7.0.10 están afectadas. Tres fallos están en el análisis de mensajes Channel Access del lado servidor en TCP 5064; el cuarto afecta la validación de conexión de pvAccess clásico en TCP 5075.
• Cipher demostró corrupción del montículo y caídas en un entorno de pruebas, no ejecución de código; la ejecución remota de código es el potencial evaluado por CISA. No se conoce explotación, y ninguno de los cuatro CVE figura en el catálogo KEV de CISA al 3 de noviembre de 2026.
• Actualice cada despliegue afectado a EPICS Base 7.0.11 y pruebe primero los clientes Channel Access antiguos. «¿Cómo lo corrijo?» detalla los pasos del retroporte y el aislamiento de red.

¿Estoy afectado?

Está expuesto cuando se cumplen todas estas condiciones:

• Ejecuta un Input/Output Controller (IOC) de EPICS u otro servidor construido sobre EPICS Base 7.0.10 o anterior. El aviso de CISA lista todas las versiones iguales o anteriores a 7.0.10 como afectadas.
• El atacante puede alcanzar los puertos de protocolo del servidor: Channel Access en TCP 5064 con el descubrimiento en UDP 5064, o pvAccess clásico en TCP 5075 con el descubrimiento en UDP 5076.
• No se necesita credencial. En la configuración de prueba de Cipher no hizo falta ninguna cuenta privilegiada, y los tres fallos de Channel Access solo requieren una conexión TCP más un canal para las rutas de escritura.

Las reglas de seguridad de acceso del IOC no cambian esto. Gobiernan lo que un cliente puede leer o escribir, y no hacen seguro el análisis de un mensaje mal formado. El fallo de pvAccess se alcanza durante la validación de conexión, antes de que ese intercambio termine.

Compruebe qué ejecuta en cada host de la instalación:

# In each EPICS Base installation: the generated version header
grep EPICS_VERSION_SHORT <epics-base>/include/epicsVersion.h

# In each IOC application directory: which EPICS Base it builds against
grep -n "EPICS_BASE" configure/RELEASE

# On the IOC host: which processes serve Channel Access and pvAccess
ss -tlnp | grep -E ':5064|:5075'

Los controladores y paquetes de línea de luz suministrados por proveedores pueden incluir EPICS Base: inventaríelos también. Una instalación puede ejecutar EPICS mediante una aplicación mantenida internamente mientras otra lo recibe dentro de hardware de proveedor, como indica Cipher.

¿Cómo lo corrijo?

Actualice primero y luego revise la accesibilidad de protocolo que exponía los fallos:

1. Actualice cada despliegue afectado de la serie 7.0 a EPICS Base 7.0.11 desde la página de versión de EPICS. Los mantenedores advierten que no han probado el servidor Channel Access endurecido con programas cliente antiguos: pruebe a fondo los clientes heredados antes de producción.
2. Para las series anteriores que no puedan pasar a 7.0.11, retroporte las dos correcciones originales: epics-base pull request 934 y pvDataCPP pull request 109. La pull request 934 de epics-base indica que los retroportes a versiones anteriores a 2017 también necesitan el commit e430d09.
3. Restrinja los puertos de protocolo a los hosts de control que los necesitan mientras despliega. Se aplican las prácticas recomendadas de CISA: mantener los sistemas de control fuera de internet, aislarlos de las redes de negocio y usar VPN actualizadas para el acceso remoto necesario.
4. Si empaqueta EPICS en un producto, verifique si su copia incluye el código Channel Access o pvAccess clásico afectado. Publique guías o retroportes por versión para sus clientes, como Cipher recomienda a los mantenedores posteriores.

Bloquear los puertos reduce la exposición, no sustituye a la actualización. El IOC sigue analizando los mensajes de los clientes legítimos con el código vulnerable hasta que la corrección esté instalada.

¿Cuál es la causa raíz?

El servidor Channel Access confía en los números de elementos y las longitudes del encabezado al dimensionar y convertir los mensajes. El deserializador de pvAccess clásico convierte los elementos decodificados al tipo que declara el array que los contiene, sin comprobar que lo tengan.

Channel Access es el protocolo cliente-servidor original de EPICS. La implementación del servidor, RSRV, lee cada encabezado de petición en una estructura caHdrLargeArray cuyos campos m_dataType, m_count y m_postsize provienen directamente de la red, y luego actúa sobre ellos en modules/database/src/ioc/rsrv/camessage.c. En la ruta de escritura de 7.0.10 nada cruza estos campos con el canal ni con la carga útil que llegó:

// epics-base/modules/database/src/ioc/rsrv/camessage.c at R7.0.10 (write_action)
status = caNetConvert (
    mp->m_dataType, pPayload, pPayload,
    FALSE /* net -> host format */, mp->m_count );

La conversión consume m_count elementos de tipo m_dataType desde el búfer de recepción sin importar cuántos elementos tenga el canal ni cuántos bytes llevara realmente la petición. El bucle de distribución de mensajes también construye tamaños con aritmética de 32 bits sin comprobar:

// epics-base/modules/database/src/ioc/rsrv/camessage.c at R7.0.10 (camessage)
msg.m_postsize  = ntohl ( pLW[0] );
msg.m_count     = ntohl ( pLW[1] );
msgsize = msg.m_postsize + sizeof(*mp) + 2 * sizeof ( *pLW );

Cada uno de los cuatro CVE es una consecuencia de esa confianza, como establece el análisis de Cipher:

• CVE-2026-114595 (CVSS v3.1 9.8, CWE-190): el número de elementos de una petición de escritura se combina con el tamaño de elemento sin límite, el cálculo desborda la aritmética de 32 bits y la asignación queda más pequeña que la conversión que sigue. Bajo AddressSanitizer esto produjo una escritura fuera de límites del montículo con bytes controlados por el atacante.
• CVE-2026-114596 (CVSS v3.1 8.2, CWE-190): una longitud de carga útil de encabezado extendido cercana al techo de 32 bits hace que el tamaño calculado se desborde y pase la comprobación de tamaño máximo, y una ruta posterior de creación de canal escribe un byte terminal fuera de límites.
• CVE-2026-114597 (CVSS v3.1 7.5, CWE-130): el número de elementos declarado excede la carga útil recibida, y la conversión avanza más allá del búfer de recepción como lectura fuera de límites.
• CVE-2026-114598 (CVSS v3.1 7.5, CWE-843): en FieldCreate::deserialize de pvDataCPP, se acepta una descripción de array de estructuras o uniones con un elemento de tipo distinto, y el código lo interpreta con el diseño equivocado, incluidos campos con punteros.

¿Cómo se explota?

No existe prueba de concepto pública: Cipher no publicó sus cargas de reproducción, y los parches originales son el registro público de lo que cada corrección cierra. Los pasos siguientes son el mecanismo tal como lo describe el análisis.

1. El atacante abre una conexión TCP normal al puerto Channel Access del IOC y envía una petición de escritura cuyo encabezado declara un número de elementos grande y un tipo.
2. El número de elementos y el tamaño de elemento se combinan mediante aritmética de 32 bits que se desborda: el servidor asigna demasiado poca memoria para los datos que procesa después.
3. La conversión de la carga útil del atacante prosigue en esa asignación insuficiente. Bajo AddressSanitizer la petición produjo una escritura fuera de límites del montículo con bytes controlados por el atacante, seguida de una caída del proceso.
4. La variante de encabezado extendido declara una longitud cercana al techo de 32 bits: la comprobación de tamaño se desborda, y una ruta posterior de creación de canal coloca un byte terminal más allá de la memoria disponible como escritura fuera de límites restringida.
5. La variante de lectura declara más elementos de los que contiene la carga útil, y la variante de pvAccess envía un elemento con tipo equivocado dentro de una descripción de array de estructuras durante la validación inicial de conexión, antes de que la autenticación termine. Ambas provocan la caída del hilo del servidor como lecturas fuera de límites.

¿Cómo fluye el ataque?

Una sola petición de escritura sin autenticación al puerto Channel Access corrompe el montículo del IOC mediante un cálculo de dimensionamiento desbordado.

¿Qué puede hacer un atacante?

Los efectos demostrados son corrupción de memoria y denegación de servicio, todos reproducidos por Cipher bajo AddressSanitizer o un depurador:

• CVE-2026-114595 produjo una escritura fuera de límites del montículo con bytes controlados por el atacante, la clase desde la que se construye la ejecución remota de código. CISA califica el fallo como Critical con un impacto de ejecución de código potencial; Cipher no construyó un exploit ni evaluó la fiabilidad de la corrupción en builds de producción.
• CVE-2026-114596 es una escritura fuera de límites restringida, un byte fijo en un desplazamiento fijado por el cálculo: el resultado es una caída provocada en remoto, no una primitiva de escritura general.
• CVE-2026-114597 y CVE-2026-114598 son lecturas fuera de límites. Cipher confirmó las caídas y no demostró divulgación de contenido de memoria a un cliente remoto.

Provocar la caída de un IOC tiene consecuencias operativas propias. Un IOC realiza supervisión, adquisición de datos y control de equipos dentro de un instrumento mayor. Interrumpirlo puede privar a los operadores o a la automatización de observaciones o funciones de control, como señala el análisis. Lo que sigue depende de la arquitectura de la instalación. Redundancia, comportamiento de respaldo y enclavamientos de protección independientes deciden el radio de impacto.

Las condiciones son la accesibilidad del puerto TCP y, para las rutas de escritura, un canal: no hizo falta ninguna cuenta privilegiada en la configuración de prueba de Cipher.

¿Por qué funciona la corrección?

La versión 7.0.11 incluye epics-base pull request 934 y pvDataCPP pull request 109, y cada una cierra exactamente el vacío de validación que usó su fallo. La ruta de escritura ahora valida el tipo, limita el número de elementos y compara el tamaño calculado con la carga útil que llegó:

 # epics-base/modules/database/src/ioc/rsrv/camessage.c (write_action, PR 934)
-    pciu = MPTOPCIU(mp);
+    pciu = MPTOPCIU(mp, client);
     if(!pciu){
         logBadId(client, mp, pPayload);
         return RSRV_ERROR;
     }
+
+    if (INVALID_DB_REQ(mp->m_dataType)) {
+        log_header ("bad put data type", client, mp, pPayload, 0);
+        return RSRV_ERROR;
+    }
+    if (mp->m_count > dbChannelFinalElements(pciu->dbch)) {
+        mp->m_count = dbChannelFinalElements(pciu->dbch);
+    }
+
+    size = dbr_size_n (mp->m_dataType, mp->m_count);
+    if (size > mp->m_postsize) {
+        return RSRV_ERROR;
+    }

El bucle de distribución ahora rechaza una longitud extendida que desbordaría la aritmética de tamaño:

 # epics-base/modules/database/src/ioc/rsrv/camessage.c (camessage, PR 934)
             msg.m_postsize  = ntohl ( pLW[0] );
             msg.m_count     = ntohl ( pLW[1] );
+            if (msg.m_postsize >= ca_uint32_max - (sizeof(*mp) + 2 * sizeof ( *pLW ))) {
+                if(CASDEBUG>0) {
+                    errlogPrintf("Client ext msg size too large 0x%08x\n",
+                                 (unsigned)msg.m_postsize);
+                }
+                status = RSRV_ERROR;
+                break;
+            }
             msgsize = msg.m_postsize + sizeof(*mp) + 2 * sizeof ( *pLW );

La confusión de tipos de pvAccess se cierra validando el tipo real del elemento decodificado antes de la conversión, y la recursión de deserialización queda limitada:

 # pvDataCPP/src/factory/FieldCreateFactory.cpp (FieldCreate::deserialize, PR 109)
-            StructureConstPtr elementStructure = std::tr1::static_pointer_cast<const Structure>(control->cachedDeserialize(buffer));
+            StructureConstPtr elementStructure = std::tr1::dynamic_pointer_cast<const Structure>(control->cachedDeserialize(buffer));
+            if(!elementStructure)
+                throw std::invalid_argument("Expected Structure");

La pull request 934 aplica el mismo límite de número de elementos y el mismo cruce de carga útil a las rutas de lectura, adición de evento y notificación de escritura. La búsqueda de canal también rechaza los identificadores creados por otro cliente: los tres fallos de Channel Access quedan cubiertos en un solo conjunto de cambios. La descripción de la propia pull request lo confirma: cruzar los campos de encabezado relacionados msgsize, dtype y count, evitando ante todo los desbordamientos de enteros.

¿Cómo verifico si estuve comprometido?

No hay indicadores publicados, porque no se han liberado cargas de reproducción ni tráfico de atacante. Un intento fallido puede no dejar nada más que una caída.

• Revise los registros de disponibilidad de los IOC en busca de reinicios o caídas de proceso inexplicadas cerca de los puertos de protocolo, incluidos los archivos core del host IOC.
• Busque orígenes inesperados en los registros de cortafuegos o de flujo para conexiones a TCP 5064 o TCP 5075, y al descubrimiento UDP 5064 y 5076, previas a una caída.
• Compruebe si algún IOC era alcanzable desde segmentos de gestión, acceso remoto, investigación, invitados o puentes. Cipher los cita expresamente como rutas que volver a revisar.
• Considere desconocido el impacto de todo evento fuera de límites confirmado hasta examinarlo. Sin carga pública, ninguna huella distingue un intento de caída de un intento de explotación.

Cronología

• 2026-06-09: Causal Security informa los cuatro hallazgos al canal de seguridad de EPICS y coordina con CISA la asignación de CVE y la notificación posterior.
• 2026-07-23: el endurecimiento de Channel Access, epics-base pull request 934, se fusiona en la rama 7.0 tras un informe confidencial de Shubham Raj de Cipher y un informe no confidencial que se solapaba.
• 2026-08-10: se fusiona la corrección de confusión de tipos de pvAccess, pvDataCPP pull request 109.
• 2026-10-26: el archivo base-7.0.11.tar.gz y su firma se crean desde la rama 7.0.
• 2026-10-27: se publica EPICS Base 7.0.11, CISA publica el aviso ICSA-26-300-01 y Cipher Research publica su análisis.

Preguntas frecuentes

¿Está demostrada la ejecución remota de código?

No. El aviso de CISA indica que el peor fallo «may result in memory corruption, denial of service, or potential remote code execution», y el entorno de pruebas de Cipher produjo una escritura fuera de límites del montículo con bytes controlados por el atacante. Cipher no construyó un exploit ni evaluó la fiabilidad de la corrupción en builds de producción: la ejecución de código sigue siendo un potencial evaluado, no un resultado demostrado.

¿Se explota alguno de los cuatro CVE en entornos reales?

No se conoce explotación, y ninguno de los cuatro aparece en el catálogo Known Exploited Vulnerabilities de CISA al 3 de noviembre de 2026. Los cuatro registros CVE tampoco llevan bloque de evaluación de CISA ADP: no existe ningún marcador SSVC de explotación que citar.

¿Las reglas de seguridad de acceso del IOC detienen estos ataques?

No. Las reglas de acceso gobiernan lo que un cliente puede leer o escribir, y el protocolo de validación de conexión de pvAccess proporciona autenticación. Cipher afirma que ninguno sustituye a las correcciones: los controles no hacen seguro el análisis de un mensaje mal formado, y el fallo de pvAccess se alcanza durante la validación de conexión antes de que ese intercambio termine.

Ejecutamos EPICS Base 3.15, no la serie 7.0. ¿Estamos afectados?

Sí. El aviso de CISA lista toda versión de EPICS Base igual o anterior a 7.0.10 como afectada. Ninguna versión de la serie 3.15 lleva las correcciones: retroporte epics-base pull request 934 y pvDataCPP pull request 109; la primera indica que las versiones anteriores a 2017 también necesitan el commit e430d09. Las pilas empaquetadas por proveedores necesitan retroportes del proveedor.

¿La actualización puede romper clientes Channel Access antiguos?

Puede. La página de la versión 7.0.11 indica que los mantenedores no han probado el servidor Channel Access endurecido con programas cliente antiguos. Aconseja a las instalaciones probar a fondo antes de desplegar en producción. Planifique el despliegue con el inventario de clientes heredados a mano.

¿Quién encontró estos fallos y cómo?

Shubham Raj de Cipher, el sistema de seguridad autónomo de Causal Security, encontró y validó los cuatro en 3 horas y 49 minutos sobre un código que no había visto antes. La investigación no exigió intervención humana; el único paso humano fue una única instrucción que autorizaba pruebas de explotabilidad más profundas en un entorno aislado.

Encuentre servicios de sistemas de control expuestos con Ostorlab

El descubrimiento de superficie de ataque de Ostorlab inventaría los hosts expuestos a internet en sus rangos. Localice cada host que responde en los puertos Channel Access o pvAccess antes de planificar la ventana de actualización. Comience un escaneo con Ostorlab para saber qué sitios corregir primero.

Referencias

• Aviso de CISA para sistemas de control industrial ICSA-26-300-01, EPICS Base, publicado el 27 de octubre de 2026, con las descripciones de los cuatro CVE, vectores CVSS y enlaces de remediación: https://www.cisa.gov/news-events/ics-advisories/icsa-26-300-01 (verificado el 3 de noviembre de 2026)
• Cipher Research, Causal Security, «Inside EPICS Base: Four severe vulnerabilities discovered autonomously in under four hours», publicado el 27 de octubre de 2026, con el mecanismo por fallo, los puertos y la cronología de divulgación: https://causalsecurity.com/research/epics-base-security-research (verificado el 3 de noviembre de 2026)
• Registro CVE-2026-114595 con CVSS v3.1 9.8 y v4.0 9.3: https://www.cve.org/CVERecord?id=CVE-2026-114595 (verificado el 3 de noviembre de 2026)
• Registro CVE-2026-114596 con CVSS v3.1 8.2 y v4.0 8.8: https://www.cve.org/CVERecord?id=CVE-2026-114596 (verificado el 3 de noviembre de 2026)
• Registro CVE-2026-114597 con CVSS v3.1 7.5 y v4.0 8.7: https://www.cve.org/CVERecord?id=CVE-2026-114597 (verificado el 3 de noviembre de 2026)
• Registro CVE-2026-114598 con CVSS v3.1 7.5 y v4.0 8.7: https://www.cve.org/CVERecord?id=CVE-2026-114598 (verificado el 3 de noviembre de 2026)
• epics-base pull request 934, «RSRV message validation», fusionada el 23 de julio de 2026, corrección de Channel Access con la nota de retroporte para versiones anteriores a 2017: https://github.com/epics-base/epics-base/pull/934 (verificado el 3 de noviembre de 2026)
• pvDataCPP pull request 109, corrección de validación de tipos y límite de recursión de pvAccess, fusionada el 10 de agosto de 2026: https://github.com/epics-base/pvDataCPP/pull/109 (verificado el 3 de noviembre de 2026)
• Página de la versión EPICS 7.0.11, 26 de octubre de 2026, con la advertencia de interoperabilidad con clientes antiguos y los enlaces de descarga: https://epics-controls.org/resources-and-support/base/epics-7/7-0-11/ (verificado el 3 de noviembre de 2026)
• Versión en GitHub de EPICS Base R7.0.11, publicada el 27 de octubre de 2026: https://github.com/epics-base/epics-base/releases/tag/R7.0.11 (verificado el 3 de noviembre de 2026)
• Código fuente vulnerable, camessage.c en el tag R7.0.10, citado para la sección de causa raíz: https://github.com/epics-base/epics-base/blob/R7.0.10/modules/database/src/ioc/rsrv/camessage.c (verificado el 3 de noviembre de 2026)
• Fuente JSON del catálogo Known Exploited Vulnerabilities de CISA, buscada para los cuatro CVE sin coincidencia al 3 de noviembre de 2026: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (verificado el 3 de noviembre de 2026)