01 · Contexto
Qué está ocurriendo
El 16 de octubre de 2026 AWS publicó el boletín 2026-138 sobre dos vulnerabilidades de FreeRTOS-Kernel. Ambas afectan las versiones 11.3.0 y 11.3.1 del puerto Arm Cortex-R82 cuando configENABLE_MPU=1. La compañía identifica la versión 11.3.2 como corregida y aclara que las aplicaciones que no utilizan esa MPU no están afectadas por estos problemas.
CVE-2026-109587 corresponde a una autorización incorrecta de regiones de memoria. CVE-2026-109588 corresponde a un truncamiento numérico al validar la longitud de un búfer. Bajo determinadas condiciones, una tarea sin privilegios podría acceder a memoria privilegiada fuera del espacio que le corresponde. El boletín recomienda actualizar y trasladar las correcciones a versiones derivadas; no aporta evidencia de explotación activa.
Análisis editorial: el nombre del componente por sí solo no permite determinar exposición. En software embebido, la revisión necesita relacionar el código incorporado, la arquitectura objetivo y las opciones efectivas de compilación. Un inventario que solo enumera FreeRTOS puede producir tanto alarmas innecesarias como una falsa tranquilidad si omite un puerto específico incluido por un proveedor.
02 · Impacto
Por qué importa
El riesgo relevante es perder una separación que la aplicación daba por confiable. En nuestra lectura, eso justifica revisar qué tareas procesan entradas externas y qué información comparte el sistema entre niveles de privilegio. No significa que todos los dispositivos con FreeRTOS sean vulnerables ni demuestra un compromiso de una instalación concreta. La decisión debe apoyarse en evidencia del firmware realmente desplegado, no únicamente en una biblioteca presente en el repositorio.
03 · Recomendaciones
Qué conviene hacer
- Identificar productos y componentes que utilicen Cortex-R82 y pedir a sus responsables la versión del kernel, la configuración MPU y la trazabilidad de la compilación distribuida. Registrar también los equipos descartados y la evidencia que justifica esa decisión.
- Para implementaciones afectadas, preparar una actualización controlada a la versión corregida, incorporando pruebas funcionales, de temporización y de recuperación apropiadas para el dispositivo. No desactivar el aislamiento como atajo para evitar el hallazgo.
- Comprobar que los forks y paquetes de terceros contienen la corrección y conservar el identificador del firmware actualizado. Si todavía falta una respuesta del proveedor, mantener el caso abierto con responsable y fecha de revisión, diferenciando incertidumbre de exposición confirmada. Documentar el resultado permite evitar repetir decisiones sin antecedentes verificables.