This Self-Hosted Knowledge Tool Could Publish Its Own Admin Panel to the Internet
A self-hosted application usually promises more control. In vulnerable versions of Knowns, a fresh installation could quietly invert that promise: the management API listened on every network interface, required no password and exposed an endpoint capable of creating a public tunnel back to itself.
The critical Knowns CVE-2026-86543 vulnerability affects versions before 0.30.0. The published record says an unauthenticated attacker with network access can call /api/tunnel/start, provision a tunnel and republish the API at a publicly accessible address. The flaw carries a CVSS 3.1 score of 9.8.
A second flaw in the same release window makes the exposure more consequential. Knowns CVE-2026-86542 allows an unauthenticated attacker to place traversal sequences in an import name, escape the intended imports directory and overwrite arbitrary files writable by the server process. It is fixed in the same 0.30.0 release.
The public tunnel starts inside the admin API
The first problem is not that an administrator intentionally published Knowns. The vulnerable default is more subtle. The browser-facing service binds to 0.0.0.0, and its authentication middleware becomes a no-op when no password is configured. According to the advisory, fresh installations do not require a password by default.
That combination exposes the management API to every network from which the listening port is reachable. The tunnel-start endpoint performs no separate authorisation check. An attacker who can reach the local API can ask the application to create a tunnel and give the management interface a public address.
This changes the normal exposure model. A service that was reachable only from a local network, development segment or mistakenly open host can be made reachable from the wider internet by a request sent through its own trusted management function. Firewall rules protecting inbound access do not necessarily describe the new outbound tunnel.
| Issue | Management API exposure | Import path traversal |
|---|---|---|
| Vulnerability | CVE-2026-86543 | CVE-2026-86542 |
| Impact | Unauthenticated management access and creation of a public tunnel | Arbitrary file write or overwrite within the permissions of the server process |
| Authentication required | No, when no password is configured | No |
| User interaction | None | None |
| Affected versions | Knowns before 0.30.0 | Knowns before 0.30.0 |
| Fixed version | 0.30.0 | 0.30.0 |
| CVSS 3.1 | 9.8 Critical | 9.1 Critical |
| Known exploitation | None reported in the published record | CISA’s enrichment records exploitation as none |
| Public technical details | Vendor advisory, vulnerable code references and fix commit are public | Vendor advisory, vulnerable code references, fix commit and a broader exploit chain are public |
An import name could become a filesystem path
The second weakness begins in Knowns’ import routes. Before 0.30.0, the application did not adequately validate the caller-supplied import name before using it to build a destination path. Directory traversal sequences could move the write outside the imports directory.
The assigned vulnerability gives an attacker an arbitrary file-write primitive bounded by the operating system permissions of the Knowns process. That is already enough to corrupt application data, overwrite configuration, disrupt service or replace files that another component later consumes.
The vendor-linked GitHub advisory also describes a two-request path to code execution that combines the file write with a separate language-server configuration behaviour. Defenders should distinguish those claims carefully. The CVE record assigns the path-traversal file-write weakness. The broader advisory documents how researchers chained that primitive with another configurable execution path.
Self-hosted does not mean locally contained
The most important boundary in this incident is not cloud versus on-premises. It is management plane versus untrusted network. A locally deployed tool can still expose privileged functions when it listens too broadly, treats a missing password as permission and can establish outbound connectivity on demand.
Development and personal knowledge tools are especially easy to overlook. They may contain notes, source material, tokens, imported repositories, internal URLs and drafts that were never meant to leave a workstation or small server. Their operators may not inventory them with the same discipline as a production service.
The tunnel capability raises a second monitoring problem. Exposure may not appear as a new inbound firewall rule. The application initiates an outbound connection to a tunnel provider, and the public endpoint exists elsewhere. Network controls that allow ordinary outbound HTTPS can therefore become part of the publication path.
Version 0.30.0 closes both paths
Knowns 0.30.0 is the fixed release for both vulnerabilities. The management-plane change removes the vulnerable unauthenticated exposure condition, while the import fix validates and confines caller-controlled paths. Operators should update rather than relying only on network placement.
Where an immediate update is impossible, administrators should bind the service only to a trusted local interface, require authentication, block unneeded access at the host and network layers, and restrict outbound tunnel traffic. Those steps reduce exposure but do not correct the unsafe import path handling.
Do not assume that setting a password now proves the system was not exposed earlier. If a vulnerable instance was reachable without authentication, review it as a possible compromise and inspect whether a tunnel was created or writable files were changed.
What Knowns operators should check
- Inventory every Knowns deployment, including developer workstations, home servers, test environments and containers outside the formal production catalogue.
- Upgrade all versions before 0.30.0 to version 0.30.0 or later.
- Confirm the service’s actual listening address from the host, rather than relying only on a configuration file.
- Require authentication and verify that an unauthenticated request cannot reach management endpoints.
- Restrict the service to trusted networks and block direct internet exposure.
- Inspect application, proxy, DNS and network telemetry for unexpected calls to
/api/tunnel/startand connections to tunnel infrastructure. - Review the imports directory and other paths writable by the Knowns process for unexpected files, replacements or timestamp changes.
- Rotate secrets stored in or accessible to the application if prior unauthenticated exposure cannot be ruled out.
- Reduce the process’s filesystem permissions so a future write primitive cannot reach unrelated application or system files.
The dangerous default is the complete chain
Each design choice can sound manageable in isolation. Listening on every interface helps a local web application work across devices. Skipping authentication avoids setup friction. Starting a tunnel makes remote access convenient. Accepting an import name makes project organisation flexible.
Together, those choices collapse multiple boundaries. A network-reachable stranger can enter the management plane, ask the application to publish that plane more broadly and use a separate input path to write outside its intended storage area.
The operational lesson is simple: convenience features that change reachability deserve their own authorisation checks. A missing password must fail closed. User-controlled names must never become unrestricted filesystem paths. Self-hosting provides control only when the application preserves those boundaries.
Knowns vulnerability questions
Does the management API flaw require an internet-facing server?
No. An attacker first needs network reach to the listening service. The tunnel endpoint can then give the API a public address, which makes an initially local or internal exposure more serious.
Does the file-write flaw automatically mean remote code execution?
The assigned vulnerability is an arbitrary file write or overwrite within the server process’s permissions. The vendor advisory describes a broader chain to code execution using a separate configuration behaviour, but operators should not treat every file write as identical to immediate code execution.
Is malicious exploitation confirmed?
No malicious exploitation was reported in the primary records checked. Technical details, vulnerable code references and fixes are public, so exposure should still be addressed promptly.
Sources and publication details
- Knowns management API security advisory, disclosure dated 16 August 2026. No publication time was provided in the CVE record.
- Knowns import path security advisory, disclosure dated 16 August 2026. No publication time was provided in the CVE record.
- Knowns 0.30.0 release, the fixed release for both issues.
- CVE Program management API record, published 8 September 2026 at 01:03:20 Europe/Madrid.
- CVE Program import path record, published 8 September 2026 at 01:03:20 Europe/Madrid and updated 8 September 2026 at 14:43:22 Europe/Madrid.
