Un aviso de seguridad describe el nuevo parche de Argo Workflows como la corrección de una corrección anterior contra plantillas maliciosas, mientras Lima VM cierra una vía a privilegios de raíz, Authorizer tapa un robo de cuenta por OAuth y Next.js suma tres versiones canary más a su afinamiento de Turbopack.
La versión 3.7.15 corrige CVE-2026-54526, que dejaba abierta la puerta que un primer parche, de meses atrás, prometió cerrar contra plantillas de flujo de trabajo maliciosas.
Argo Workflows, el motor de flujos de trabajo nativo de Kubernetes que forma parte de la Cloud Native Computing Foundation (CNCF), publicó las versiones 3.7.15 y 4.0.6, que corrigen CVE-2026-54526, según el aviso de seguridad publicado en la base de datos de GitHub Advisory. La falla, con una puntuación CVSS de 8,9 sobre 10, permite que el campo ArtifactGC.PodSpecPatch —usado para configurar la limpieza automática de artefactos— sortee la lista de referencias permitidas que los modos Strict y Secure de Argo Workflows imponen sobre las plantillas de flujo de trabajo, según describe el propio aviso. Un usuario con permiso para crear flujos de trabajo podía inyectar un parche de especificación de pod (strategic merge patch) que agregara volúmenes hostPath, contenedores privilegiados o acceso a la red del nodo anfitrión, es decir, exactamente lo que esos modos de seguridad están diseñados para impedir. El aviso identifica el problema como una corrección incompleta de CVE-2026-31892, una falla similar que Argo Workflows ya había parchado meses antes: la validación de la lista de referencias permitidas solo revisaba, por reflexión, los campos de primer nivel de WorkflowSpec, sin bajar a subcampos anidados como PodSpecPatch dentro de estructuras ya permitidas como ArtifactGC. Ese detalle —un parche que cerró la puerta principal pero dejó una ventana lateral abierta— consta en el propio texto del aviso de seguridad, no en una crítica externa, y expone un patrón conocido en el diseño de listas de permitidos basadas en reflexión: cada campo nuevo que un mantenedor agrega a una estructura ya autorizada necesita revisión explícita, o hereda el permiso de su contenedor sin que nadie lo haya decidido así. Las versiones 2.x de Argo Workflows, que llegaron a su fin de soporte, no recibirán parche, según el mismo aviso. La información de esta nota proviene únicamente del aviso de seguridad publicado en la base de datos de GitHub Advisory, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Argo Workflows, pero la herramienta es una opción común entre equipos de plataforma que ya corren Kubernetes en la nube para orquestar canalizaciones de datos o de integración continua, a los que conviene actualizar a la versión 3.7.15 o 4.0.6 y revisar si algún flujo de trabajo de terceros usa el campo ArtifactGC.PodSpecPatch antes de confiar en los modos Strict o Secure como única barrera de seguridad.
El proyecto de código abierto Lima, una herramienta que crea máquinas virtuales Linux para correr contenedores en macOS y Linux —usada como alternativa ligera a Docker Desktop por herramientas como Rancher Desktop y Colima—, corrigió en su versión 2.1.3 la falla CVE-2026-53657, con una puntuación CVSS de 8,2 sobre 10, según el aviso de seguridad de la base de datos de GitHub Advisory. El problema afecta a las instancias que usan el controlador QEMU: cualquier usuario dentro de la máquina virtual, sin necesidad de privilegios previos, podía acceder al socket del agente invitado en /run/lima-guestagent.sock, que ofrece un servicio de túnel hacia cualquier dirección, incluida la de sockets Unix de demonios privilegiados como D-Bus, y usarlo para ejecutar comandos con privilegios de superusuario dentro de la máquina virtual, según describe el propio aviso. La falla no compromete la máquina física que aloja la máquina virtual, y no afecta a quienes usan el controlador VZ de Apple en lugar de QEMU, porque ese controlador se comunica por vsocks en lugar de sockets Unix, según el aviso. El hallazgo importa para cualquier flujo de trabajo que ejecute código de terceros o de múltiples usuarios dentro de una misma máquina virtual Lima —un escenario habitual en entornos de integración continua compartidos— porque reduce a cero la barrera entre un usuario sin privilegios y el control total de esa máquina. La información de esta nota proviene únicamente del aviso de seguridad oficial de Lima en la base de datos de GitHub Advisory, sin cobertura cruzada de otro medio al cierre de esta edición. Mientras se actualiza a la versión 2.1.3, el propio aviso recomienda dos salidas alternativas: cambiar al controlador VZ en macOS o desactivar por completo el agente invitado. Costa Rica no publica cifras propias de adopción de Lima, pero la herramienta gana terreno entre desarrolladores locales que buscan alternativas gratuitas a Docker Desktop en Mac, a quienes conviene revisar hoy mismo qué controlador usan sus instancias antes de correr cargas de trabajo de terceros dentro de ellas.
El proyecto de código abierto Authorizer, una plataforma de autenticación autoalojada, corrigió el 7 de agosto de 2026 la falla CVE-2026-35511, con una puntuación CVSS de 8,7 sobre 10, según el aviso de seguridad de la base de datos de GitHub Advisory, catalogado el 13 de agosto. El problema está en la forma en que Authorizer vincula identidades de proveedores externos —Google, GitHub, Facebook, Apple, LinkedIn, Twitter, Discord, Twitch, Roblox y Microsoft, según el aviso— a cuentas existentes que coinciden por dirección de correo, sin verificar si el dueño original de esa cuenta confirmó realmente ese correo. Un atacante podía registrarse primero con el correo de otra persona sin confirmarlo, y cuando la víctima real iniciara sesión después con su proveedor de OAuth, el sistema vinculaba automáticamente esa identidad a la cuenta ya creada por el atacante —marcando el correo como verificado y sumando el proveedor de OAuth a los métodos de acceso, sin invalidar la contraseña original que el atacante ya conocía. El resultado es una puerta trasera persistente: incluso si la víctima revoca el acceso de OAuth después de notar algo raro, el atacante conserva acceso por contraseña a la cuenta, según describe el aviso. La falla afecta a todas las versiones de Authorizer anteriores a la publicada el 7 de agosto de 2026, identificada por su hash de módulo Go en lugar de un número de versión tradicional. La información de esta nota proviene únicamente del aviso de seguridad oficial de Authorizer en la base de datos de GitHub Advisory, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Authorizer, pero la herramienta es una opción de código abierto para equipos que buscan alternativas autoalojadas a servicios de autenticación comerciales, a los que conviene actualizar de inmediato y revisar sus registros de usuarios en busca de cuentas creadas con correos que nunca llegaron a verificarse.
Budibase, la plataforma de código abierto para construir aplicaciones internas de bajo código, publicó el 14 de agosto de 2026 la versión 3.41.3 de su paquete de servidor (@budibase/server), que corrige CVE-2026-35219, una falla de falsificación de solicitudes del lado del servidor (SSRF) con una puntuación CVSS de 7,1 sobre 10, según el aviso de seguridad publicado ese mismo día en la base de datos de GitHub Advisory. El problema está en las funciones de automatización que se conectan a webhooks, Zapier, n8n, Slack y Discord: en lugar de pasar por la capa de validación de direcciones que Budibase aplica en otros puntos, esas integraciones usaban directamente la librería node-fetch, sin revisar si la dirección de destino apuntaba a una red interna. Además, según el aviso, la lista de bloqueo de direcciones IP de la integración REST queda vacía por defecto si nadie configura la variable de entorno BLACKLIST_IPS, lo que deja ese punto de entrada también expuesto. En la práctica, cualquier usuario con permiso para crear una automatización podía apuntarla contra direcciones internas como 169.254.169.254 —el servicio de metadatos que exponen los proveedores de nube pública para entregar credenciales temporales a las máquinas virtuales—, bases de datos privadas o la API de un clúster de Kubernetes en una red restringida. El aviso recomienda activar por defecto la protección contra SSRF en todos los clientes HTTP salientes, en lugar de dejarla como una configuración opcional, y bloquear por defecto los rangos de direcciones privadas. La información de esta nota proviene únicamente del aviso de seguridad oficial de Budibase en la base de datos de GitHub Advisory, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Budibase, pero la herramienta es una opción habitual entre equipos internos que arman paneles y flujos de aprobación sin escribir una aplicación completa desde cero, a los que conviene actualizar a la versión 3.41.3 y revisar si su despliegue corre dentro de una nube pública con servicio de metadatos accesible desde la red de la aplicación.
GitHub sumó, el 14 de agosto de 2026, a su base de datos de avisos de seguridad la falla CVE-2026-55153, que afecta a mchange-commons-java, una librería de utilidades para conexión a bases de datos en Java que forma parte del proyecto c3p0, un agrupador de conexiones (connection pooler) usado como dependencia transitiva en aplicaciones empresariales Java. El aviso, con una puntuación CVSS de 7,1 sobre 10 y clasificado bajo la categoría CWE-470 de reflexión insegura, describe dos problemas distintos en la implementación de fábricas de objetos JNDI (JavaBeanObjectFactory) de la librería: antes de la versión 0.6.0, esa fábrica podía instanciar clases arbitrarias y asignarles propiedades sin restricción —el aviso pone como ejemplo que inicializar un componente Swing JEditorPane con contenido HTML podía disparar solicitudes HTTP no deseadas—, y antes de la versión 0.5.0, la librería deserializaba objetos Java no confiables, lo que, según el aviso, abría la puerta a cadenas de gadgets de deserialización usando librerías como commons-beanutils y commons-collections. Este tipo de falla —deserialización insegura combinada con referencias JNDI maliciosas— es la misma familia de problema que causó Log4Shell en diciembre de 2021, una de las vulnerabilidades más explotadas de la última década en el ecosistema Java. Los parches de mchange-commons-java, según el propio aviso, corrigen el problema eliminando la deserialización insegura, aplicando una lista de clases permitidas para la instanciación de objetos y desactivando por defecto el mecanismo ReferenceIndirector que permitía inyectar referencias JNDI maliciosas a través de objetos deserializados. El aviso no precisa si hubo explotación activa antes del parche, ni desde cuándo el código problemático estaba presente en la librería. La información de esta nota proviene únicamente del aviso de seguridad de la base de datos de GitHub Advisory, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de c3p0 o mchange-commons-java, pero ambas librerías circulan como dependencia transitiva —sin que el equipo que las usa las haya elegido de forma directa— en aplicaciones Java empresariales que corren en bancos, aseguradoras y otras empresas con backend Java en el país, a las que conviene ejecutar un inventario de dependencias para confirmar si arrastran una versión de mchange-commons-java anterior a la 0.6.0.
— El aviso, sumado a la base de datos de GitHub el 14 de agosto, documenta dos fallas —ya corregidas en versiones 0.5.0 y 0.6.0— en una librería de utilidades para conexión a bases de datos.
cat /feed/herramientasdevnextjs.md
Las versiones 16.3.1-canary.17 a 16.3.1-canary.19, publicadas entre el 13 y el 14 de agosto, limpian manifiestos obsoletos, corrigen el caché de disco de imágenes y adoptan un nuevo sistema de metadatos.
> > next --version
> Vercel publicó, entre el 13 y el 14 de agosto de 2026, tres versiones más de la rama canary de Next.js 16.3.1 —canary.17, canary.18 y canary.19—, según el registro oficial de lanzamientos del proyecto en GitHub. La secuencia continúa el ciclo de afinamiento de Turbopack, el empaquetador escrito en Rust que Next.js viene puliendo desde inicios de agosto: canary.19, publicada el 14 de agosto a las 23:46 UTC, adopta un nuevo sistema de metadatos para el renderizado (SelectedMetadata), corrige el caché en disco de imágenes para rechazar imágenes vacías al leer o escribir, y elimina manifiestos obsoletos de rutas ya borradas que Turbopack dejaba huérfanos en el caché.
> > next build --profile
> Las versiones canary.17 y canary.18, del 13 de agosto, sumaron pruebas unitarias para la tabla de seguimiento de archivos de Turbopack y actualizaron las dependencias de React del proyecto, según el mismo registro de cambios. Esta sección documentó, el 12 de agosto, cinco versiones canary consecutivas centradas en acelerar el caché de Turbopack; la tanda de esta edición confirma que Vercel no ha cerrado ese ciclo y sigue publicando ajustes incrementales casi a diario, sin que el registro de cambios adelante todavía una fecha para promover Turbopack a empaquetador por defecto fuera del modo de desarrollo.
> > next --why
> La información de esta nota proviene únicamente del registro de lanzamientos oficial de Next.js en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Next.js, pero el framework es una opción dominante entre agencias y startups locales que construyen aplicaciones web con React, a las que conviene seguir tratando cada versión canary como una vista previa de trabajo en progreso antes de adoptarla en producción.
SurrealDB, la base de datos de código abierto escrita en Rust, corrigió en su versión 3.1.4 la falla identificada como GHSA-8rw6-p7m8-63jp, con una puntuación CVSS de 6,5 sobre 10 y severidad moderada, según el aviso de seguridad sumado a la base de datos de GitHub Advisory el 14 de agosto de 2026. El problema afecta a las tablas que definen permisos de selección a nivel de elemento de un arreglo, mediante la sintaxis field.*: la lógica que filtraba los elementos denegados los eliminaba por índice mientras recorría el arreglo hacia adelante, de modo que cada eliminación desplazaba los índices siguientes y las comprobaciones posteriores terminaban revisando la posición equivocada, dejando expuestos elementos que el permiso debía ocultar, según describe el propio aviso. El efecto es una fuga de confidencialidad —no de integridad ni de disponibilidad, aclara el aviso—: un usuario con sesión de registro podía leer elementos de un arreglo en tablas a las que sí tenía acceso, pero que los permisos por elemento debían mantener ocultos. Los permisos definidos a nivel de campo completo, y las sesiones de raíz o de dueño de registro, no se vieron afectados. La corrección invierte el orden: ahora la librería elimina los elementos denegados en orden de índice inverso, lo que evita el desplazamiento que causaba el problema. La información de esta nota proviene únicamente del aviso de seguridad de la base de datos de GitHub Advisory, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de SurrealDB, pero la base de datos gana terreno entre equipos locales que buscan una alternativa a bases relacionales y documentales tradicionales para aplicaciones con modelos de permisos complejos, a los que conviene actualizar a la versión 3.1.4 y revisar si algún esquema propio usa permisos field.* sobre arreglos.
Entre un parche de Kubernetes que quedó incompleto dos veces y una librería Java con deserialización insegura, esta edición documenta siete desarrollos recientes en el ecosistema de programación.
Esta edición documentó siete desarrollos entre el 12 y el 14 de agosto de 2026: la corrección de Argo Workflows a un parche que, según su propio aviso de seguridad, dejó incompleta la defensa contra plantillas maliciosas; la falla de privilegios de raíz que Lima VM cerró en el socket de su agente invitado; el robo de cuenta por vinculación de OAuth sin verificar que Authorizer corrigió; la falsificación de solicitudes del servidor que exponía redes internas desde las automatizaciones de Budibase; la deserialización insegura que GitHub catalogó en la librería Java mchange-commons; la fuga de datos por permisos mal calculados que SurrealDB cerró en sus arreglos; y tres versiones canary más de Next.js que siguen afinando el caché de Turbopack. El patrón que domina la semana es el mismo que esta sección viene señalando desde el lunes: la mayoría de las fallas de severidad alta —Argo Workflows con CVSS 8,9, Lima VM con 8,2, Authorizer con 8,7— vive en herramientas de código abierto de uso específico, con avisos que rara vez llegan a la cobertura de medios generalistas pero exponen a cualquier equipo que no revise sus propias dependencias. El caso de Argo Workflows es el más elocuente: el propio aviso de seguridad describe el nuevo parche como una corrección de una corrección anterior, evidencia de que cerrar una lista de permitidos por reflexión es más difícil de lo que parece cuando la estructura de datos permitida crece con el tiempo. Para equipos de desarrollo en Costa Rica, la lista de esta semana suma tareas concretas: actualizar Argo Workflows a 3.7.15 o 4.0.6 si corre flujos de trabajo de terceros; revisar el controlador de Lima VM antes de compartir una máquina virtual entre varios usuarios; y confirmar si algún proyecto Java propio arrastra mchange-commons-java como dependencia transitiva anterior a la versión 0.6.0.