Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Algernon selects its file handler from filepath.Ext() (engine/handlers.go:134), which does not treat the NTFS-equivalent names x.lua::$DATA, x.lua., or x.lua as .lua. On Windows, an unauthenticated client appends one of these suffixes to any server-side script on a public path and receives its raw source instead of executed output, leaking embedded secrets such as database credentials and the SetCookieSecret value. Linux and macOS hosts are unaffected. Preconditions - Algernon runs on a Windows host (NTFS filesystem). - The instance serves at least one server-side script (.lua, .tl, .po2, .amber, .frm). - The script sits on a public path, or no auth backend is configured (--nodb, --simple, or default no-DB). - HTTP/HTTPS reachability to the server. Details The request path reaches FilePage through URL2filename (utils/files.go:24), which rejects only ..; a :, a trailing ., and a trailing space all pass through into filename. filepath.Ext does an exact suffix match, so…
Recommended action: Upgrade to 1.17.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When algernon is started with --domain (or --letsencrypt, which silently turns on --domain at engine/flags.go:372), the request handler resolves the served directory by joining the configured --dir with the value of the client-supplied Host header. The join is performed by filepath.Join with no validation, so a Host: .. header walks one level above the document root. Subsequent file resolution then exposes everything in that parent directory — arbitrary file read, full directory listing, and, if any .lua file is present, server-side Lua execution. Algernon 1.17.7 and earlier are affected. Details engine/handlers.go (function RegisterHandlers, around line 510): utils/web.go (GetDomain): utils/files.go (URL2filename) only sanitises the URL path — it never inspects dirname: engine/flags.go (auto-enable in CertMagic / Let's Encrypt mode): Putting it together: 1. The client sends Host: ... Go's HTTP server accepts the value because . is in the URI host whitelist and there are no…
Recommended action: Upgrade to 1.17.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The SSE event server's Access-Control-Allow-Origin response header was hardcoded to the wildcard regardless of the caller's Origin. Because EventSource does not preflight and does not send cookies, the wildcard is sufficient to let any third-party page the developer visits open a cross-origin EventSource to the SSE port and read the live filename stream from JavaScript. Combined with the lack of authentication (advisory #2a), no further trickery is required — any tab the developer opens has script-level read access to the stream. This advisory covers the CORS configuration in isolation. The fix is independent of authentication and bind-address fixes: the wildcard could be replaced with a same-origin echo without touching either. Details Root cause — hard-coded "" passed as the CORS allowed-origin The literal "" is the second positional argument. The vendored recwatch implementation reflects it verbatim into the response header: There is no decision based on the request's…
Recommended action: Upgrade to 1.17.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The SSE event server bound to 0.0.0.0:5553 on Linux/macOS by default because the platform-dependent host default in engine/flags.go:39-46 set host = "" for non-Windows, and utils.JoinHostPort("", ":5553") resolves to ":5553" — a Go http.Server.Addr of ":5553" listens on every interface. On Windows the same code chose "localhost", binding loopback only. The result was a platform split where the OS Algernon's dev workflow is most often used on (Linux/macOS) got the network-exposed default, and only Windows users got the loopback-safe one. A LAN peer with no developer interaction could connect to <dev-laptop-ip:5553 and read the file-change stream. This advisory covers the bind-address default in isolation. The fix is independent of authentication (#2a) and CORS (#2b) — switching the default to loopback can be done without touching either. Details Root cause — platform-dependent host default in handleFlags Result tabulated: | Platform | host | eventAddr after JoinHostPort |…
Recommended action: Upgrade to 1.17.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When auto-refresh is enabled, Algernon spins up an SSE handler that streams a data: line for every filesystem event under the watched directory. The handler performs no authentication of any kind — no shared token, no cookie check against the permissions2 userstate, no IP allow-list, no path-prefix permission. Any client that can complete a TCP connection to the listener address receives the stream. This advisory covers the authentication gap in isolation. The cross-origin browser-reach (advisory #2b) and the network-reach (advisory #2c) amplify the impact, but each is independently fixable; this finding addresses the case where a same-origin or LAN-local client connects directly to the SSE port and reads the stream without proving anything about its identity. Details Root cause — the SSE handler does not consult permissions2 or any other auth Note the handler signature: func(w http.ResponseWriter, http.Request). The request is discarded — no Cookie, Authorization,…
Recommended action: Upgrade to 1.17.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When Algernon is asked for any URL path that resolves to a directory without an index file, DirPage walks upward through parent directories — past the configured server root — looking for a file named handler.lua to execute as the request handler. The loop terminates only after 100 ancestor steps or when filepath.Dir returns ., so on any absolute server-root path the search reaches the filesystem root (/ on Unix, drive letter on Windows). The first handler.lua it finds is loaded into the Lua interpreter with the full Algernon API exposed — including run3(), httpclient, os.execute, io.popen, PQ, MSSQL, raw filesystem access, and the userstate database. Any process that can write handler.lua anywhere in a parent directory of the server root obtains pre-authenticated remote code execution on the next HTTP request. This is reachable without authentication — the lookup happens before the permission check returns a hit (the perm system only gates URL prefixes, not the…
Recommended action: Upgrade to 1.17.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When Algernon is invoked with a single file path instead of a directory — the documented "quick demo" workflow (algernon foo.lua, algernon page.po2, algernon index.html, algernon mywebsite.alg) — singleFileMode is set to true and debugMode is forcibly enabled with no opt-out: debugMode activates the PrettyError renderer, which on any Lua or template error response dumps: 1. The absolute path of the file that errored (Filename field of the error template). 2. The complete byte contents of that file, HTML-escaped, with the offending line wrapped in <font style='color: red !important'…</font. 3. The exception or parser error text — which in turn often quotes additional file content (Pongo2 errors include surrounding template lines; Lua tracebacks include argument values). This response is served with HTTP 200 OK to whoever sent the request that triggered the error. There is no authentication, no rate limit specific to errors, no redaction, and no opt-out short of avoiding…
Recommended action: Upgrade to 1.17.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cross-site Scripting vulnerability in Algernon v1.17.4 allows attackers to execute arbitrary code via injecting a crafted payload into a filename.
Recommended action: Upgrade to 1.17.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.