Python.org confirma que la versión 3.15.0 ya está disponible tras tres ediciones sin poder verificarlo, Hazelcast corrige una fuga crítica que deja leer la memoria de cualquier nodo del clúster, un complemento oficial de Payload permite ejecutar código con el puntaje máximo de severidad y AsyncHttpClient filtra credenciales al reenviar una solicitud a otro servidor.
La página oficial de descargas de Python.org lista el 9 de octubre de 2026 como fecha de la versión estable 3.15.0, el cierre de un ciclo de desarrollo de 17 meses con 5.643 commits aportados por 1.012 personas, según la propia página de la versión. Entre las novedades que trae esta entrega destacan el sistema de importaciones diferidas (lazy imports), el tipo incorporado frozendict para diccionarios inmutables y con hash (PEP 814), el tipo sentinel (PEP 661), el desempaquetado dentro de comprensiones (PEP 798), UTF-8 como codificación por defecto (PEP 686) y un perfilador estadístico de muestreo (PEP 799) que captura la pila de llamadas periódicamente en lugar de instrumentar cada función, según el mismo registro oficial y la cobertura de Real Python. Esta sección documentó, el 5, el 6, el 9 y el 10 de octubre, el mismo patrón: la fecha de 3.15.0 se movió del 1° de octubre original fijado por el PEP 790 hasta el 9 de octubre, tras bloqueos de última hora en la propia función de importación diferida que hoy ya forma parte de la versión final, y los canales públicos del proyecto -blog oficial, foro de discusión, página de descargas- tardaron en reflejar con claridad que el lanzamiento ya había ocurrido. Que la confirmación llegue recién hoy, dos días después de la fecha que figura en la propia página de descargas, documenta cuánto puede tardar un proyecto de código abierto grande en comunicar con claridad un cambio de estado tan simple como si una versión ya salió, más que señalar un problema técnico del lanzamiento en sí. Equipos que planificaban migrar a Python 3.15 este mes ya pueden actualizar sus entornos de prueba contra la versión final publicada en la página oficial. Costa Rica tiene una comunidad amplia de programadores Python en ciencia de datos, automatización y educación, concentrada en zonas francas y universidades, que ahora puede planificar su propio calendario de adopción sobre una fecha ya confirmada, sin que se conozca todavía un cronograma de migración distinto al del resto del ecosistema.
El GitHub Advisory Database publicó, el 8 de octubre de 2026, el aviso GHSA-6v25-8wq6-xq4j (CVE-2026-107726, CVSS v4.0 de 9.3) para Hazelcast, la plataforma de cómputo distribuido y malla de datos en memoria usada por aplicaciones Java empresariales: según la descripción oficial, el motor no valida correctamente los datos que envía un cliente ya conectado al clúster, lo que permite "a un cliente malicioso de bajo privilegio leer datos arbitrarios en memoria de cualquier nodo del clúster" -incluido el montón de Java, memoria fuera del montón y el espacio de direcciones del propio proceso. El mismo aviso agrega que ese cliente "puede provocar que uno o más nodos del clúster se caigan" y que, en algunas configuraciones de la edición Enterprise, el error "también puede corromper el contenido de la memoria, lo que podría derivar en ejecución remota de código". La falla afecta las versiones anteriores a 5.4.5, la serie 5.5.x anterior a 5.5.10 y la versión exacta 5.6.0; el parche llega en la 5.7.0 para la edición Community, o en 5.6.1, 5.5.10 y 5.4.5 para quienes usan Enterprise, según el crédito del propio aviso al investigador k-jamroz. El puntaje de 9.3 conviene matizarlo con dos datos del propio ecosistema de vulnerabilidades: el modelo EPSS, que estima la probabilidad de explotación real en los próximos 30 días, ubica esta falla en apenas 0,383% -el percentil 30 de todas las vulnerabilidades registradas-, y el vector CVSS exige que el atacante ya tenga una conexión de cliente al clúster, no un acceso anónimo desde internet. Hazelcast documenta desde hace años, en su propia guía de endurecimiento de seguridad, que restringir el acceso al clúster a clientes de confianza y activar la autorización por cliente reduce justamente este tipo de riesgo; el aviso repite esa misma recomendación como mitigación mientras se aplica el parche. 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. Hazelcast es una pieza común de arquitecturas Java de caché y sesión distribuida en bancos y empresas de zona franca costarricenses que corren backends empresariales sobre Java y Spring; equipos que expongan su clúster más allá de una red interna de confianza deberían revisar su versión antes del próximo despliegue, sin que se conozca un caso costarricense afectado al cierre de esta edición.
El GitHub Advisory Database publicó, el 8 de octubre de 2026, el aviso GHSA-jmqq-x5g9-9p2w (CVE-2026-107282, CVSS v4.0 de 9.4) para async-http-client, el cliente HTTP de Java del proyecto AsyncHttpClient: cuando una solicitud se reenvía a un segundo host, "el cliente actualiza solo la solicitud visible y deja el objetivo interno apuntando al host original", según la descripción oficial. Cuatro rutas de código distintas -el manejo del grupo de conexiones, los túneles CONNECT, la selección de credenciales (realm) y las decisiones de TLS- siguen leyendo ese objetivo interno sin actualizar, lo que hace que la petición, las credenciales o ambas del primer servidor terminen llegando al segundo. El propio aviso aclara que "el atacante no necesita inducir el reenvío": basta con que la aplicación use una función normal del cliente, como un ResponseFilter para manejar fallos o el reintento automático ante una IOException, para que el error se dispare. La falla afecta las versiones 3.0.0 a 3.0.12 y 2.0.0 a 2.16.0 por igual; el parche llega en la 3.0.13 y la 2.16.1. El puntaje de 9.4 -casi el máximo posible- pide matizarlo con el propio texto técnico del aviso: el vector CVSS v4.0 marca complejidad de ataque alta y exige que ya existan requisitos previos (AC:H, AT:P), y el modelo EPSS calcula apenas 0,189% de probabilidad de explotación en 30 días -el percentil 8, uno de los más bajos entre las vulnerabilidades registradas este año-. El propio aviso agrega, además, que el comportamiento "es de larga data, no una regresión reciente": existe desde las primeras versiones de ambas ramas, no apareció de un día para otro. El riesgo real, entonces, queda acotado a aplicaciones que ya configuren reintentos o filtros de respuesta capaces de cambiar de host y que, además, manejen credenciales o un proxy en esas solicitudes -una combinación específica, no el uso por defecto del cliente. 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. Quien use un ResponseFilter que pueda reenviar a un host distinto, o reintentos automáticos con credenciales o proxy configurados, debería actualizar a la versión 3.0.13 o 2.16.1 cuanto antes. AsyncHttpClient es una librería común en backends Java que integran APIs externas de pago o de terceros en bancos y empresas de zona franca costarricenses; equipos que usen esa combinación específica de reintentos y credenciales deberían revisar su configuración, sin que se conozca un caso costarricense afectado.
Cualquier envío a un formulario construido con @payloadcms/plugin-form-builder puede ejecutar código remoto en el servidor, con el puntaje máximo de severidad posible, según GitHub.
El GitHub Advisory Database publicó, el 7 de octubre de 2026, el aviso GHSA-r488-j9vj-wx3q (CVE-2026-105857, CVSS v3.1 de 10.0, el máximo posible en la escala) para @payloadcms/plugin-form-builder, el complemento oficial del CMS headless Payload para construir formularios: según la descripción oficial, el paquete "permite envíos que pueden manipularse para ejecutar código remoto en el servidor", una combinación de inyección de código (CWE-94) y contaminación de prototipos (CWE-1321) que afecta a cualquier proyecto que use el complemento. La falla afecta las versiones anteriores a la 3.90.0 y las versiones canary 4.0.0-canary.0 a 4.0.0-canary.33; el parche llega en la 3.90.0 y la 4.0.0-canary.34. El propio mantenedor de Payload, DanRibbens, publicó el reporte original el 18 de setiembre, acreditando el hallazgo al investigador Zerotistic; la falla llegó a la base nacional de vulnerabilidades (NVD) el 6 de octubre y al registro público de GitHub un día después. Es el tercer CVE crítico que esta sección documenta sobre el ecosistema de Payload en poco más de un mes: el 8 de octubre ya cubrió dos fallas en el núcleo del CMS (CVE-2026-105859 y CVE-2026-105863), y esta nueva falla repite el patrón, pero esta vez en un complemento oficial -no en el núcleo- que suele quedar expuesto en formularios públicos de contacto o captación de clientes, sin autenticación previa. El modelo EPSS calcula 0,434% de probabilidad de explotación en 30 días -percentil 36-, el más alto de los tres avisos críticos de esta edición, lo que es consistente con que un formulario de envío público, por definición, es más accesible para un atacante que un panel administrativo o un cliente ya conectado a un clúster. 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. Agencias digitales costarricenses que usan Payload como gestor de contenido headless para sitios de clientes, y que además instalaron el complemento de formularios para capturar leads o contactos, deberían actualizar a la versión 3.90.0 de inmediato, dado que el vector de ataque -un formulario público- suele estar abierto a cualquier visitante; no se conoce un caso costarricense afectado al cierre de esta edición.
cat /feed/cloudflareworkersworkerd.md
La versión del 11 de octubre consolida las pruebas de flujos pendientes del cambio al objeto global WrapGlobal y deja de instalar flujos en C++ cuando el indicador de TypeScript está activo.
> Cloudflare publicó, el 11 de octubre de 2026, la versión v1.20261011.1 de workerd, el motor de código abierto que corre Cloudflare Workers, marcada como "Latest" en el registro oficial de versiones del proyecto en GitHub. La entrega consolida y limpia las pruebas de flujos (streams) que habían quedado pendientes tras los cambios de la canalización de instantáneas de arranque y el paso al objeto global WrapGlobal -ambos ya cubiertos por esta sección el 9 y el 10 de octubre-, deja de instalar los flujos escritos en C++ cuando el indicador experimental de TypeScript está activo, y mueve las dependencias de HTTP, TLS y WebSocket de kj-hyper detrás de interfaces tipadas de kj (kj-typed), según el changelog oficial del proyecto.
> Es la decimocuarta entrega que esta sección documenta en la racha casi diaria de workerd desde finales de setiembre, y la primera, en varios días, que no introduce un cambio estructural nuevo sino que cierra cabos sueltos de la migración a WrapGlobal que las dos versiones anteriores dejaron abiertos. El movimiento de dependencias detrás de interfaces tipadas continúa, además, el mismo patrón de modularización que esta sección registró el 5 y el 7 de octubre con las interfaces de Rust (into_kj, kj-rs-tokio): aislar cada pieza del motor detrás de una frontera explícita antes de seguir cambiando su funcionamiento interno.
> 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 se conozca un caso de uso local vinculado a este cambio específico.
El proyecto de código abierto compromised-packages-check registró, en su barrido fechado el 11 de octubre de 2026 (PR 154, commit cf51e62), seis entradas nuevas de paquetes maliciosos: una en npm y cinco en PyPI, según el registro público del proyecto en GitHub, que cita como fuente la exportación masiva de OSV del 10 de octubre. En npm, @library-wide/library-shell 99.9.1 se describe como un "centinela de confusión de dependencias" (OSV MAL-2026-17754) que imita el espacio de nombres de una organización específica, en lugar de typosquatear un paquete popular. En PyPI, el investigador kam193 identificó cinco paquetes como malware: agentaix (versiones 0.1.0 y 0.2.0, MAL-2026-17752), media-manager5 0.1.0 (MAL-2026-17753), agent-vx 0.1.0 (MAL-2026-17755), pafer (versiones 0.9.7 y 0.9.8, MAL-2026-17756) y webreader 2.3.8 (MAL-2026-17757). La cifra de hoy -seis- queda muy por debajo de los lotes de esta semana (40 el 9 de octubre, 44 el 8 y 9, 29 el 8), la más baja desde que esta sección empezó a seguir el indicador diario del proyecto. El cambio no es solo de volumen: el único hallazgo de npm de hoy es un centinela de confusión de dependencias contra un espacio de nombres corporativo puntual, no uno de los clústeres amplios de typosquats contra herramientas populares -Hardhat, Bitwarden, Baileys- que dominaron los barridos de la semana, y el grueso del lote de hoy se concentra en PyPI en lugar de npm. 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. Costa Rica tiene una comunidad amplia de programadores que instalan paquetes de PyPI a diario en zonas francas y startups; nombres genéricos como agentaix, pafer o webreader pueden confundirse fácilmente con herramientas legítimas, así que revisar el nombre exacto y el historial de publicación de cualquier paquete nuevo sigue siendo la defensa más simple, sin que se conozca un caso costarricense afectado por este lote.
— El proyecto compromised-packages-check documentó, el 11 de octubre, un paquete de npm que imita un espacio de nombres corporativo y cinco paquetes de PyPI identificados como malware, la cifra diaria más baja de la semana.
La jornada cierra, al fin, el arco que esta sección viene siguiendo desde el 5 de octubre: la página oficial de Python.org confirma que la versión 3.15.0 salió el 9 de octubre, dos días antes de que esta edición pudiera verificarlo. En seguridad, Hazelcast corrigió una falla crítica (CVSS 9.3) que permite a un cliente de bajo privilegio leer memoria de cualquier nodo del clúster, aunque el modelo EPSS le asigna apenas 0,383% de probabilidad de explotación real. AsyncHttpClient corrigió una fuga de credenciales al reenviar solicitudes a otro host -de larga data, según su propio aviso, y con una probabilidad de explotación aún más baja, 0,189%-, mientras que un complemento oficial de formularios de Payload sumó el tercer CVE crítico del ecosistema en poco más de un mes, este con el puntaje máximo posible y expuesto en formularios públicos sin autenticación. Cloudflare publicó una nueva versión de workerd que cierra cabos sueltos de su migración a WrapGlobal, y el rastreo comunitario de paquetes maliciosos registró apenas seis entradas nuevas, la cifra más baja de la semana. Todas las historias completas, con sus fuentes primarias, quedan disponibles arriba para decidir qué actualizar o parchar primero esta semana.