Lo que está pasando en tecnología, y por qué importa

Escenario (hipotético): durante tres noches seguidas, el clúster de base de datos de un sistema de ventas hace failover automático al nodo secundario. Nadie lo nota: los usuarios no reportan nada y en la mañana el monitoreo está en verde. La tentación es dar el tema por cerrado.

Qué dice ITIL® V5: en la sección 4.9.3, el libro reconoce que la recuperación automática o el cambio a recursos de respaldo minimizan el impacto, pero aclara que esos incidentes, aun con poco o ningún impacto en usuarios, muchas veces requieren investigación y resolución estructural. En 4.9.2 señala que los incidentes repetitivos son un disparador típico de la gestión de problemas.

Criterios para decidir:

1. ¿La conmutación perdió o duplicó transacciones? ¿Lo puedo verificar con datos, no con suposiciones?
2. ¿El secundario estaba sincronizado o había retraso de réplica?
3. ¿Hay patrón de hora, carga o tarea programada?
4. ¿Qué pasa la noche en que el secundario también falle?

Qué deberíamos hacer: iniciar gestión de problemas aunque nadie se haya quejado, cruzar el patrón con jobs y respaldos nocturnos, validar la integridad del dato tras cada conmutación y documentar una solución temporal mientras se diseña la definitiva. El post-mortem debe alimentar el siguiente diseño, no quedarse en un archivo.

¿En su equipo, un incidente invisible para el usuario se investiga o se archiva?

El 22 de octubre de 2026, The Hacker News informó que Railway, proveedor de Plataforma como Servicio (PaaS), detectó "actividad anómala" en los sistemas que almacenan las variables de entorno de sus clientes. Según la empresa, un tercero no autorizado pudo acceder a variables cifradas y, en algunos casos, a su contenido descifrado. El impacto se limita a un subconjunto de usuarios y la recomendación es rotar credenciales.

ITIL® V5 lo enmarca en la dimensión de socios y proveedores (sección 2.5): un proveedor integrado funciona como componente de nuestro servicio, y el riesgo de depender de él debe compararse con el de hacerlo internamente. La sección 4.9 (Support) pide que cada incidente se detecte, mitigue, resuelva, analice y se evite que se repita.

Criterios para decidir:

1. ¿Qué secretos nuestros vivían en ese proveedor y a qué sistemas dan acceso?
2. ¿Podemos rotarlos hoy sin afectar producción?
3. ¿Tenemos registros para saber si alguien usó esas credenciales?
4. ¿El acuerdo con el proveedor define quién notifica y en qué plazo?

Qué deberíamos hacer: asumir el compromiso aunque no estemos en el subconjunto afectado. Inventario de secretos, rotación priorizada por nivel de privilegio, revisión de accesos en las bases de datos y nubes conectadas, y después reducir permisos: cada credencial con el mínimo necesario.

¿Ustedes saben hoy qué secretos tienen guardados en su PaaS?

La factura de AWS no debería sorprender a nadie a fin de mes.

AWS Budgets permite dar seguimiento a costos y uso, y avisar cuando el gasto real o el pronosticado supera el monto presupuestado. Las notificaciones pueden ir a un correo, a un tema de Amazon SNS o a ambos. Tengan en cuenta algo que dice la propia documentación: la información se actualiza hasta tres veces al día y hay un retraso entre el cargo y el aviso, así que el gasto puede pasar el umbral antes de que llegue la alerta. Por eso conviene alertar también sobre el pronóstico, no solo sobre lo ya gastado.

En un equipo de TI se ve así: un presupuesto mensual de costo, alertas que llegan a un tema SNS que lee el equipo (no al buzón de una sola persona) y, si hace falta, una acción que aplique una política de IAM personalizada que impida aprovisionar más recursos. Esa acción la decide una persona y se prueba antes.

Les recomiendo:

1. Revisen en Cost Explorer el gasto de los últimos meses antes de fijar el monto, y en la calculadora de precios de AWS lo que planean agregar.
2. Creen un presupuesto de costo con alertas por gasto real y pronosticado.
3. Si usan RIs o Savings Plans, agreguen presupuestos de utilización y cobertura para detectar lo que se paga y no se usa.

