Igual A Modern Approach to Preventing CSRF in Go es excesivamente técnico y sobre algo muy concreto, pero quería dejarlo guardado porque nunca se sabe qué se puede necesitar en algún momento futuro.

Have we finally reached the point where CSRF attacks can be prevented without relying on a token-based check (like double-submit cookies)? Can we build secure web applications without bringing in third-party packages like justinas/nosurf or gorilla/csrf?

And I think the answer now may be a cautious “yes” — so long as a few important conditions are met.

En “GPUGate” Malware Abuses Google Ads and GitHub to Deliver Advanced Malware Payload nos contaban cómo atacaban a usuarios poco vigilantes mediante anuncios y enlaces a GitHub.

1. Aparece un anuncio malicioso, que apunta a un enlace que aparentemente es de GitHub, con un producto que parece ‘interesante’ (GitHub Desktop)

The attack begins with malicious advertising, where attackers place a sponsored ad at the top of Google search results for terms like “GitHub Desktop.” This ad directs users to what appears to be a legitimate GitHub page.

1. El enlace lleva a un página de GitHub dentro de un repositorio, todo parece legítimo, pero allí hay enlaces de descarga alterados.

In reality, the link leads to a specific, manipulated “commit” page within a repository. This page looks authentic, retaining the repository’s name and metadata, but contains altered download links that point to an attacker-controlled domain.

1. Para evitar los filtros de contenido el tamaño del instalador es muy grande (para aprovecharse de que muchos mecanismos de seguridad que tienen limitación de tamaño).

What makes GPUGate particularly notable is its unique evasion method. The initial installer is a large 128 MB file, designed to bypass security sandboxes that often have file size limits.

1. Finalmente, y para evadir la vigilancia mejor, solo se activa en caso de que haya disponible una GPU.

Its most innovative feature is a GPU-gated decryption routine. The malware will only decrypt its malicious payload if it detects a real, physical GPU with a device name longer than ten characters, Arctic Wolf said.

En este caso se está abusando de la confianza en los anuncios de Google, y en las páginas de GitHub. Pero eso es un problema, claro.

This “trust bridge” exploits the user’s confidence in both Google and GitHub to deliver the malicious payload.

Además, se implantan algunas medidas que son habituales en las máquinas de vigilancia y de los analistas, lo que haría más difícil la detección y análisis.

Curioso.

Ya hace unos cuantos años que se ofrecían inteligencias artificiales para la ciberseguridad: lo penúltimo era la detección de comportamientos anómalos a partir de la actividad de la red, los registros de actividad, etc. Pero, en los últimos años, las IAs se han ganado por derecho propio la entrada a todos los niveles. Casi me da apuro hablar de este caso porque la entrada tiene más de un año y todo cambia demasiado rápido, pero en Hallucinations, Hidden Costs & Human-in-the-Loop Realities nos hablaban de varios problemas y limitaciones que siguen estando de plena actualidad.

Nos podrían ayudar, nos dicen, en diversos aspectos:

• La fatiga por alertas: Ante la avalancha de avisos y textos largos, la IA permite examinarlos y resumirlos en segundos (aunque el problema de fondo sigue siendo que necesitan un buen entrenamiento con datos de calidad para ser confiables).

LLM Solution: Summarises the log avalanche in seconds

• Construcción de consultas: Ayuda a redactar queries complejas sin necesidad de ser un DBA especialista en esa sintaxis específica.

Pain Point: Query Kung-fu — SPL/KQL syntax

• Estructura y borrador de informes: Prepara la plantilla base (boilerplate) y aligera la carga de redacción.

Pain Point: Playbook boilerplate

• Apoyo a los perfiles junior: Delegar en la IA la explicación de conceptos o eventos relevantes (manteniendo siempre la precaución frente a posibles alucinaciones).

Pain Point: Junior mentoring

También se señalan inconvenientes claros:

• Completado de patrones: Como sabemos, los LLM completan secuencias de texto; no «saben» hechos. Si les alimentamos con datos de seguridad ambiguos o parciales, se inventan la respuesta con total soltura.

LLMs complete patterns; they don’t know facts. Feed them ambiguous or partial security data and they happily invent:

