Un aviso con severidad máxima muestra que una imagen de checkpoint puede desactivar casi todo el aislamiento de Podman, Arcane corrige una toma de cuenta administradora por un permiso delegado, GitHub revisa fallas que tiran procesos en kin-openapi, gomarkdown, Wasmtime y lopdf, el rastreo comunitario de paquetes maliciosos halla 10 entradas nuevas solo en PyPI, y workerd cierra con una versión de mantenimiento la semana del primer parche de Ryan Dahl.
Una anotación en la imagen basta para que podman run descarte --cap-drop y cualquier otra bandera de aislamiento que el operador haya configurado, según el aviso con la severidad máxima que GitHub revisó el 15 de octubre.
El GitHub Advisory Database revisó y actualizó, el 15 de octubre de 2026, el aviso GHSA-2cvf-wqm6-wr9g (CVE-2026-94603, CVSS 3.1 de 10.0, la severidad máxima posible) para github.com/containers/podman y go.podman.io/podman/v6, el motor de contenedores de código abierto de Red Hat que compite con Docker como alternativa sin demonio y sin privilegios de raíz. Según la descripción oficial, Podman 4.4.0 agregó la capacidad de distribuir puntos de control (checkpoints) de contenedores completos a través de registros OCI y relanzarlos con podman run; cuando una imagen lleva la anotación io.podman.annotations.checkpoint.runtime.name, que la marca como un checkpoint, el comando "silently ignore[s] all user input" sobre cómo debe crearse el contenedor, en palabras del propio aviso. Eso significa que una bandera como --cap-drop=ALL, pensada para quitarle todas las capacidades de Linux al contenedor, queda sin efecto: el checkpoint trae sus propias capacidades guardadas, que pueden incluir todas. ADA Logics Ltd. reportó la falla, usando modelos de Anthropic como parte de su proceso de revisión, según el crédito del propio aviso. La corrección llegó en las versiones 5.8.8 y 6.1.3 del proyecto, publicadas por el mantenedor mheon, y consiste en revertir por completo la función que relanzaba checkpoints desde podman run. Una severidad de 10.0 sobre 10 -el puntaje máximo que admite el estándar CVSS- es rara incluso entre los avisos críticos que esta sección cubre a diario, y refleja que el ataque no exige privilegios, interacción de la víctima ni complejidad técnica alguna si el operador llega a ejecutar la imagen. Podman se eligió, en buena parte, como alternativa a Docker precisamente por ofrecer garantías de aislamiento más estrictas por defecto; que una imagen pueda apagar esas garantías con solo una anotación -sin exploit, sin escalamiento, solo aprovechando una función que el propio proyecto documentó desde 2023- pone en duda esa promesa central. El propio aviso, sin embargo, acota el alcance real de la falla: Podman en modo sin privilegios de raíz (rootless) -la configuración que el proyecto recomienda por defecto desde hace varias versiones- no está afectado, porque esa variante todavía no soporta checkpoint/restore. El ataque exige además que alguien ejecute explícitamente una imagen marcada como checkpoint proveniente de afuera, un flujo de trabajo mucho menos común que simplemente correr una imagen de contenedor cualquiera. Esa combinación de requisitos reduce el universo real de sistemas expuestos frente a lo que el puntaje de 10.0 podría sugerir a primera lectura. Costa Rica no tiene una base reportada públicamente de empresas que corran Podman rootful en producción, pero equipos de DevOps costarricenses que migraron de Docker a Podman por sus garantías de aislamiento -una tendencia creciente en shops que trabajan con Red Hat y OpenShift- deberían confirmar que no ejecutan imágenes de checkpoint sin revisar antes de actualizar a 5.8.8 o 6.1.3, sin que se conozca un caso costarricense afectado al cierre de esta edición.
El GitHub Advisory Database revisó y actualizó, el 16 de octubre de 2026, el aviso GHSA-pw5q-rjx4-7f7p (CVE-2026-96627, CVSS 3.1 de 8.8, severidad alta) para github.com/getarcaneapp/arcane/backend/v2, el backend en Go de Arcane, un tablero de código abierto para administrar contenedores Docker que compite con Portainer. Según la descripción oficial, el manejador de actualización de usuarios en backend/api/handlers/users.go fija el hash de contraseña de cualquier usuario objetivo sin comparar el nivel de privilegio de quien hace la solicitud contra el de ese objetivo; la asignación de roles sí está restringida a administradores globales, pero el permiso users:update -pensado para quedar por debajo de ese nivel- terminaba permitiendo lo mismo por una vía distinta: restablecer la contraseña del propio administrador. El usuario de GitHub zx, identificado como Jace, reportó la falla. La corrección llegó en la versión 2.6.0 del backend. El aviso original lo publicó el mantenedor kmendell el 29 de julio de 2026, casi tres meses antes de que el GitHub Advisory Database lo revisara y lo incorporara a su catálogo esta semana -una demora que significa que ninguna herramienta automatizada de escaneo de dependencias, como Dependabot, pudo alertar sobre la falla durante ese tiempo-. Que un permiso diseñado deliberadamente para quedar por debajo del rol de administrador termine permitiendo tomar esa cuenta por completo es el mismo tipo de falla de jerarquía de privilegios que ya ha aparecido en otras plataformas de gestión interna esta semana: la promesa de un control de acceso granular depende de que cada permiso respete en código, no solo en la interfaz, el límite que el operador cree estar fijando. La información de este caso proviene únicamente del aviso oficial de GitHub, sin cobertura cruzada de un medio de seguridad especializado al cierre de esta edición. Arcane es una herramienta todavía de nicho frente a Portainer o Rancher, sin adopción reportada públicamente entre empresas de desarrollo costarricenses; equipos pequeños o de uso personal que la tengan autoalojada deberían actualizar a la versión 2.6.0 antes de delegar cualquier permiso a usuarios que no sean de plena confianza, sin que se conozca un caso costarricense afectado al cierre de esta edición.
El GitHub Advisory Database revisó y actualizó, el 16 de octubre de 2026, dos avisos de severidad alta para librerías de Go. El primero, GHSA-74vm-87hj-r66f (CVE-2026-100349, CVSS 4.0 de 8.2), afecta a github.com/getkin/kin-openapi, el validador de especificaciones OpenAPI más usado en servicios Go: según la descripción oficial, la función ValidateResponse sufre un desreferenciamiento de puntero nulo cuando una especificación declara un encabezado de respuesta usando content en vez de schema -el documento sigue pasando la validación general de doc.Validate(), y basta con declarar ese encabezado para que el panic ocurra en cada llamada a esa operación, sin que la respuesta real necesite incluirlo siquiera-. Es la segunda falla de este tipo que kin-openapi corrige en dos días: el aviso aclara que GHSA-jpcw-4wr7-c3vq, corregido en la versión 0.144.0, cubrió la misma clase de error para parámetros de solicitud; esta cubre encabezados de respuesta, con una exposición distinta porque el disparador vive en la propia especificación, no en algo que el atacante deba enviar. El investigador vnykmshr reportó la falla, corregida en la versión 0.146.0. El segundo aviso, GHSA-cv23-7vc5-jfh7 (CVE-2026-102941, CVSS 3.1 de 7.5), afecta a github.com/gomarkdown/markdown: la función IsSafeURL corta la cadena de entrada antes de verificar su longitud, y una URL de cero a dos caracteres -más corta que los prefijos "/", "./" o "../" que la función espera- produce un panic de límites de slice sin capturar, que termina el proceso completo; el error es alcanzable a través de markdown.ToHTML cuando la bandera html.Safelink está activa y un enlace tiene un destino vacío o muy corto, como [x](). El investigador arpitjain099 reportó la falla, que existe desde 2022 según confirmó el propio mantenedor, kjk, en el commit e08cff8. Las dos fallas comparten la misma forma de fondo: una entrada que la propia librería considera validada -una especificación que ya pasó su verificación general, una URL que el código trata como segura por defecto- termina provocando un desreferenciamiento o un corte de arreglo que Go no recupera solo, y que apaga el proceso entero en vez de devolver un error. Que kin-openapi reciba dos avisos de la misma familia de error en dos días consecutivos sugiere que la corrección de la primera variante no cerró el patrón de fondo que la produjo. La información de estos dos casos proviene únicamente de los avisos oficiales de GitHub, sin cobertura cruzada de un medio de seguridad especializado al cierre de esta edición. Ninguna de las dos fallas permite ejecutar código ni filtrar datos -ambas clasifican como impacto exclusivo de disponibilidad-, y la de gomarkdown exige además que el servicio afectado active explícitamente la bandera Safelink o llame directamente a la función de bajo nivel IsSafeURL, algo que no ocurre en la ruta de renderizado por defecto. kin-openapi y gomarkdown son librerías de uso común entre equipos de backend costarricenses que construyen APIs o generan documentación en Go; esos equipos deberían revisar su versión en el próximo ciclo de dependencias, sin que se conozca un caso costarricense afectado por ninguna de las dos.
— Un encabezado de respuesta declarado con content hace panic a kin-openapi, y una URL de uno o dos caracteres provoca lo mismo en gomarkdown, según dos avisos que GitHub revisó el 16 de octubre.
El GitHub Advisory Database revisó y actualizó, el 16 de octubre de 2026, dos avisos para proyectos de Rust. El primero, GHSA-4ch3-9j33-3pmj (CVE-2026-58494, CVSS 3.1 de 6.5, severidad moderada), afecta a wasmtime-wasi, la implementación de la interfaz de sistema de archivos WASI del runtime de WebAssembly Wasmtime, mantenido por la Bytecode Alliance. Según la descripción oficial, un programa invitado con permiso de solo lectura sobre un directorio preabierto puede crear un enlace físico (hard link) hacia ese archivo dentro de un segundo directorio preabierto que sí admite escritura y mutación, y luego sobrescribir el archivo del anfitrión a través de ese enlace -renombrar el enlace produce el mismo efecto-, lo que burla los permisos por directorio (FilePerms) que WasiCtxBuilder había fijado. La falla afecta a cuatro rangos de versiones distintos y la corrigen las versiones 24.0.11, 36.0.12, 45.0.3 y 46.0.1; el propio aviso aclara que la CLI de Wasmtime no está expuesta, porque siempre otorga permisos completos de archivo. El investigador sdjasj reportó la falla. El segundo aviso, GHSA-6fj4-rcr3-r7rr (CVSS 3.1 de 7.5, severidad alta, sin CVE asignado al cierre de esta edición), afecta a lopdf, la librería de Rust para leer y escribir archivos PDF: sus funciones de carga analizan arreglos y diccionarios anidados con recursión sin límite, y un documento con un Catalog de unos 10.000 niveles de anidamiento agota la pila de llamadas y aborta el proceso con SIGABRT -una señal de aborto, no un panic de Rust, por lo que catch_unwind no puede interceptarla-. El propio aviso precisa que un PDF de apenas 21 kilobytes basta para provocarlo en la configuración por defecto. La versión 0.42.0 corrige la falla. Ambas fallas viven en librerías de Rust elegidas, en parte, por las garantías de seguridad de memoria del lenguaje, pero las dos tiran el proceso completo por vías que esas garantías no cubren: los permisos de archivo son responsabilidad de quien integra el runtime, no del compilador, y una señal de aborto del sistema operativo queda fuera del alcance del manejo de panics de Rust. Wasmtime, en particular, es la base de sistemas de plugins aislados que van más allá de su propia comunidad -el mismo estándar WASI subyace a modelos de aislamiento que usan otros proveedores de borde-, así que una falla en la implementación de referencia de su interfaz de archivos importa más allá de los usuarios directos del proyecto. La información de estos dos casos proviene únicamente de los avisos oficiales de GitHub, sin cobertura cruzada de un medio de seguridad especializado al cierre de esta edición. El caso de lopdf exige que una aplicación analice un PDF sin confiar con la configuración por defecto; un equipo que ya limite el tamaño de los documentos que acepta, o que aísle ese análisis en un proceso separado, acota el daño a ese proceso y no al servicio completo. Costa Rica no tiene un proveedor propio de runtimes de WebAssembly, pero cualquier equipo tico que construya un sistema de plugins sobre Wasmtime, o que procese PDF subidos por usuarios -trámites digitales, por ejemplo- debería confirmar su versión antes de aceptar archivos sin revisar, sin que se conozca un caso costarricense afectado por ninguna de las dos fallas.
El proyecto compromised-packages-check documentó, en su barrido del 17 y 18 de octubre, un clúster de ocho paquetes que imitan herramientas de voz y dos infostealers más, todos en PyPI y ninguno en npm.
El proyecto de código abierto compromised-packages-check registró, en su PR 161 -fusionado el 18 de octubre de 2026 con datos del volcado masivo de OSV del 17 y 18 de octubre-, 10 entradas nuevas de paquetes maliciosos, todas en PyPI, según el registro público del proyecto en GitHub. El lote más grande es un clúster de ocho paquetes atribuido a una cuenta identificada como kam193, que se presentan falsamente como librerías de texto a voz o de reconocimiento de voz: driftwavets, emberlytts, glassbeakasr, novalithtts, pyrechoasr, quasitonnts, tonemaptts y voltswannts, todos publicados en su versión 0.1.0. El registro documenta además ukraine69, descrito como un infostealer cuyo archivo __init__.py luce inocuo pero esconde una carga maliciosa, con ocho versiones distintas marcadas (de la 1.2.0 a la 1.2.8); y leakdeep, que se presenta como herramienta de verificación de credenciales filtradas (OSINT) pero roba credenciales al instalarse o importarse, con cinco versiones marcadas (de la 2.5.0 a la 2.6.6). Es la primera vez en varios días que el barrido de este proyecto no reporta ningún paquete nuevo en npm, algo que no indica necesariamente una pausa en los ataques contra ese registro, sino que el lote de hoy se concentró por completo en PyPI. El clúster de ocho paquetes de voz falsos sigue un patrón distinto al typosquatting habitual que domina el rastreo de los últimos días: en vez de imitar el nombre de una librería real y ya instalada, inventa nombres creíbles para una categoría de herramienta con demanda genuina -texto a voz, reconocimiento de voz-, apostando a que alguien busque e instale una de las ocho variantes sin verificar su origen. leakdeep, por su parte, se monta sobre la demanda de herramientas ofensivas de ciberseguridad para distribuir justamente el tipo de robo de credenciales que dice ayudar a detectar. La información de este caso proviene únicamente del registro del proyecto compromised-packages-check en GitHub, sin confirmación cruzada de Socket.dev, Phylum o Sonatype al cierre de esta edición. Cualquier desarrollador costarricense que instale paquetes de Python para procesamiento de audio o para verificar si sus credenciales aparecen en filtraciones conocidas enfrenta el mismo tipo de riesgo que documenta este lote, sin que se conozca un caso costarricense afectado.
cat /feed/cloudflareworkersworkerd.md
La versión del 18 de octubre de workerd corrige solo una prueba de referencia inestable y actualiza una guía interna, un día después de que el motor integrara la primera contribución de Ryan Dahl y el salto a V8 15.7.
> Cloudflare publicó, el 18 de octubre de 2026, la versión v1.20261018.1 de workerd, el motor de código abierto que corre Cloudflare Workers, con apenas dos cambios fusionados según el registro oficial de versiones del proyecto en GitHub: una actualización sin cambios de comportamiento que agrega lineamientos de "incluye lo que usas" al archivo AGENTS.md del proyecto y elimina una verificación interna llamada rust_io_link_check (PR #7736), y una corrección que estabiliza la prueba de referencia de rendimiento del servidor, que venía fallando de forma intermitente (PR #7797).
> La entrega de hoy contrasta con la de ayer, cuando workerd sumó a su historial la primera contribución firmada por la cuenta ry -de Ryan Dahl, creador de Node.js y de Deno-, apenas una semana después de que Cloudflare anunciara la incorporación de todo el equipo de Deno, y actualizó el motor V8 a la versión 15.7, según esta sección reportó el 17 de octubre. El ciclo de publicación diaria de workerd vuelve, con la versión de hoy, al patrón de mantenimiento incremental que domina la mayoría de sus entregas: sin ningún cambio de comportamiento visible para quien despliega un Worker.
> La información de este caso proviene únicamente del registro oficial de versiones de workerd en GitHub, sin cobertura cruzada de un medio especializado al cierre de esta edición. Costa Rica no aloja una región de Cloudflare, pero agencias digitales y startups ticas que despliegan aplicaciones sobre Workers reciben esta actualización de forma automática en su próximo despliegue, sin que haya, en este caso, ningún cambio de comportamiento que revisar.
La jornada del 18 de octubre la abre un aviso con la severidad máxima que admite el estándar CVSS: una imagen marcada como "checkpoint" puede hacer que podman run ignore casi toda la configuración de seguridad del operador, aunque el propio aviso aclara que el modo sin privilegios de raíz -la configuración recomendada por defecto- no está afectado. Arcane corrigió un fallo que dejaba tomar la cuenta administradora completa con solo el permiso delegado users:update, y GitHub revisó otras cuatro fallas que terminan el proceso en vez de devolver un error: dos nil-pointer panics en kin-openapi -la segunda en dos días- y en gomarkdown, y dos más en Rust, un bypass de permisos de archivo en wasmtime-wasi y un agotamiento de pila en lopdf que un PDF de 21 kilobytes basta para provocar. El rastreo comunitario de paquetes maliciosos sumó 10 entradas nuevas, todas en PyPI y ninguna en npm por primera vez en varios días, encabezadas por un clúster de ocho paquetes que se presentan falsamente como herramientas de voz. Cloudflare cerró, además, la semana del primer parche de Ryan Dahl en workerd con una versión puramente de mantenimiento. Todas las historias completas, con sus fuentes primarias, quedan disponibles arriba para decidir qué parchar o revisar primero esta semana.