Gitea and n8n exposure: why configuration matters more than asset counts

Recent internet scans have identified hundreds of thousands of publicly accessible instances of Gitea and n8n, two popular self-hosted tools for code management and workflow automation. While the sheer volume of exposed assets raises immediate concerns, security experts emphasize that the presence of these services online does not automatically equate to a breach. The critical factor is not just visibility, but how these platforms are configured to handle the sensitive credentials they store on behalf of users.

What happened

On 28 October 2026, measurements collected via the ZoomEye platform revealed significant numbers of indexed assets identifying as specific self-hosted applications. The scan found 117,523 assets matching the signature for Gitea, a lightweight Git service. For n8n, a workflow automation tool, the count was substantially higher at 420,452 assets matching its application signature, with an additional 401,268 matches based on page titles. These figures represent the number of systems that responded to identification probes, not necessarily the number of compromised or misconfigured servers.

The analysis highlights that both Gitea and n8n serve as central repositories for secrets. Gitea stores deploy keys, webhook secrets, access tokens, and often SSH keys used for code pushes. Similarly, n8n workflows contain API credentials for various external services integrated into automated processes. Because these platforms concentrate high-value authentication data, any instance left open to the public internet requires rigorous scrutiny. The risk is not merely unauthorized access to the platform itself, but the potential theft of the third-party credentials stored within it.

Key details

• ZoomEye recorded 117,523 Gitea instances and 420,452 n8n instances on 28 October 2026.
• Gitea stores sensitive items like deploy keys, webhook secrets, and SSH keys alongside code repositories.
• n8n workflows embed API credentials for connected external services, making them high-value targets.
• Default Gitea settings include INSTALL_LOCK to secure the setup page and DISABLE_REGISTRATION to prevent unauthorized sign-ups.
• n8n instances often require public accessibility for webhooks, increasing their exposure compared to VPN-only Gitea setups.
• Asset counts do not indicate vulnerability; many indexed instances may be properly hardened with single sign-on and restricted access.

Background

Self-hosted software gives organizations control over their data and infrastructure, but it also shifts the responsibility for security entirely to the operator. Unlike managed cloud services where the provider handles patching and access controls, self-hosted instances rely on the administrator to configure security settings correctly from day one. Tools like Gitea and n8n are designed to integrate deeply with other systems, which necessitates storing authentication tokens and keys locally. This architectural choice creates a "credential vault" effect, where compromising the host yields access to multiple external services.

The discrepancy in public visibility between Gitea and n8n stems from their typical deployment patterns. Gitea is often used by development teams who can access it via a corporate VPN, allowing it to remain invisible to the public internet. In contrast, n8n relies on webhooks to receive triggers from external providers like payment gateways or CRM systems. This functional requirement often forces n8n instances to be publicly reachable, making them more likely to appear in internet-wide scans. Understanding this distinction helps contextualize why n8n appears more frequently in public indexes despite both tools being widely adopted.

Why it matters

For teams running their own software, these findings underscore the danger of "set and forget" deployments. It is common for administrators to install a tool for evaluation or initial setup and leave it running with default configurations. In Gitea, if INSTALL_LOCK is not enabled, the initial configuration page remains accessible, potentially allowing an attacker to reset administrative settings. Similarly, if registration is not disabled, unauthorized users can create accounts and potentially access internal repositories or workflow definitions. These oversights are not complex exploits but simple configuration gaps that leave the door open.

The accumulation of stale credentials poses another silent threat. Automation platforms like n8n tend to grow organically, with new integrations added over time. Old workflows connecting to deprecated services or using credentials from former employees often remain active because removing them feels risky. If an instance is exposed, attackers can harvest these long-forgotten tokens. Regular audits of both the platform’s access controls and the specific secrets stored within workflows are essential to maintain a secure posture. The high number of indexed assets suggests that many organizations may not be performing these routine checks.

What you can do

• Verify that INSTALL_LOCK is set to true in your Gitea configuration to block access to the setup wizard.
• Ensure DISABLE_REGISTRATION is enabled in Gitea unless you specifically intend to allow public sign-ups.
• Review n8n user management settings to confirm that only authorized personnel can create accounts or modify workflows.
• Audit all deploy keys and webhook secrets in Gitea, removing any that belong to departed staff or unused projects.
• Check n8n workflows for obsolete API credentials and rotate keys for any services that are still actively used.
• Consider placing self-hosted instances behind a reverse proxy or VPN to limit public exposure to only necessary endpoints.