• Costes ocultos: El precio de los tokens, el coste de conectar e integrar nuestros datos (Retrieval Engineering), la desviación de instrucciones (Prompt Drift), el optimismo del vendedor frente a los resultados reales y las zonas grises en materia de cumplimiento normativo.

Token Tax Retrieval Engineering Prompt Drift Oversell, Underdeliver Compliance Grey-zones

¿Dónde quedan los humanos? Una cosa es que realmente podamos auditar y supervisar las respuestas de nuestras IAs y otra muy diferente lo que terminemos haciendo en el día a día.

Marketing slides imply analysts are promoted to “decision-makers”. In reality: they become prompt engineers, prompt auditors and bug-report shepherds. Without clear HITL checkpoints, a hallucinating agent can spray false positives, or worse, false negatives, at machine speed.

Para no olvidarlo.

Forma parte del folclore cómo algunos empleados ‘previsores’ insertan código en las plataformas que gestionan ‘por si acaso’. En Dev gets 4 years for creating kill switch on ex-employer’s systems nos contaban uno de estos casos y cómo el empleado fue condenado a cuatro años de cárcel por hacerlo.

A software developer has been sentenced to four years in prison for sabotaging his ex-employer’s Windows network with custom malware and a kill switch that locked out employees when his account was disabled.

Por lo visto, había sido degradado en una reestructuración de la empresa y trató de vengarse preparando código malicioso.

After a corporate restructuring and subsequent demotion in 2018, the DOJ says that Lu retaliated by embedding malicious code throughout the company’s Windows production environment.

Algo tan simple como un programita en Java que lanza un bucle infinito, sobrecarga y termina dejando inutilizables los servidores.

The malicious code included an infinite Java thread loop designed to overwhelm servers and crash production systems.

No parece que sea la mejor forma de afrontar un despido o una degradación, justificados o no.

Cualquiera que venga por aquí de vez en cuando imaginará que esto es así. En AI Coding Tools Are Creating a Security Gap We Must Close Immediately (que leí a través de AI code generators are writing vulnerable software nearly half the time pero ahora parece no estar disponible) nos dicen que a los desarrolladores les gusta mucho usar los LLMs: escriben código más rápido, hacen menos trabajo repetitivo y se pueden añadir más características fácilmente.

Developers love AI coding tools. And why wouldn’t they? After all, they write code faster. They reduce repetitive work. They help junior engineers ship features that used to take days.

Pero hay un problema, esta aceleración también se produce en la generación de fallos y problemas de seguridad.

AI coding tools are producing insecure code at massive scale. And the industry is running out of time to fix it.

Si lo pensamos, esto es normal: con tanto código malo como hay por ahí disponible, seguramente al entrenar a esos LLMs no se habrá filtrado adecuadamente el código defectuoso.

El resumen que nos da es que solo el 55% del código generado en las pruebas de Veracode pasa pruebas básicas de seguridad.

Here it is, plain and simple. Across more than 150 large language models tested, only 55% of AI-generated code passes basic security tests.

Por ponerlo más claro: en casi la mitad del código generado por un LLM se introduce alguna vulnerabilidad conocida.

That means in nearly half of all cases, an AI coding tool may introduce a known security vulnerability directly into your codebase.

El contraste es interesante, porque este código es perfecto desde el punto de vista sintáctico, pasa las pruebas unitarias, se mezcla con el código anterior …

What makes this worse is the contrast. Those same AI models achieve syntax correctness rates above 95%. The code looks right. It runs. It passes unit tests. It gets merged. And it contains a security hole.

Algunos tipos de fallo son mejores que otros, por ejemplo para la inyección de SQL los modelos alcanzan un 82% de paso de las pruebas de seguridad, y en el caso del uso inseguro de criptografía es incluso mejor, el 86%. Son datos ampliamente disponibles y bien conocidos.

For SQL injection, AI models achieve an 82% security pass rate. For insecure cryptographic algorithms, it’s 86%. These are common, well-documented patterns. The models have seen them thousands of times in training data. They’ve learned to avoid the obvious anti-patterns.

