Ocho fallos de control de acceso, divulgados en un día

En una sola jornada de noviembre de 2026 reporté, por el canal oficial de cada proyecto, ocho vulnerabilidades de control de acceso en software de código abierto. Cuatro recibieron identificador GHSA de GitHub —una de severidad crítica—; las otras cuatro se enviaron al mantenedor por correo cifrado. Ninguna se hizo pública antes de tiempo: los detalles técnicos y los nombres se reservan hasta que haya corrección, que es lo que exige la divulgación responsable.

Este texto no lista objetivos ni exploits. Explica el método, porque eso es lo que se puede medir.

El método: razonar el código, no escanearlo

Un escáner empareja patrones conocidos y, contra software bien mantenido, sale seco. El control de acceso roto no es un patrón: es una ausencia —un where que falta, una comprobación que vive una capa más allá, dos funciones que sus autores nunca vieron juntas—. Una ausencia no tiene nada que emparejar.

El procedimiento fue el mismo en los ocho:

1. Modelar el sistema: dónde entra el dato no confiable, cuáles son las fronteras de identidad/tenencia/privilegio, qué delega cada componente en otro.
2. Derivar la invariante —lo que el sistema promete que siempre es verdad— en una frase: «un usuario solo lee recursos de su propia organización».
3. Refutar cada hipótesis: construir el caso de por qué NO es explotable (el guard del middleware, el filtro por tenant_id, el scope global del modelo) y buscarlo en la fuente. Si aparece, es seco; y decirlo es una determinación buena, no un fracaso.
4. Confirmar por ejecución, nunca por lectura: levantar el proyecto en un laboratorio local y reproducir el fallo por la vía real, con un control positivo que demuestre que la prueba discrimina.

Lo que de verdad separa una señal del ruido

La parte más honesta del trabajo fue tirar a la basura los falsos positivos. Un asistente que localiza candidatos no es quien decide: en varios casos el candidato caía al leer la fuente —existía el filtro, o el propio test del mantenedor declaraba intencional el comportamiento—. En uno, verificar el artefacto redujo una lista de «cinco endpoints vulnerables» a exactamente uno; en otro, el test del propio proyecto demostró que la supuesta segunda vulnerabilidad era un diseño deliberado. Sin esa refutación habría enviado ruido, que es la forma rápida de quemar la credibilidad.

La severidad se reportó sin inflar: cuando la explotación exigía un identificador no adivinable, se dijo; cuando el dato en juego era un salario o un registro clínico, también.

Qué demuestra

No es una lista de herramientas: es profundidad medida. Ocho invariantes rotas, encontradas razonando sobre el código y confirmadas por ejecución; cuatro con número de aviso público; una crítica sobre datos de salud. El mismo criterio que aplico a un producto propio —cripto post-cuántica, historias clínicas bajo Ley 1581— es el que aplico al auditar el ajeno: la verificación cruza la frontera del programa, o no cuenta.