Revisar los Community Nodes de n8n: cuánta confianza merece el código de terceros

Un Community Node de n8n es un paquete npm de alguien que usted no conoce, y se ejecuta en la misma máquina que sus credenciales de acceso al CRM, la contabilidad y el correo. La instalación tarda dos minutos, la responsabilidad queda después de su lado. La pregunta antes del uso en producción no es, por tanto, una pregunta de funcionalidad, sino una pregunta sobre la cadena de suministro: quién mantiene este código, con qué frecuencia, y qué ocurre si mañana ya nadie se interesa por él.

El catálogo es lo bastante grande como para que la intuición no baste. El registro de npm indica, para la palabra clave de paquete prescrita por n8n, 12.022 paquetes (consultado el 3 de agosto de 2026). Aquí se trata de las extensiones, no del núcleo de n8n: para eso está el artículo sobre endurecimiento de seguridad.

¿Qué permisos obtiene un Community Node en su instancia?

Un Community Node se ejecuta con los mismos permisos que el propio n8n. La documentación de n8n sobre los riesgos lo expresa sin rodeos: los Community Nodes tendrían "full access to the machine that n8n runs on, and can do anything, including malicious actions", y cada node utilizado tiene acceso a los datos de sus workflows.

Por eso la instalación está vinculada a roles. En una instancia self-hosted, según la documentación de instalación solo Owner y Admin pueden instalar Community Nodes desde npm, y el cuadro de diálogo exige la confirmación activa de la frase "I understand the risks of installing unverified code from a public source". Además, n8n mantiene una lista de bloqueo para paquetes que son deliberadamente maliciosos o deficientes en un grado perjudicial.

Que el riesgo es real y no teórico lo ha documentado el propio n8n. Tras el gusano de npm Shai-Hulud, la empresa informó en su Security Advisory del 25 de noviembre de 2025 que los paquetes npm utilizados en el núcleo de n8n no se vieron afectados, pero sí dos Community Nodes no verificados, cuya instalación se desaconsejó explícitamente.

¿Qué significa realmente "verificado" en los Community Nodes de n8n?

Verificado significa: n8n ha comprobado el paquete enviado frente a un catálogo fijo de requisitos de seguridad y calidad, y lo ha incorporado al panel de nodes. Al inicio, según el anuncio de n8n unos 25 nodes, reconocibles por un icono de escudo, a partir de n8n 1.94.0. Las directrices de verificación también sirven de referencia para los paquetes no verificados:

• Sin dependencias en tiempo de ejecución: cada dependencia transitiva sería un editor externo adicional en su cadena de suministro.
• Licencia MIT: para que la reutilización y el mantenimiento propio permanezcan jurídicamente indiscutibles.
• Sin acceso al entorno ni al sistema de archivos: el código no puede leer variables de entorno ni leer o escribir archivos.
• Exactamente un servicio de terceros por paquete: sin nodes de control de flujo, sin duplicados de nodes existentes.
• Escaneo superado: npx @n8n/scan-community-package debe ejecutarse sin errores.
• Origen verificable: desde el 1 de mayo de 2026, los nodes enviados deben, según la documentación de envío publicarse mediante GitHub Actions con una declaración de procedencia; ya no se acepta una publicación desde una máquina local.

Cabe una salvedad: un paquete enviado se comprueba en un momento dado. El sello no responde a quién publicará la versión posterior a la siguiente.

¿Qué criterios de revisión se aplican antes del uso en producción?

Seis criterios deciden, y los seis se responden en pocos minutos a partir de metadatos públicos de npm, sin leer una sola línea de código. El registro proporciona en registry.npmjs.org/<paketname> los campos time, maintainers, dist-tags, repository y license.

• Estado de mantenimiento: el campo time contiene la marca de tiempo de cada versión publicada. Si la última publicación tiene más de doce meses mientras el servicio conectado ha seguido evolucionando su API, el node está en vías de extinción.
• Factor bus: maintainers muestra cuántas personas pueden publicar. Un único maintainer privado no es un criterio de exclusión, pero sí un motivo para planificar la ruta de sustitución con antelación.
• Difusión: el endpoint api.npmjs.org/downloads/point/last-month/<paketname> devuelve las descargas junto con el período. Como referencia: el propio paquete n8n alcanza allí 335.472 descargas del 4 de julio al 2 de agosto de 2026. Con una cifra mensual de tres dígitos, casi nadie encuentra los errores antes que usted.
• Profundidad de dependencias: las dependencies del paquete. npm audit las compara con vulnerabilidades conocidas. Cero dependencias en tiempo de ejecución es el valor objetivo.
• Origen y firma: si repository apunta a un repositorio real y público. Con npm audit signatures se pueden comprobar las atestaciones de procedencia, es decir, la prueba de que el paquete procede del repositorio indicado y de un pipeline de CI trazable.
• Necesidad de permisos: qué credenciales solicita el node, y si el alcance se corresponde con el propósito. Un node para un único servicio que solicita permisos amplios requiere explicación.