Sin embargo, si nos referimos a la inyección cruzada (cross-site scripting (XSS),), la cosa baja a un 15% (¡Ay la web!) y en el caso de inyección en el registro de actividad (log injection) estamos hablando del 13%. ¿Tus programadores se preocupan de lo que se escribe en el registro de actividad?

Nos dice que la cosa no ha mejorado en estos años con los sucesivos modelos, porque son buenos con el manejo de patrones, y lo que ya han visto, pero no lo son tanto con razonamientos sutiles, dependientes del contexto y de su lógica.

These numbers have barely moved since initial research began two years ago. This isn’t a bug that’s getting patched. It’s a structural limitation. AI models are pattern-matchers. They’re excellent at reproducing what they’ve seen. They’re poor at reasoning through subtle, context-dependent security logic — exactly the kind that produces XSS and log injection vulnerabilities.

Hay alguna excepción, como OpenAI con su ChatGPT 5, con una tasa de paso de entre 70–72%, pero eso deja todavía un 30% de código con fallos.

There is one bright spot worth noting. OpenAI’s reasoning-focused models — the GPT-5 series with extended reasoning — achieved security pass rates between 70–72%. That’s a real improvement over the standard 55% baseline. It suggests that models built to think through problems, not just autocomplete them, produce safer code. But 70% still means 30% of AI-generated code contains known flaws. That’s not a solution. It’s a direction.

Naturalmente, esto conduce al éxito de los ataques, con el 81% de las organizaciones siendo víctimas de ataques exitosos.

81% of organizations experienced at least one successful cyberattack in the past year. And the number of organizations suffering six or more successful attacks is actually increasing.

Y sin olvidar que los malos también usan las herramientas, generando programas maliciosos guiados por IA.

The 2026 Cyberthreat Defense Report found that AI-enabled evasive malware is the number one AI-related threat concern, cited by 45.5% of security professionals.

Como solemos decir, el problema no es por generar código rápido, el problema está en confiar en ese código demasiado pronto. Sobre todo porque el verdadero cuello de botella es arreglar ese código cuando aparecen problemas.

The real bottleneck has always been fixing them, governing how they enter codebases, and proving to boards, regulators, and customers that the software you’re running is trustworthy.

Nos recomiendan, por lo tanto, priorizar:

1. No lo arregles todo. Arregla primero lo correcto.

1. Stop trying to fix everything. Fix the right things first.

1. Pídele seguridad a la IA, no es una sugerencia.

1. Make security prompting a standard, not a suggestion.

1. Reemplaza las pruebas manuales por pruebas automatizadas.

1. Replace manual testing with continuous, automated scanning.

1. Construye visibilidad antes que planes de reparación.

1. Build visibility before you build remediation plans.

1. Demuéstralo. Al comité, los reguladores y los clientes.

1. Prove it — to your board, your regulators, and your customers.

A pesar de que se trata de un texto de parte (venden herramientas, consultoría sobre seguridad, …) me parece un texto muy interesante y valioso.

En los últimos años venimos observando cada vez más preocupación sobre qué tenemos ejecutándose en las máquinas por ahí, sobre todo por las diversas nubes y el deseo de estar seguros de que allá sigue estando lo que nosotros habíamos puesto.

En Personal Reflections On Immutable Linux

Immutable means “not subject or susceptible to change” according to Merriam-Webster, which is not 100% accurate in this context, but it’s close enough and the name is there so we’re stuck with it. Immutable distributions are subject to change, it’s just that how you change them is quite a bit different than bog-standard Linux.

Tiene un poco que ver, creo, también con la reproducibilidad y tener la tranquilidad de que nuestro entorno de ejecución será parecido al de pruebas.

Nos habla de algunos ejemplos, como MicroOS, OSTree, Silverblue Aurora…

Pero esa inmutabilidad no significa que no podamos instalar nuevos programas y la solución habitual es mediante contenedores (Flatpak, por ejemplo). A partir de ahí muestra cómo MacOS es un Unix inmutable, a través de su aislamiento de las carpetas del sistema en modo de solo lectura. Las actualizaciones vienen como snapshots que sustituyen esa parte del sistema completa.

