Otro ataque más a la cadena de suministro, hackean Axios en npm para distribuir malware
Otro ataque más a la cadena de suministro
La popular librería de JavaScript Axios, utilizada por millones de desarrolladores para enviar solicitudes HTTP entre aplicaciones y servicios web, fue comprometida en uno de los ataques a la cadena de suministro más graves registrados en el ecosistema npm.
Con cerca de 100 millones de descargas semanales, el incidente encendió alarmas en toda la industria del software.
Cómo ocurrió el ataque
El ataque no explotó una vulnerabilidad del código de Axios. En cambio, los atacantes lograron secuestrar la cuenta de la persona responsable por mantener el proyecto y cambiar su correo por una bandeja anónima de ProtonMail.
Desde ahí, los intrusos evitaron los controles automáticos del pipeline de GitHub Actions y publicaron manualmente versiones maliciosas en el registro de npm usando la línea de comando (CLI).
En tan solo 39 minutos, se publicaron dos versiones comprometidas:
axios@1.14.1 (00:21 UTC)
axios@0.30.4 (01:00 UTC)
Cualquier desarrollador que instaló estas versiones descargó malware sin saberlo.
El caballo de Troya: un paquete falso llamado plain-crypto-js
El ataque fue planeado minuciosamente. Los atacantes publicaron primero un paquete falso llamado plain-crypto-js para crear historial y credibilidad.
18 horas después, lo actualizaron con código malicioso y lo añadieron como dependencia dentro de la versión comprometida de Axios.
Su función real era actuar como puerta de entrada para un Remote Access Trojan (RAT).
Tras la instalación, un script automático descargaba una segunda carga maliciosa adaptada al sistema operativo:
macOS: disfrazado como daemon del sistema
Windows: ejecución vía PowerShell
Linux: puerta trasera en Python
Después de infectar el sistema, el malware eliminaba sus rastros para dificultar el análisis forense.
Un ataque altamente sofisticado
La firma de seguridad StepSecurity analizó el incidente y lo calificó como uno de los ataques más sofisticados contra npm.
Según Ashish Kurmi, CTO y cofundador de la empresa:
“No fue oportunista. Se prepararon tres cargas para distintos sistemas, se atacaron dos ramas en menos de una hora y todo fue diseñado para autodestruirse”.
Este tipo de campañas confirma una tendencia preocupante: los atacantes están enfocándose directamente en la cadena de suministro del software.
Riesgo crítico para desarrolladores y empresas
Aunque npm eliminó rápidamente las versiones maliciosas, el daño potencial es enorme:
Equipos de desarrollo infectados
Pipelines CI/CD comprometidos
Posible filtración de credenciales y tokens
Riesgo de infiltración en entornos de producción
Los expertos advierten que si instalaste esas versiones de Axios, debes asumir que tu sistema está comprometido.
Qué hacer si tu proyecto fue afectado
Las recomendaciones de seguridad son:
1) Revertir versiones
Volver a una versión segura de Axios
Verificar la eliminación de la dependencia maliciosa
2) Auditar pipelines
Revisar logs de CI/CD y despliegues recientes
3) Rotar credenciales
Cambiar contraseñas, API keys y tokens
4) Reconstruir entornos
Reinstalar máquinas y pipelines desde cero si es necesario
Debido a la enorme presencia de Axios en el ecosistema global, las consecuencias de este ataque pueden perdurar.
Pretext: la librería de 15KB que podría resolver un problema de rendimiento web viejo de 30 años
Un viejo problema
Durante décadas, medir y posicionar texto en la web ha sido una trampa silenciosa de rendimiento. Cada vez que el navegador calcula el tamaño de un párrafo o dónde cortar una línea, ejecuta una de las tareas más costosas del rendering, a saber el reflow de layout.
Ahora, el ingeniero Cheng Lou, creador de React Motion y senior engineer en Midjourney, presentó una solución radical, Pretext, una librería TypeScript de solo 15KB que mide texto multilinea hasta 600 veces más rápido que los métodos tradicionales.
El costo oculto del texto en la web
Renderizar texto parece simple, pero no lo es.
Los navegadores deben manejar:
Emojis y modificadores de tono de piel
Ligaduras tipográficas
Sistemas de escritura sin espacios como el japonés o el chino
Idiomas RTL (right-to left) como el árabe o el hebreo que se escriben de derecha a izquierda
Para medir el tamaño del texto, los desarrolladores normalmente insertan elementos invisibles en el DOM y consultan sus dimensiones. Esto provoca un reflow sincrónico, que según el equipo de Chrome DevTools puede bloquear el hilo principal entre 10 y 100 ms en móviles.
Multiplica eso por cientos de bloques de texto y obtienes:
UI lenta
“Web jank”
Peor CLS (Cumulative Layout Shift)
Penalizaciones SEO
El cambio de paradigma de Pretext
Pretext rompe con el enfoque tradicional ya que no usa el DOM ni CSS para medir texto.
Su método funciona en dos pasos:
1) Medición sin reflow
Utiliza canvas.measureText() para acceder al motor tipográfico del navegador sin activar layout.
2) Cálculo matemático puro
Con el ancho del contenedor, calcula:
Saltos de línea
Justificación
Altura total
Resultado:
Método tradicional: 500 bloques → 15–30 ms + 500 reflows
Pretext: 500 bloques → 0.05 ms y 0 reflows
No es solo optimización, es una nueva forma de pensar el layout.
Nuevas posibilidades para interfaces y animación
Separar el layout del DOM desbloquea varios casos de uso antes imposibles.
Solución al problema histórico del SVG
Desde su lanzamiento en 2003, SVG nunca ha ofrecido una solución adecuada al wrapping automático de texto. Con Pretext + herramientas tipográficas, ahora es posible generar texto SVG que se ajusta automaticamente.
Pretext llena un vacío enorme en el desarrollo web moderno. Disponible como código abierto en npm, ofrece a los desarrolladores un control total y ultrarrápido sobre el elemento más básico de la web que es el texto.
Si se adopta masivamente, podría cambiar cómo se construyen interfaces en internet durante la próxima década.
Sin embargo, lo más importante podría terminar siendo que esta librería al fin hiciera que la W3C se fijara en este problema fundamental y definiera un nuevo estándar para resolver este problema de programación tan común que afecta a tantos desarrolladores de front-end.
Oracle anunció Java 26 con Project Detroit para acelerar la interoperabilidad entre Java, JavaScript y Python
Java 26 incluye Project Detroit para acelerar la interoperabilidad entre Java, JavaScript y Python
En el marco de JavaOne, Oracle ha anunciado oficialmente Java 26 y lo más interesante de esta nueva versión es Project Detroit, una nueva iniciativa que busca mejorar de forma significativa la interoperabilidad entre Java, JavaScript y Python.
Está claro que Java perdió el tren de la IA. Los desarrolladores apostaron principalmente por Python y en menor medida por JavaScript para crear aplicaciones con IA. Si bien no hay nada que impide que una aplicación Java explote APIs de IA como los de OpenAI o Google, Java tiene muchos menos frameworks de desarrollo para integrar Java a sus aplicaciones y eso es un problema para la plataforma.
Por eso, el objetivo de Java 26 es permitir a los desarrolladores utilizar código escrito en esos lenguajes y que usan esos frameworks de los que carece Java para crear nuevas aplicaciones de forma más rápida, eficiente y segura. Uno podría preguntarse porqué los desarrolladores no abandonan simplemente Java y adoptan Python o JavaScript. La respuesta es sencilla, Java sigue siendo un lenguaje de programación mucho más serio que ambas alternativas y mejor diseñado para aplicaciones empresariales.
Un nuevo enfoque: runtimes nativos dentro de la JVM
A diferencia de soluciones anteriores, Project Detroit apuesta por integrar directamente los runtimes más utilizados dentro de la máquina virtual de Java:
V8 (motor de JavaScript)
CPython
Esto elimina la necesidad de reimplementaciones, como ocurrió con proyectos anteriores como Nashorn, que intentaban recrear JavaScript dentro de Java.
El resultado:
Mejor compatibilidad con ecosistemas reales
Menos problemas en casos límite
Mayor rendimiento
El papel clave del FFM API
Uno de los pilares técnicos de esta mejora es el Foreign Function and Memory API, introducido en Java 22.
Este API reemplaza al antiguo Java Native Interface (JNI) con un enfoque más moderno y sencillo, permitiendo crear capas muy ligeras para:
Llamar código JavaScript desde Java
Invocar Java desde otros lenguajes
Rendimiento y seguridad mejorados
Según Oracle, el nuevo enfoque ofrece ventajas claras:
Mayor velocidad en la ejecución entre lenguajes
Aislamiento de memoria entre heaps (Java, V8, CPython)
Modelo de seguridad más robusto
Esto es especialmente relevante en aplicaciones modernas que necesiten combinar código Java con componentes en Python o JavaScript, principalmente para usar la IA.
Java 26: una versión de transición
Java 26 es una versión de Java que tendrá un tiempo de vida corto ya que será reemplazada dentro de seis meses por Java 27.
Entre las novedades de Java 26:
Mejoras incrementales en concurrencia estructurada
Avances en el Vector API
Soporte para HTTP/3
También marca el fin de una era con la eliminación definitiva de los applets de Java, ya obsoletos.
Más novedades dentro del ecosistema Java
Oracle también anunció otros movimientos estratégicos:
Project Helidon se integrará en OpenJDK
Lanzamiento del Java Verified Portfolio (JVP), un conjunto validado de herramientas empresariales
Soporte renovado para JavaFX
Integración de Java en notebooks de Visual Studio Code
Además, la compañía está reforzando su apuesta por la IA con proyectos como:
Helidon AI
LangChain4j (fuertemente apoyado por IBM)
Spring AI
Java se adapta (tarde) a la era de la IA
Project Detroit refleja una tendencia clara, ya ningún lenguaje vive en aislamiento. Las aplicaciones modernas combinan múltiples tecnologías, especialmente ante el auge de la inteligencia artificial.
Al integrar directamente los runtimes más populares, Oracle busca posicionar Java como un actor central en este nuevo paradigma, facilitando la colaboración entre ecosistemas sin sacrificar rendimiento ni compatibilidad.
En definitiva, más que competir con otros lenguajes, Java apuesta por convivir con ellos de forma nativa y eficiente.
Dos décadas de Amazon S3, el motor invisible de Internet creado por AWS
De un lanzamiento discreto al motor invisible de Internet
Hace 20 años, el 14 de marzo de 2006, Amazon Web Services lanzó silenciosamente un servicio que cambiaría para siempre la industria tecnológica: Amazon S3. Sin demos, sin ejemplos de código y con apenas un breve anuncio, el servicio ofrecía algo aparentemente simple: almacenar datos (PUT) y recuperarlos (GET) utilizando un API REST.
Lo que parecía una herramienta básica acabaría convirtiéndose en uno de los pilares fundamentales de Internet moderno.
De un petabyte a cientos de exabytes
En sus inicios, S3 contaba con:
~1 petabyte de capacidad total
400 nodos de almacenamiento
Objetos de hasta 5 GB
Un coste de $0.15 por GB
Actualmente, la escala es difícil de imaginar:
Más de 500 billones de objetos almacenados
Más de 200 millones de solicitudes por segundo
Cientos de exabytes de datos distribuidos en 39 regiones
Un tamaño máximo por objeto de 50 TB
El coste también se ha desplomado a poco más de $0.02 por GB, una reducción del 85%, propiciada por el crecimiento de la capacidad de los discos duros y la reducción del costo por GB. Además, herramientas como S3 Intelligent-Tiering han permitido ahorrar miles de millones a los clientes.
El impacto cultural: el “backend” del mundo digital
S3 no solo creció en tamaño, sino en influencia. Se convirtió en la infraestructura invisible detrás de servicios globales como:
Netflix
Spotify
Gracias a su escalabilidad prácticamente ilimitada, permitió que estas plataformas redefinieran cómo consumimos contenido.
Además, su API se transformó en un estándar de facto. Hoy en día, no hay proveedor de nube que no ofrezca soluciones 100% compatibles con S3, replicando su modelo y convenciones, generalmente a menor costo.
Desafíos y evolución técnica
Operar a esta escala no ha estado exento de problemas. Uno de los incidentes más recordados fue la caída de 2017 en la región US-EAST-1, que afectó a buena parte de Internet.
También hubo retos de seguridad: en sus primeros años, configuraciones abiertas por defecto provocaron filtraciones de datos hasta que AWS endureció sus políticas.
Para garantizar fiabilidad, S3 está diseñado con 11 nueves de durabilidad (99.999999999%), lo que logra gracias a:
Sistemas automáticos de verificación y reparación
Arquitectura de microservicios
Uso de métodos formales para validar código
En los últimos años, AWS ha reescrito partes críticas del sistema en Rust, mejorando rendimiento y eliminando potenciales errores relacionados con el uso de la memoria.
Y quizás lo más impresionante es que el código escrito en 2006 que usaba S3, sigue funcionando hoy sin cambios, manteniendo una compatibilidad total.
La base de la era de la IA
El futuro de S3 va mucho más allá del almacenamiento tradicional. AWS quiere convertirlo en la base universal para datos e inteligencia artificial.
Entre las nuevas capacidades destacan:
Tablas gestionadas con Apache Iceberg (S3 Tables)
Gestión centralizada de metadatos
Almacenamiento nativo de vectores (S3 Vectors)
Este último es clave para casos como búsqueda semántica y sistemas de IA con RAG (Retrieval-Augmented Generation). Solo en unos meses de 2025, se crearon más de 250,000 índices y se almacenaron más de 40,000 millones de vectores.
Un estándar que define la industria
La visión es de AWS es clara. El objetivo es almacenar cualquier tipo de dato una sola vez y procesarlo directamente en S3, eliminando la necesidad de mover información entre sistemas.
Esto no solo simplifica la arquitectura técnica, sino que también refuerza el papel de AWS como eje central del ecosistema de datos.
De herramienta simple a infraestructura global
En dos décadas, S3 ha pasado de ser una utilidad básica a convertirse en la columna vertebral del mundo digital.
Su éxito demuestra una idea poderosa: cuando la infraestructura funciona de forma invisible y fiable, los desarrolladores pueden centrarse en innovar. Y eso, en última instancia, es lo que ha permitido construir gran parte de Internet tal y como lo conocemos hoy.
IA y código abierto. Los conflictos que vienen. Chardet solo es el primer caso.
Vivimos en una era distinta. Todo está cambiando.
El auge de la inteligencia artificial generativa está transformando rápidamente la industria tecnológica, pero una nueva controversia ha puesto de relieve uno de sus efectos más complejos: la reescritura de software mediante el uso de la IA.
Modelos de lenguaje avanzados y agentes de programación son capaces de recrear grandes bases de código en cuestión de horas o días. Esto está permitiendo que desarrolladores reescriban proyectos existentes y los publiquen bajo licencias diferentes, lo que pone a prueba conceptos fundamentales del mundo del software como el copyright, las licencias y el movimiento copyleft.
El caso más reciente surgió en la comunidad de Python con el popular proyecto chardet.
La controversia de chardet
La librería Python chardet fue creada para detectar el tipo de codificación utilizado para una cadena de caracteres o una página web. Fue creada en 2006 por Mark Pilgrim y se ha convertido en una herramienta extremadamente popular con unos 130 millones de descargas mensuales.
El proyecto fue publicado bajo la licencia LGPL, una licencia copyleft que exige que las versiones derivadas mantengan las mismas condiciones de distribución.
En 2012, Mark Pilgrim dejó el proyecto y el mantenimiento del mismo pasó a manos de Dan Blanchard quien estuvo actualizándolo hasta ahora.
Distribuida bajo la licencia MIT, mucho más permisiva
Para crear esta nueva versión, Mark utilizó Claude de Anthropic, completando el trabajo en tan solo cinco días.
El cambio de licencia tenía un objetivo claro: facilitar que la biblioteca pudiera integrarse en la biblioteca estándar de Python.
El creador original se opone
Poco después del lanzamiento, Mark Pilgrim reapareció en GitHub para protestar.
Según él, los mantenedores no tienen derecho a cambiar la licencia del proyecto.
Pilgrim argumentó que incluso si fuera cierto que el código fue reescrito, los desarrolladores habían estado expuestos durante años al código original, lo que podría convertir la nueva versión en una obra derivada bajo los términos de la LGPL.
También cuestionó el argumento de que usar IA cambiara la situación legal:
“Añadir un generador de código sofisticado no concede ningún derecho adicional”.
El debate del “clean room”
El conflicto gira en torno al concepto de implementación “clean room”.
Históricamente, este método se utilizó para recrear software sin violar derechos de autor. El caso más famoso ocurrió en 1982 cuando Compaq clonó el BIOS de IBM.
El proceso requería dos equipos separados:
El primero analizaba el producto original y escribía una especificación
El otro creaba un nuevo código basándose únicamente en esa especificación
Este proceso podía tardar meses.
Actualmente, un modelo de IA puede realizar ese proceso en cuestión de horas.
Blanchard reconoce que su método no fue un clean room tradicional, ya que conoce el proyecto desde hace más de una década. Sin embargo, sostiene que lo importante es que el resultado final sea estructuralmente independiente.
Para demostrarlo utilizó JPlag, una herramienta de detección de plagio de código. Según sus pruebas, la similitud máxima entre el nuevo código y versiones anteriores es inferior al 1.3 %.
El problema de fondo: el entrenamiento de la IA
El uso de IA introduce una complicación completamente nueva.
Incluso si el desarrollador comenzó con un repositorio vacío, el modelo Claude probablemente fue entrenado con código público, incluyendo potencialmente el código original de chardet.
Esto plantea una pregunta jurídica inédita:
¿Puede una IA entrenada con código copyleft generar legalmente una versión no derivada de ese mismo software?
La respuesta todavía no está clara.
Un posible terremoto para la industria
Muchos expertos creen que el caso chardet es solo el primer indicio de un problema mucho mayor.
En listas de correo del desarrollo del kernel de Linux ya se debate la posibilidad de que agentes de IA reescriban grandes partes del sistema operativo bajo licencias distintas.
“No hay nada ‘limpio’ en un modelo de lenguaje que ha ingerido el código que se le pide reimplementar”.
La incertidumbre legal
La situación legal tampoco está definida.
El año pasado, la Corte Suprema de los EEUU rechazó revisar el caso Thaler v. Perlmutter, confirmando que el contenido generado exclusivamente por IA no puede tener copyright.
Esto deja abiertas preguntas importantes:
¿Cuánta participación humana se necesita para reclamar derechos de autor?
¿Quién es responsable legalmente de una reescritura generada por IA?
Ahora bien, el que no se pueda proteger código escrito por la IA no significa que la nueva versión de chardet sea una copia de la versión original.
¿El fin del modelo económico del software?
Algunos pioneros del software libre creen que estamos ante un punto de inflexión.
Armin Ronacher, creador del framework Flask, señala que las licencias copyleft siempre han dependido de la “dificultad”de reescribir código.
Según Perens, esta tecnología podría transformar completamente la economía del software:
“Estoy rompiendo el vidrio y activando la alarma de incendios. La economía del desarrollo de software está acabada”.
Incluso demostró el problema recreando con IA una plataforma completa de System Reliability Engineering (SRE) en cuestión de días y bajo otra licencia.
Hay que decir que esto no es nada nuevo y es algo que ya vemos que está beneficiando a sistemas operativos minoritarios como Linux y macOS ya que se ha vuelto muy sencillo portar aplicaciones de Windows a esos sistemas operativos.
Un punto de inflexión tecnológico
La capacidad de la IA para reescribir software plantea un dilema profundo tanto para empresas propietarias como para el movimiento de código abierto.
Si cualquier base de código puede ser recreada rápidamente mediante el uso de la IA, los límites tradicionales entre software original, derivado y reimplementado podrían desaparecer.
Como señaló Perens, quizá estamos viviendo un momento comparable a la invención de la imprenta:
el conocimiento ha alcanzado una masa crítica, y las reglas que lo rodean están a punto de cambiar para siempre.
