Last updated: August 19, 2026 at 1:47 AM UTC
All 741 Vulnerability 286 Breach 129 Threat 319 Defense 7
Tag: self-hosted (8 articles)Clear

Unpatched GeoServer zero-day allowing code execution is already being probed

A newly disclosed zero-day in GeoServer, the widely used open-source geospatial server, is already drawing exploitation attempts, according to watchTowr. The flaw is a SQL injection issue that can lead to remote code execution, and it remains unpatched, with no CVE assigned yet. It was first disclosed publicly by a researcher on August 12, and attackers commonly begin probing internet-facing servers as soon as such details appear. GeoServer instances are frequently exposed to the internet to serve mapping and location data, which makes an unpatched code-execution flaw in the platform an attractive and reachable target. Defenders should treat exposed instances as at risk until a fix ships.

Check
Identify internet-facing GeoServer instances, restrict access to them, and monitor closely for exploitation, since the flaw is unpatched and attackers are already probing for vulnerable servers.
Affected
Organizations running internet-exposed GeoServer; an unpatched SQL injection flaw can lead to remote code execution, there is no fix or CVE yet, and probing for vulnerable instances has already started.
Fix
Limit GeoServer exposure behind authentication or a firewall until a patch is available, monitor for suspicious database queries and process execution, and apply the vendor fix as soon as it is released.

Leaked n8n API tokens in public code exposed live automation instances

GitGuardian found 321 live n8n automation instances reachable using API tokens that developers had accidentally committed to public GitHub repositories, and showed four ways an attacker could abuse them. n8n workflows often hold credentials for the services they connect, so a valid API token can expose not just the automation platform but the downstream accounts it touches, from cloud services to messaging and databases. Because n8n is widely self-hosted and frequently wired into sensitive systems, an exposed token can become a path to broader compromise. The finding is a reminder that secrets committed to source control remain one of the most reliable ways in.

Check
Scan your repositories and history for committed n8n API tokens and other secrets, rotate anything exposed, and confirm n8n instances are not reachable from the internet without protection.
Affected
Teams self-hosting n8n whose API tokens reached public code; an attacker can drive the automation platform and reach the downstream credentials stored in its workflows, from cloud services to databases.
Fix
Rotate exposed tokens, add automated secret scanning to block commits, scope n8n credentials tightly, keep instances behind authentication and off the public internet, and audit workflows for stored downstream credentials.

Attacker wires DeepSeek into an agent to hunt and exploit exposed servers

Palo Alto Networks Unit 42 detailed a Chinese-speaking attacker who used the DeepSeek model as the reasoning engine inside an open-source agent called Hermes to attack exposed servers with little human input. Taking instructions over Telegram and using an internet asset search engine, the agent ran in a mode that executes commands without asking permission: from a single task, it downloaded a public exploit, enumerated vulnerable Langflow and n8n instances, judged targets by value, and attempted exploitation on its own. The autonomous attempts failed, blocked by authentication and configuration, though the operator succeeded manually elsewhere. The operation was exposed when the agent accidentally served its own working directory over the web.

Check
Keep self-hosted tools like n8n and Langflow patched, authenticated, and off the public internet, since autonomous agents now scan asset search engines and attempt exploitation without a human in the loop.
Affected
Organizations exposing self-hosted AI and automation tools such as Langflow and n8n; autonomous AI agents can discover, rank, and attack them at scale, though basic authentication and hardening blocked the observed attempts.
Fix
Require authentication, disable risky auto-login options, restrict management interfaces, and patch known flaws, since the defensive configurations that stopped this agent are the same controls that blunt automated exploitation generally.

n8n sandbox escape lets workflow editors run commands on the server

n8n patched a high-severity flaw that lets an authenticated user who can create or edit workflows escape the expression sandbox and run operating-system commands as the n8n process. Security Joes found it while probing n8n's February fix for an earlier sandbox bug, and the gap sits in how the rewriter handled a bare identifier in a concise arrow function body. Successful exploitation can expose the n8n encryption key and allow decryption of stored credentials. It is tracked as GHSA-gv7g-jm28-cr3m with a score of 8.7 and no CVE assigned yet. Fixed versions are 2.31.5 and 2.32.1, with no patched 1.x release listed.

Check
Update self-hosted n8n to 2.31.5 or 2.32.1 or later, and treat the vendor's interim advice to restrict editing to trusted users as an incomplete stopgap rather than a fix.
Affected
Self-hosted n8n deployments before 2.31.5 or on 2.32.0 (GHSA-gv7g-jm28-cr3m); any account allowed to create or modify workflows can run commands as the n8n process and expose stored credentials.
Fix
Upgrade to a fixed release, rotate the n8n encryption key and stored credentials if you ran an exposed version, and keep the instance off the public internet.

Attackers exploit Windmill flaw to read server files and reach superadmin access

