Algernon vulnerabilities

Algernon, a small self-contained pure-Go web server, prior to version 1.17.9, on Windows contains a vulnerability in file handler selection for NTFS-equivalent names such as x.lua::$DATA. An unauthenticated client can access raw source code of server-side scripts, potentially exposing database credentials, API keys, and the SetCookieSecret value.

Algernon before version 1.17.7 has a vulnerability in the DirPage function that, when a directory without an index file is requested, searches parent directories (past the configured server root) for a handler.lua file. The found file is executed with full access to the Algernon API, allowing unauthenticated remote code execution.

Algernon before version 1.17.8, when started with --domain (or --letsencrypt), resolves the served directory by joining the configured --dir with the client-supplied Host header without validation, allowing attackers to read arbitrary files, list directories, and execute server-side Lua code.

Algernon prior to version 1.17.7 has a vulnerability in the SSE event server where the Access-Control-Allow-Origin header is hardcoded to '*', allowing third-party pages to read the filename stream via JavaScript.

The Algernon web server before version 1.17.7 bound the SSE event server to 0.0.0.0:5553 by default on Linux/macOS, allowing external access. This vulnerability is fixed in version 1.17.7.

In Algernon before 1.17.7, when invoked with a single file, debug mode exposes the full path and contents of the source file in error responses. Any client can trigger an error and obtain the source code.

Algernon before version 1.17.6 contains a vulnerability in the uploadedFileSaveIn() function in lua/upload/upload.go, which uses filepath.Join() with a caller-supplied directory without boundary checking after joining, allowing file writes outside the server's document root.

Algernon, a small self-contained pure-Go web server, prior to version 1.17.6, has a vulnerability in engine/luahandler.go where the sync.RWMutex protecting LoadCommonFunctions is released before L.Push() and L.PCall() execute. Since gopher-lua's LState is not goroutine-safe, concurrent requests race on the shared state, causing Lua VM corruption.