Revisión de tres alertas altas de secretos en n8n
Revisamos tres alertas altas de n8n: la procedencia del escaneo y el contexto del código deben comprobarse antes de declarar una filtración.
Más allá de ASPM
AppSec basada en pruebas para equipos que desarrollan con IA
Plexicus usa AI Swarm Pentest para explorar rutas de aplicaciones autorizadas, validar qué es explotable y dar a los equipos evidencia para priorizar la remediación.
Explorar AI Swarm PentestEl 29 de octubre de 2026 revisamos un conjunto de resultados de Plexicus asociado al repositorio de n8n. Contenía 110 alertas de secretos: tres clasificadas como altas y 107 medias. Ese resumen podría parecer una prueba de credenciales filtradas. Los registros detallados no permitían concluirlo.
Inspeccionamos los tres registros de gravedad alta y contrastamos sus ubicaciones con el código público de la revisión inmutable solicitada. Dos ubicaciones corresponden a constantes de nombre de credencial dentro de módulos simulados. La tercera corresponde a una declaración de tipo de credencial. Ninguna demuestra una credencial utilizable expuesta. La falta del commit realmente escaneado impide también declarar definitivamente falsos positivos del escáner.
Qué demuestran los tres registros
Los registros llevaban la etiqueta «Use of Hard-coded Credentials». Incluían ruta y línea, pero sus campos de código, informe del escáner y descripción estaban vacíos. El indicador de falso positivo era falso. Ese estado de trabajo no demuestra de forma independiente que exista una credencial.
| Ubicación notificada | Código público en la revisión solicitada | Resultado de la revisión |
|---|---|---|
| CredentialConfig.test.ts, línea 1002 | Declaración ICredentialType | Los metadatos no demuestran un valor de credencial |
| Prueba de borrado de página de Confluence, línea 14 | CONFLUENCE_CREDENTIAL_NAME dentro de vi.mock | El nombre simulado no demuestra un secreto utilizable |
| Prueba de borrado de adjunto de Confluence, línea 8 | El mismo tipo de constante simulada | Hace falta la coincidencia original del escáner |
Las pruebas de configuración de credenciales, borrado de páginas y borrado de adjuntos son referencias públicas e inmutables. Publicamos únicamente los identificadores necesarios para explicar el análisis. No incluimos valores de credenciales, identificadores privados ni respuestas completas de la API.
La revisión ausente cambia el veredicto
El registro de Open Source Explorer solicitaba 447fc866bb0a841decfa5e8a29fba06057bfc5bc. Pudimos recuperar los archivos de upstream en ese SHA exacto. Sin embargo, los registros no identificaban la ejecución ni el commit realmente escaneado. Un recuento del repositorio puede incluir registros de otro momento de su historia.
Cuando las líneas cambian, una declaración inocua en la revisión solicitada no demuestra qué detectó el escáner antes. Una etiqueta alta tampoco sustituye la evidencia que falta. El resultado limitado es: los tres registros disponibles y su contexto no establecen una exposición de credenciales. No significa que n8n carezca de secretos en todo su código ni que todas las alertas sean incorrectas.
Modelo original de revisión. Explica la evidencia necesaria para decidir; no representa una filtración reproducida.
Un archivo de pruebas aporta contexto
Las credenciales reales también pueden terminar en pruebas, ejemplos y fixtures. Excluir todos esos directorios ocultaría filtraciones auténticas. Hay que determinar qué hace el valor: si autentica, nombra un tipo de credencial, actúa como marcador sintético o referencia otro objeto.
Las dos ubicaciones de Confluence asignan una constante de nombre dentro de un módulo simulado y sustituyen la función de API por un doble de prueba. La tercera inicia un objeto de configuración tipado. Antes de pedir rotaciones o anunciar un incidente, corresponde recuperar la coincidencia original y la explicación de la regla.
Si esa evidencia posterior demuestra una credencial real, sanitiza el informe público y sigue el procedimiento de revocación del proveedor. No intentamos autenticar con ningún valor ni enviamos credenciales candidatas a servicios externos.
Conserva la evidencia junto a la decisión
Guarda la versión del escáner y la regla, el commit escaneado, el rango de código, la coincidencia redactada, la clase de credencial y el razonamiento del revisor. Indica quién asume la corrección. Una comprobación bloqueada o una carga ausente sigue pendiente.
Nuestro flujo de Proof-Driven AppSec conecta la alerta con un resultado revisable. La guía de corrección describe el paso a un cambio revisado. Deep Code Analysis explica el valor del contexto.
Plexicus proporciona los metadatos utilizados. La inspección y las conclusiones de este artículo son una investigación editorial, no una decisión que hayamos demostrado como función automatizada del producto. El flujo de corrección y AI Swarm Pentest describen otros trabajos acotados; no convierten estos registros en filtraciones confirmadas.
Cómo completar el análisis
Solicita la coincidencia original y la revisión real. Reconcilia las líneas antes de confirmar o descartar la alerta. Conserva los enlaces de esta revisión solicitada para que otro analista pueda completar el expediente. No hemos establecido un parche de n8n, una revocación ni una explotación exitosa.
Fuentes
¿Necesitas convertir alertas en decisiones de ingeniería? Contacta con Plexicus con la revisión del repositorio y un paquete de evidencias sanitizado.