VulnCheck reports active exploitation of a path traversal flaw in Windmill, an open source platform for building internal tools, jobs, and workflows. CVE-2026-29059 lets an unauthenticated attacker read arbitrary files through the log file endpoint, and while observed attempts included reading the password file, the higher value target is the superadmin secret. Where that is configured, an attacker can authenticate as a super administrator and run arbitrary code through the job preview API. VulnCheck counted roughly 170 exposed instances across 24 countries, including deployments reachable through a proxy path rather than directly.

Check
Update Windmill to a fixed release, confirm whether any instance was reachable from the internet, and treat the superadmin secret and any credentials stored in configuration as exposed.
Affected
Organizations running internet-reachable Windmill deployments (CVE-2026-29059); unauthenticated attackers read server files, and where the superadmin secret is set, escalate to full administrative access and code execution.
Fix
Patch to the fixed version, rotate the superadmin secret and stored credentials, keep internal automation platforms off the public internet or behind authentication, and review logs for file read attempts.

n8n token exchange flaw could let attackers log in as other users

A vulnerability in the workflow automation platform n8n could let an attacker log in as another user without their password. Tracked as CVE-2026-59208, the flaw sits in n8n's Enterprise token exchange feature, which lets embedded deployments avoid a second login by accepting tokens from partner identity providers. Because the code did not properly bind an identity to its issuer, a valid token from one issuer that carried the identifier of a user under a different issuer would log the attacker in as that user. n8n shipped a fix on June 24, and there is no evidence of exploitation. The bug was found by an AI penetration-testing agent.

Check
Check whether you run n8n, especially Enterprise deployments using the token exchange feature for embedding or single sign-on, confirm the version, and update to a release that includes the June fix.
Affected
Organizations running n8n Enterprise deployments that use the token exchange feature (CVE-2026-59208); a flaw in binding identities to issuers could let an attacker present a token and log in as another user.
Fix
Update n8n to a version containing the June 24 fix, review authentication logs for unexpected cross-issuer logins, and apply least privilege so that a single compromised account has limited reach.

Gitea Docker images trusted a forged header, letting anyone log in as any user

Attackers have started probing a critical flaw in Gitea's official Docker images, the self-hosted Git service used by many development teams. The images shipped a configuration that trusted the X-WEBAUTH-USER header from any source address, so with reverse-proxy login enabled, anyone who could reach the port could send that header and be authenticated as any user, no password required. Tracked as CVE-2026-20896 and rated 9.8, it was fixed in version 1.26.3 late last month, which removes the wildcard and makes reverse-proxy authentication opt-in. Sysdig reported the first exploitation attempt 13 days after disclosure, so far just reconnaissance, against some of the roughly 6,200 internet-facing Gitea instances.

Check
Check whether you run Gitea from its Docker image and on what version, review the app.ini reverse-proxy trusted-proxies setting for a wildcard, and whether the instance is internet-reachable.
Affected
Self-hosted Gitea Docker deployments on version 1.26.2 or earlier with reverse-proxy login enabled (CVE-2026-20896); an unauthenticated attacker who can reach the service can impersonate any user by forging one header.
Fix
Update Gitea to 1.26.3 or later, remove the wildcard from the reverse-proxy trusted-proxies setting, keep management interfaces off the public internet, and review logs for spoofed X-WEBAUTH-USER authentication attempts.

Critical GitHub flaw lets a single 'git push' run code remotely on the server - patched, but most self-hosted GitHub Enterprise instances haven't updated yet (CVE-2026-3854)

Researchers disclosed CVE-2026-3854, a critical GitHub Enterprise Server flaw that lets anyone with push access execute arbitrary commands on the GitHub server with a single git push. The bug is in how Enterprise Server handles repository hooks during push operations - a crafted commit message or filename bypasses the sanitization that normally prevents shell injection. GitHub patched it last week, but self-hosted instances need to apply the patch manually, and telemetry shows most haven't yet. Anyone with developer-level access to a vulnerable Enterprise Server can take over the entire instance, then pivot into every repository and CI/CD secret it hosts.

Check
If you run a self-hosted GitHub Enterprise Server, apply the latest patch this week and review push activity from any low-privilege accounts since the patch was released.
Affected
Self-hosted GitHub Enterprise Server instances on versions before the April 2026 patch. The bug requires push access to any repository, which means every developer with commit rights is a potential entry point. CI/CD secrets, signing keys, and source code are exposed. GitHub.com (the SaaS product) is not affected.
Fix
Upgrade GitHub Enterprise Server to the patched release per GitHub's advisory. Until patched, restrict push access to trusted accounts and require code review on all pushes. Audit Enterprise Server logs for unusual git operations or shell processes spawning from the GitHub system user. Rotate any CI/CD secrets, signing keys, and webhook tokens stored on the server.