And Cupertino has been moving towards this “immutable” thing for a long time, until Catalina finally sealed the system folders away completely on a read-only volume. Updates for MacOS also come as snapshots to replace that system volume– you could certainly call them “atomic”.

La pregunta que surge es si esto es aceptable para el escritorio y la respuesta es que, probablemente, para la mayoría sí. Lo demuestra macOS y sus usuarios satisfechos.

macOS has shown that very few desktop users will ever notice if they can access the system folders or not; they are most interested in having a stable, reproducible environment to work in.

Naturalmente, estas aproximaciones vienen con sus propios inconvenientes: el uso de contenedores supone mayor uso de recursos (memoria y disco, fundamentalmente).

There are downsides to this kind of system, of course, and it is important to recognize that. Some people really, really hate containerization because Flatpaks, and other similar options, use more memory, both on disk and in RAM.

También nos quita algunas cosas a las que estamos acostumbrados en los sistemas de tipo Linux como el control sobre lo que hay en nuestra máquina, o cambiando la perspectiva, la idea de ‘no tocar’, derivada de la inmutabilidad.

From an aesthetic perspective, it’s not as elegant as a traditional Linux environment, at least to some eyes, mine included. Those of us who switched to Linux because we wanted absolute control over our computers might not feel too great about the “do not touch” label implicitly scrawled across the system folders

Finalmente, nos habla de una solución que no es exactamente inmutable, pero que nos permite abordar el problema del control sobre lo que hay en nuestro sistema, como es Nix, ofreciéndonos muchas de las ventajas de la inmutabilidad pero sin renunciar a configurar nuestro sistema.

After seeing how well containerization can work on desktop, Nix looks extra appealing – it can do most of what this article talks about with the immutable distros, but without trusting configuration of any facet of the system to anyone else.

Cualquiera que haya jugado un rato con una IA sabe que pueden convertirse en algo adictivo: nos aligera las tareas repetitivas, nos ayuda a resolver algunos problemas técnicos sin necesidad de leerse unos cuantos foros para ver cuál es la buena…. casi siempre.

En Large Language Models (LLMs) Are Falling for Phishing Scams: What Happens When AI Gives You the Wrong URL? nos recordaban que las recomendaciones no siempre son correctas y para comprobarlo hicieron un experimento.

Preguntaban dónde conectarse a algunas plataformas conocidas y las respuestas eran erróneas; no solo eso, ni siquiera estaban conectadas con el sitio al que pretendíamos ir en un 34% de las ocaciones.

When Netcraft researchers asked a large language model where to log into various well-known platforms, the results were surprisingly dangerous. Of 131 hostnames provided in response to natural language queries for 50 brands, 34% of them were not controlled by the brands at all.

Esto era un problema relativo, porque en la mayoría de los casos (29%) eran dominios aparcados, no registrados o sin actividad y en un 5% de los casos eran negocios legítimos, pero incorrectos.

64 domains (66%) belonged to the correct brand. 28 domains (29%) were unregistered, parked, or had no active content. 5 domains (5%) belonged to unrelated but legitimate businesses.

Pero cualquiera que tenga interés por las cosas de las que solemos hablar aquí sabe cuál es el siguiente paso: alguien descubre estas direcciones, las registra, y solo le queda esperar a recolectar los frutos.

Worse, many of the unregistered domains could easily be claimed and weaponized by attackers. This opens the door to large-scale phishing campaigns that are indirectly endorsed by user-trusted AI tools.

¿A quién afecta esto? Fundamentalmente, los damnificados podrían ser los negocios y empresas más pequeñas (que, además, últimamente son los que tienen la web completamente abandonada echándose en los brazos de las redes sociales).

Sitios más pequeños tienen una menos probabilidad de estar incluidos en los conjuntos de datos de entrenamiento y, por lo tanto, son los que invitan a los LLMs a alucinar, inventándose algo que decir cuando no lo tienen en su información.

These smaller players are less likely to appear in LLM training data, meaning hallucinations are more likely.

Podría suceder lo mismo con asistentes de programación, si alguien consigue contaminar sus datos con APIs falsas, que el asistente incluirá en nuestro código sin demasiados problemas.