¿Hoy quién se entera primero de un gasto fuera de lo normal: una alerta o la factura?

Si su Sprint Goal es una lista de tickets, en realidad no tienen Sprint Goal.

La Guía de Scrum (versión de noviembre de 2020) lo define como el único objetivo del Sprint y el compromiso del Sprint Backlog. Se crea en Sprint Planning al responder la primera pregunta: ¿por qué es valioso este Sprint? Y hay algo que a veces se nos pasa: da flexibilidad sobre el trabajo exacto para lograrlo. Si algo sale distinto a lo esperado, los Developers negocian el alcance con el Product Owner sin afectar el Sprint Goal.

En un equipo de TI se ve así: "Cerrar los tickets 214, 215 y 220" no guía a nadie. "Comprobar que podemos restaurar la base de datos de ventas desde el respaldo en un ambiente de pruebas" sí. Si a media semana falla un script, el equipo sabe qué priorizar y qué puede esperar. Igual en infraestructura o desarrollo: el objetivo dice el porqué; los ítems, el qué.

Les recomiendo:

1. Escriban el Sprint Goal en una frase que un stakeholder entienda, antes de cerrar Sprint Planning.
2. En el Daily Scrum, revisen cómo van hacia el Sprint Goal, no solo qué hizo cada quien.
3. Antes de meter trabajo nuevo, pregúntense si pone en riesgo el Sprint Goal; si es así, platíquenlo con el Product Owner.

¿Su último Sprint Goal les habría ayudado a decidir algo a mitad del Sprint?

El 23 de octubre de 2026, The Hacker News reportó que investigadores de Imperva demostraron "Node2Shell". Se trata de una prueba de concepto que ejecuta código del atacante en la imagen oficial de Node.js 24.22.0 para Linux arm64. No usaron depurador ni build personalizado. Bastó con enviar datos manipulados al decodificador Brotli incluido (CVE-2026-111497).

Por qué me importa: no es un laboratorio artificial, es la imagen oficial. Si su aplicación descomprime Brotli que llega de afuera (cuerpos de petición, archivos, respuestas de terceros), ese dato no confiable termina en la superficie de ataque.

Qué deberíamos hacer:

1. Inventariar qué servicios corren Node.js 24.22.0 y en qué arquitectura.
2. Identificar dónde se descomprime Brotli de origen no confiable.
3. Revisar el aviso primario de Node.js para confirmar las versiones afectadas y la corregida. La nota es de fuente secundaria y no lo detalla.
4. Actualizar con respaldo y plan de reversión, no a ciegas.

Trade-off: parchear la imagen base obliga a reconstruir y volver a probar todo lo que depende de ella. Aun así, la seguridad va primero.

¿Ustedes saben hoy cuántas de sus imágenes descomprimen datos que no controlan?

Seguro muchos ya lo saben, pero para quienes todavía no: el 21 de octubre PHP publicó correcciones para dos fallas críticas, CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell. Ambas permiten ejecutar código sin autenticación, con los privilegios del proceso que atiende las peticiones web.

Tengan en cuenta que no depende de un framework ni de un CMS: afecta a cualquier instalación que sirva peticiones web, con PHP-FPM, Apache mod_php, php-cgi, FrankenPHP o LiteSpeed. Rapid7 todavía no confirma explotación, pero ya reporta intentos y hay pruebas de concepto públicas.

Seguridad: es ejecución remota de código sin autenticación; no hay mucho que matizar.

Integridad: con los privilegios del worker web, lo que la aplicación puede leer o escribir, el atacante también.

Es necesario:

1. Actualizar a 8.2.35, 8.3.36, 8.4.27 u 8.5.12 (o posterior). Es la única corrección completa.
2. Reiniciar todos los procesos de PHP después de actualizar. Un worker viejo sigue siendo vulnerable.
3. Si están en 8.1 o anterior, no hay parche: hay que migrar a una rama con soporte y, mientras tanto, aislar ese servidor.

Les recomiendo además:

• Inventariar dónde corre PHP, incluidas las imágenes de contenedor: las imágenes oficiales de Docker ya están actualizadas, pero un contenedor viejo no se actualiza solo.
• Mientras actualizan, desactivar session.upload_progress en la configuración del servidor (no en la aplicación) y limitar el tamaño de las peticiones en el WAF o el proxy.
• Tratarlo como urgencia, fuera del ciclo normal de parches.

¿Ya revisaron sus contenedores, o solo sus servidores?

La última ronda de correcciones, publicada el 13 de agosto, cerró 28 vulnerabilidades. Dos de ellas estaban en pg_dump y psql: las herramientas con las que respaldamos y restauramos. Una permite que el superusuario del servidor de origen ejecute código en la máquina de quien restaura el dump.

Seguridad: después del 12 de noviembre, la siguiente falla de ese calibre en la versión 14 ya no tendrá corrección.

Integridad: el respaldo es la última línea de defensa. Si la herramienta de respaldo es superficie de ataque, restaurar un dump de origen desconocido deja de ser una operación neutral.

Qué deberíamos hacer:

1. Inventario real: qué instancias siguen en 14, incluidas réplicas, ambientes de pruebas y contenedores que nadie recuerda.
2. Migrar a una versión con soporte largo (17 o 18). No a la 19 RC: en producción no se estrena nada.
3. Antes de migrar, restaurar el respaldo actual en un ambiente aislado. Un respaldo que no se ha restaurado no es respaldo.
4. Restaurar dumps solo de orígenes confiables y con clientes ya parcheados.

El 21 de octubre el proyecto PHP publicó versiones de seguridad para dos vulnerabilidades críticas. CVE-2026-109618 corrompe memoria durante el manejo de falta de memoria. CVE-2026-109619 es un use-after-free por estado que persiste entre peticiones. Según Rapid7, ambas tienen CVSSv4 9.2 y permiten ejecución remota de código sin autenticación con los privilegios del worker web. AWS y Docker ya publicaron sus avisos.

Por qué importa: Rapid7 también reporta que en el Q3 el promedio entre la publicación de una vulnerabilidad de alta severidad y su explotación fue de 3 días, y que el 71% ocurrió en la primera semana. Una ventana de cambios mensual no alcanza.

Qué deberíamos hacer:

1. Inventario real: dónde corre PHP, incluidas las imágenes base de contenedores que nadie revisa.
2. Aplicar parches primero lo expuesto a internet, con respaldo y plan de reversión.
3. Revisar qué puede leer y tocar el usuario del worker. Si hay RCE, ese es el alcance del daño, y ahí el mínimo privilegio deja de ser teoría.
4. Reconstruir imágenes, no solo actualizar hosts.

El trade-off existe: parchar rápido en producción tiene riesgo. Pero no parchar también es una decisión, y hoy es la más cara.

¿Cuánto tarda tu equipo desde que sale un CVE crítico hasta que el parche está en producción?

AWS publicó el boletín 2026-143 sobre dos vulnerabilidades críticas en PHP (CVE-2026-109618 y CVE-2026-109619). Según el boletín, permiten a un actor remoto no autenticado ejecutar código, acceder a datos accesibles por el proceso o provocar denegación de servicio en workers PHP afectados. El rango señalado abarca las ramas 8.2 a 8.5. Las versiones corregidas exactas hay que tomarlas del boletín y del aviso del proyecto PHP.

Por qué importa: esto no es un problema de AWS, es de PHP. Afecta a cualquiera que ejecute esas versiones, en la nube o en su propio servidor. Ejecución remota sin autenticación es el peor escenario. Y "datos accesibles por el proceso" suele incluir credenciales de base de datos, llaves y sesiones.

Qué deberíamos hacer:

1. Inventario real: qué versión de PHP corre en cada servidor, contenedor e imagen base. La real, no la que dice la documentación.
2. Aplicar parches con respaldo y plan de reversión, empezando por lo expuesto a internet.
3. Si un servicio expuesto quedó sin parche, rotar los secretos que su worker podía leer.
4. Revisar con qué privilegios corre el worker. El mínimo privilegio limita el daño cuando el parche llega tarde.

¿Saben hoy, sin preguntarle a nadie, qué versión de PHP corre en su ambiente de producción?