¿Qué ocurre si se abandona el proyecto?

El abandono de un proyecto no se nota al principio, porque la versión instalada sigue funcionando. Se hace visible en la siguiente actualización de n8n: un Community Node que ya no es compatible con la nueva versión de n8n puede bloquear el arranque de la instancia, véase n8n no arranca tras la actualización. Un problema de mantenimiento silencioso se convierte entonces en un fallo de todos los workflows en un minuto.

Por eso el plan de salida debe existir antes de la instalación. Bastan tres puntos: una ruta de sustitución designada, normalmente el node HTTP Request integrado contra la misma API, porque un Community Node por lo general solo hace más cómoda una interfaz REST. Una versión fija en lugar de una etiqueta móvil. Y la lista de workflows afectados. La instalación mediante variable de entorno ayuda en esto: N8N_COMMUNITY_PACKAGES admite el nombre del paquete, una versión opcional y una suma de comprobación SHA-512 opcional del tarball resuelto, con lo que no solo se fija la versión, sino también el contenido del paquete. En n8n Cloud la cuestión se plantea de otro modo, ya que allí solo hay disponibles nodes verificados, véase cambio de self-hosted a la nube.

¿Cómo limitar el riesgo en la instancia?

La configuración predeterminada de una instancia n8n recién instalada está orientada a la apertura, no a la precaución. Cinco variables de entorno cambian esto. Según la documentación de las variables de entorno se aplica lo siguiente:

• N8N_COMMUNITY_PACKAGES_ENABLED: Por defecto true. Con false, la instancia desactiva por completo los Community Nodes, tanto verificados como no verificados.
• N8N_UNVERIFIED_PACKAGES_ENABLED: Por defecto true. Con false, solo quedan utilizables los nodes verificados. El interruptor único más eficaz para la mayoría de las instancias de empresas medianas.
• N8N_VERIFIED_PACKAGES_ENABLED: Por defecto true. Controla si los nodes verificados aparecen en el panel de nodes.
• N8N_COMMUNITY_PACKAGES_MANAGED_BY_ENV: Por defecto false, a partir de n8n 2.21.0. Con true, n8n compara los paquetes instalados con la configuración en cada arranque y deja la gestión en la interfaz en modo de solo lectura. El conjunto de nodes pasa entonces a formar parte del despliegue en lugar de ser el resultado de clics.
• NODES_EXCLUDE: por defecto contiene n8n-nodes-base.executeCommand y n8n-nodes-base.localFileTrigger, ampliable con cualquier node que no deba ejecutarse.

En los entornos n8n que operamos en NordFlux para nuestros clientes, rige lo siguiente: los Community Nodes no verificados están desactivados en la instancia de producción, los candidatos se revisan en una instancia de prueba independiente con credenciales propias, y ningún node pasa a producción mientras su ruta de sustitución no esté documentada. Esto cuesta media hora durante la configuración. Más información en la página sobre hosting de n8n en Alemania.

Preguntas frecuentes sobre los Community Nodes de n8n

¿Son seguros los Community Nodes de n8n verificados?

Los nodes verificados son comprobados por n8n frente a un catálogo fijo: sin dependencias en tiempo de ejecución, licencia MIT, sin acceso a variables de entorno ni al sistema de archivos, exactamente un servicio de terceros conectado, escaneo de paquete superado. Esto reduce notablemente el riesgo, pero no sustituye la comprobación del estado de mantenimiento, porque la verificación se refiere a un paquete enviado y no a cada versión futura.

¿Puedo usar Community Nodes en n8n Cloud?

Solo los verificados. La instalación desde npm, y por tanto todos los nodes no verificados, solo es posible en self-hosted, según la documentación de n8n. Quien utilice nodes no verificados o creados por sí mismo debe sustituirlos antes de pasar a la nube.

¿Cómo puedo saber que un Community Node ya no recibe mantenimiento?

Por el campo time en los metadatos de npm en registry.npmjs.org/<paketname>, que contiene todas las marcas de tiempo de las versiones publicadas. Una última versión más antigua que el último cambio importante de la API del servicio conectado es la señal más clara.

¿Cómo evito que los empleados instalen nodes por su cuenta?

En las instancias self-hosted, de todos modos solo las cuentas Owner y Admin pueden instalar Community Nodes; el resto de usuarios solo pueden usar los nodes instalados. Quien quiera fijar el conjunto establece N8N_COMMUNITY_PACKAGES_MANAGED_BY_ENV en true: la gestión en la interfaz pasa a ser de solo lectura.

¿Qué hacer si se informa de que un node en uso está comprometido?

Excluir el node de la carga mediante NODES_EXCLUDE, detener los workflows afectados, rotar todas las credenciales a las que el node tenía acceso. n8n publica estos casos en la categoría Security Advisories del foro de la comunidad.