In another campaign, Netcraft uncovered a sophisticated effort to poison AI coding assistants. The threat actor created a fake API, SolanaApis, designed to impersonate a legitimate Solana blockchain interface. Developers who unknowingly included this API in their projects were, in reality, routing transactions directly to the attacker’s wallet. The malicious API was hosted on two hostnames: api.solanaapis[.]com and api.primeapis[.]com

Interesante.

No estoy muy seguro sobre en qué habrá terminado esto pero me parece interesante por varios motivos: Ubuntu disables Intel GPU security mitigations, promises 20% performance boost.

Por un lado, está claro que añadir controles de seguridad hace que el código sea más lento (en este caso parece que mucho), y más complejo (se añaden instrucciones para vigilar que no pasen cosas y estar seguros de que sucden las adecuadas).

En este caso, además, los controles de seguridad vienen de un fallo de diseño por la ejecución predictiva (Recordar “Meltdown” and “Spectre:” Every modern processor has unfixable security flaws).

Según Ubuntu, este sería un problema suficientemente bien manejado en el kernel y, por lo tanto, los controles que añadían serían innecesarios.

At this point, Spectre has been mitigated in the kernel, and a clear warning from the Compute Runtime build serves as a notification for those running modified kernels without those patches. For these reasons, we feel that Spectre mitigations in Compute Runtime no longer offer enough security impact to justify the current performance tradeoff.

La ganancia no es pequeña, como dice el titular: un 20% de mejora.

Más aún, parece que estos fallos no están siendo atacados porque el esfuerzo no compensa (aunque ya sabemos que todo depende del sistema y el nivel de la información que protege).

“Nobody bothers attacking these vulns because it takes a lot of engineering time to implement attacks against them to any useful level of rigor, and getting any interesting data back outside very targeted scenarios is very unlikely (plus it’s noisy due to the number of iterations you need to do on these types of side-channels),” independent researcher Graham Sutherland wrote on Mastodon. “The economics just don’t stack up for attackers, especially when there are so many lower-effort higher-reward attack approaches they can throw at stuff.”

Interesante.

En LastPass Dodges Deepfake Scam: CEO Impersonation Attempt Thwarted nos cuentan un caso de intento de engaño mediante deep-fakes para engañar a las personas adecuadas, haciéndose pasar por alguna persona de confianza.

En este caso se trataba de la empresa LastPass y un intento de engaño con mensajes de audio para hacerse pasar por el CEO de la empresa.

The incident, detailed in a blog post by LastPass, involved an audio deepfake impersonating CEO Karim Toubba attempting to contact the employee via WhatsApp.

Las señales de que algo no van bien están muchas veces claras; un ejemplo es el uso de sistemas de comunicación alternativos (o no habituales).

As for LastPass, the company commended the employee’s vigilance in recognizing the red flags of the situation. The unusual use of WhatsApp, a platform not commonly used for official communication within the company…

Tampoco es que esto sea lo más habitual (hacerlo bien tiene requisitos importantes) pero es, nos avisan, que es una amenaza creciente.

While deepfake scams targeting businesses are still relatively uncommon, the LastPass incident stresses the growing threat. The company’s decision to publicize the attempt serves as a valuable cautionary tale for other organizations, urging them to heighten awareness and implement preventative measures.

El panorama ha cambiado un poco en los últimos tiempos, y en Triaging security issues reported by third parties la queja era que recibían muchos avisos de seguridad, perdiendo mucho tiempo en verificarlos, aunque no siempre son tan importantes.

I have to spend several hours each week dealing with security issues reported by third parties. Most of these issues aren’t critical but it’s still a lot of work.

Tiene algo que ver con la irrupción de la IA (más facilidad para hacer análisis y encontrar fallos), pero también con que el software libre no termina de encontrar el camino para financiar a sus desarrolladores y ese trabajo termina siendo, muchas veces, pura voluntariosidad.

In the long run, putting such demands on OSS maintainers without compensating them is detrimental. I just stepped down as libxslt maintainer and it’s unlikely that this project will ever be maintained again. It’s even more unlikely with Google Project Zero, the best white-hat security researchers money can buy, breathing down the necks of volunteers.