# Hallazgo urgente: las correcciones de seguridad no están en producción **Fecha:** 9 de septiembre de 2026 **Origen:** extracción completa de ambos entornos mediante la API de gestión de Supabase y copia íntegra del repositorio y sus registros de despliegue en GitHub, con credenciales de la propietaria de la cuenta. **Naturaleza:** verificado mediante consulta directa a las bases de datos de producción y validación. --- ## 1. Qué se ha comprobado El informe de verificación de agosto concluyó que los ocho problemas de seguridad detectados en la auditoría estaban corregidos. Esa conclusión se apoyaba en la lectura del código del repositorio. La extracción realizada hoy permite comprobar, por primera vez, qué se está ejecutando realmente en cada entorno. El resultado es que **las correcciones existen en el repositorio y están aplicadas en validación, pero no han llegado a producción**. | Entorno | Última migración aplicada | |---|---| | Validación | `20260624000000` | | **Producción** | **`20260620000000`** | A producción le faltan cuatro migraciones, entre ellas la reescritura completa de la capa de permisos del 23 de agosto, que era la corrección principal. --- ## 2. Qué sigue abierto en producción Comprobado consultando directamente la base de datos de producción. | Vulnerabilidad de la auditoría | Validación | Producción | |---|---|---| | Auto-aprobación de evidencias por el propietario | Corregida | **Corregida** | | Registro de auditoría falsificable | Corregida | **Corregida** | | Alta de usuario en empresa ajena | Corregida | **ABIERTA** | | Administrador de marca sin acotar por marca | Corregida | **ABIERTA** | | Tenant derivado de datos que controla el usuario | Corregida | **ABIERTA** | | Permisos de escritura del rol autenticado | Revocados | **ABIERTOS** | Detalle de cada uno de los cuatro que permanecen abiertos: **Alta de usuario en empresa ajena.** La función que valida el alta contra una invitación real, una lista blanca o un portal público no existe en producción. El registro sigue aceptando el identificador de empresa que envíe quien se da de alta, tal como se describió en la auditoría de agosto. **Administrador de marca sin acotar.** Ninguna de las políticas de producción emplea la comprobación por marca. En validación la usan treinta y cuatro. En producción sigue vigente la construcción anterior, que la auditoría describió como trivialmente satisfacible. **Tenant derivado de datos del usuario.** La función que resuelve la empresa activa continúa leyendo los metadatos que el propio usuario puede escribir. Se verificó consultando su definición en producción. **Permisos de escritura sin revocar.** El rol autenticado conserva noventa y dos permisos de inserción, actualización y borrado sobre el esquema público. En validación son cero. --- ## 3. Por qué la combinación agrava el problema Los dos últimos puntos se refuerzan entre sí. Mientras el rol autenticado conserva permisos de escritura, las políticas de seguridad son la única defensa. Y las políticas vigentes en producción son las anteriores a la corrección, aquellas que la auditoría identificó como insuficientes: las de inscripción y ejecución comprueban únicamente que la empresa coincida con la que declara la sesión, sin verificar pertenencia real. Como la empresa declarada se lee de un campo que el usuario puede modificar, y los permisos de escritura están concedidos, la secuencia descrita en la auditoría de agosto es ejecutable hoy contra producción. En validación no lo es, porque allí los permisos están revocados y las políticas reescritas. --- ## 4. Un efecto colateral El panel de operaciones construido en agosto depende de cuentas con rol global, que crea una de las migraciones ausentes. En producción esas cuentas no existen. Conviene comprobar si el panel es operativo en producción o si el equipo continúa trabajando con el mecanismo anterior, aquel en el que el personal actuaba como administrador de cada cliente. --- ## 5. Por qué no llegó a producción La copia íntegra de GitHub realizada hoy permite responder a esta pregunta con datos, y la respuesta descarta la hipótesis más temida. **El proceso automático de despliegue funciona.** Las doce ejecuciones registradas sobre la rama `production` terminaron todas con éxito. No hay ningún fallo técnico, ninguna ejecución interrumpida, ningún error silenciado. Lo que muestran los registros es otra cosa: | | | |---|---| | Último despliegue a producción | 18 de agosto de 2026 | | Último despliegue a validación | 21 de agosto de 2026 | | Commits presentes en `main` y ausentes en `production` | 26 | El 18 de agosto se promovió a producción la entrega titulada *release remediación seguridad P0/P1*, que aplicó la primera migración de endurecimiento. Es la que explica las dos vulnerabilidades que sí aparecen corregidas en la tabla del apartado 2. Entre el 19 y el 21 de agosto se integró en `main` el resto del trabajo: la reescritura completa de la capa de permisos, la revocación de privilegios del rol autenticado y el panel de operaciones. Esa segunda tanda se quedó en `main`. **No es un fallo de la automatización. Es un paso de promoción entre ramas que nunca llegó a ejecutarse.** La rama `production` no se ha movido desde el 18 de agosto, de modo que el despliegue automático no tenía nada nuevo que desplegar. Y como cada ejecución terminaba en verde, ningún aviso lo delató durante tres semanas. Conviene retener esta distinción: un proceso que no se dispara no genera errores. La ausencia de alertas se interpretó como normalidad cuando significaba lo contrario. --- ## 6. Qué hacer **De forma inmediata.** Aplicar a producción las cuatro migraciones pendientes. Están escritas, probadas y funcionando en validación desde hace tres semanas. No es un desarrollo, es un despliegue. **Antes de aplicarlas.** La causa ya está identificada, según se detalla en el apartado anterior: falta fusionar `main` en `production`. Esa fusión dispara el despliegue por sí sola. Conviene revisar antes las cuatro migraciones pendientes, porque alteran permisos sobre datos que están en uso, y confirmar que el orden de aplicación es el correcto. **Después.** Repetir esta comprobación. La consulta que la detecta es sencilla y debería formar parte de la rutina de despliegue: contrastar la última migración aplicada en cada entorno contra la última presente en el repositorio. **Sobre la causa de fondo.** Que una rama de producción pueda quedarse tres semanas atrás sin que nadie lo advierta es un problema de proceso, no de código. Merece una comprobación automática que compare ambas ramas y avise cuando la distancia supere un umbral razonable. --- ## 7. Sobre el informe de verificación de agosto Sus conclusiones sobre el código eran correctas y no requieren rectificación. Las correcciones están bien hechas y las vulnerabilidades que introdujeron siguen siendo válidas. Lo que aquel informe no podía comprobar, por no disponer entonces de acceso a las bases de datos, es si el código verificado estaba efectivamente desplegado. Hoy sabemos que en producción no lo está. Es la diferencia entre revisar un plano y visitar el edificio.