Vulnerability-Lookup

GHSA-FWQX-8365-9983

Vulnerability from github – Published: 2026-05-19 14:35 – Updated: 2026-05-19 14:35

Summary

Algernon: Single-file mode unconditionally enables debug mode

Details

Summary

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:

// engine/config.go:498-502
// Make a few changes to the defaults if we are serving a single file
if ac.singleFileMode {
    ac.debugMode = true
    ac.serveJustHTTP = true
}

debugMode activates the PrettyError renderer, which on any Lua or template error response dumps:

The absolute path of the file that errored (Filename field of the error template).
The complete byte contents of that file, HTML-escaped, with the offending line wrapped in <font style='color: red !important'>…</font>.
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 single-file invocations entirely. Any client able to reach the server and able to provoke a runtime error in the served script obtains the full server-side source of that script and of any sibling Lua data file consulted during the request.

This combines particularly badly with --prod not being effective: --prod sets productionMode = true and calls ac.debugMode = false inside finalConfiguration, but singleFileMode is computed after --prod in MustServe (line 499 vs finalConfiguration further down) and the forced debugMode = true happens before --prod's debugMode = false clamp runs — so even an operator who reasoned "I will pass --prod to be safe" gets debug-mode-on if they also pass a single Lua file. Operators routinely combine the two when running Algernon as a system unit (ExecStart=algernon --prod /etc/algernon/site.lua), unaware that single-file detection has overridden their hardening flag.

Details

Root cause 1 — single-file detection forces `debugMode = true`

// engine/config.go:441-502  (inside MustServe — abridged)
switch strings.ToLower(filepath.Ext(serverFile)) {
case ".md", ".markdown":
    ...
case ".zip", ".alg":
    ...
default:
    ac.singleFileMode = true
}
// ...
// Make a few changes to the defaults if we are serving a single file
if ac.singleFileMode {
    ac.debugMode = true
    ac.serveJustHTTP = true
}

Any single-file invocation whose extension is not .md/.zip/.alg lands in the default: branch and turns into singleFileMode = true, which then sets debugMode = true. That includes the natural quickstart inputs — .lua, .po2, .pongo2, .html, .amber, .tmpl, .jsx, .tl, .prompt — every file extension Algernon recognises as a server-renderable handler.

The .lua case has a follow-up at engine/config.go:536-548 that resets singleFileMode = false so the script can read sibling files, but debugMode has already been written to true and is not unset.

Root cause 2 — `--prod`'s clamp runs after the forced enable, so it is the wrong direction

// engine/config.go:393-397  (finalConfiguration, called from MustServe)
// Turn off debug mode if production mode is enabled
if ac.productionMode {
    // Turn off debug mode
    ac.debugMode = false
}

This clamp is in finalConfiguration. finalConfiguration is invoked from MustServe after the single-file block (MustServe line 632: ac.finalConfiguration(ac.serverHost)). So the order is:

1. flag parsing       -> productionMode=true, debugMode=false
2. single-file detect -> debugMode = true     (overrides production)
3. finalConfiguration -> if productionMode { debugMode = false }

On paper step 3 wins. In practice the operator-controlled execution path through MustServe for .lua files is:

1. flag parsing                                            -> productionMode=true, debugMode=false
2. single-file detect (line 493 default branch)            -> singleFileMode = true
3. if singleFileMode { debugMode = true } (line 499)       -> debugMode = true
4. if singleFileMode && ext==".lua" { singleFileMode = false; serverDir = Dir(...) }
5. ac.RunConfiguration(luaServerFilename, mux, true)       -> Lua server-conf script runs, may register handlers
6. ac.finalConfiguration(host)                              -> if productionMode { debugMode = false }   ← clamp restored

Step 5 happens between the forced enable and the production clamp, and inside the configuration script Lua code may already check or expose debugMode (the debug() global is wired in [engine/serverconf.go]). Anything that latches on debugMode during step 5 — including RegisterHandlers itself when called from within the server-conf script — picks up the wrong value. The clamp at step 6 may or may not retroactively fix downstream behaviour; for PrettyError, which reads ac.debugMode at request-time, the clamp does win for .lua single-file mode — but only because of the late ordering inside MustServe. For the other single-file extensions (.po2, .html, .amber, …), step 4's reset does not run, singleFileMode stays true, and --prod collides with singleFileMode semantically (a "single file" cannot meaningfully be a production system service). The forced debugMode = true survives because no later code branches re-clamp it for non-.lua paths.

Empirically: algernon --prod foo.po2 (or .amber, .tmpl) on a stock Algernon binary serves PrettyError-style debug responses on template failures. --prod does not save the operator.

Root cause 3 — `PrettyError` discloses absolute path + full source

// engine/prettyerror.go:82-147  (abridged)
func (ac *Config) PrettyError(w http.ResponseWriter, req *http.Request, filename string, filebytes []byte, errormessage, lang string) {
    w.WriteHeader(http.StatusOK)
    w.Header().Add(contentType, htmlUTF8)
    // ... linenr parsing elided ...
    filebytes = bytes.ReplaceAll(filebytes, []byte("<"), []byte("&lt;"))
    bytelines := bytes.Split(filebytes, []byte("\n"))
    if (linenr >= 0) && (linenr < len(bytelines)) {
        bytelines[linenr] = []byte(preHighlight + string(bytelines[linenr]) + postHighlight)
    }
    code = string(bytes.Join(bytelines, []byte("\n")))
    title := errorPageTitle(lang)
    data := struct {
        Title         string
        Filename      string
        Code          string
        ErrorMessage  string
        VersionString string
    }{
        Title:         title,
        Filename:      filename,        // absolute path on disk
        Code:          code,            // entire file
        ErrorMessage:  strings.TrimSpace(errormessage),
        VersionString: ac.versionString,
    }
    ...
}

The HTML template at the top of the file embeds those fields directly:

Contents of {{.Filename}}:
<div>
  <pre><code>{{.Code}}</code></pre>
</div>
Error message:
<div>
  <pre id="wrap"><code style="color: #A00000;">{{.ErrorMessage}}</code></pre>
</div>

Every byte of the script — including any DB connection string, API key, JWT signing secret, S3 access key, or hard-coded admin credential the operator left in index.lua for the demo — is returned to the requester. The status code is 200 OK, so caches and logs may persist the disclosure further.

Root cause 4 — call sites that reach `PrettyError` are exercised by ordinary, attacker-influenceable inputs

// engine/handlers.go (Lua handler with debugMode):
if ac.debugMode {
    ...
    if err := ac.RunLua(recorder, req, filename, flushFunc, httpStatus); err != nil {
        errortext := err.Error()
        fileblock, err := ac.cache.Read(filename, ac.shouldCache(ext))
        if err != nil {
            fileblock = datablock.NewDataBlock([]byte(err.Error()), true)
        }
        ac.PrettyError(w, req, filename, fileblock.Bytes(), errortext, "lua")
    }
}

And in PongoHandler (engine/handlers.go:81-92):

if err != nil {
    if ac.debugMode {
        luablock, luablockErr := ac.cache.Read(luafilename, ac.shouldCache(ext))
        if luablockErr != nil {
            luablock = datablock.EmptyDataBlock
        }
        ac.PrettyError(w, req, luafilename, luablock.Bytes(), err.Error(), "lua")
    }
    ...
}

The Pongo2/Amber call sites do the same for their template languages. To trigger a Lua error, an attacker needs to push the script onto a code path the developer did not test:

Send a GET to an endpoint the script handles only on POST — most handle() implementations index req fields that crash on the wrong method.
Submit a parameter the script tonumber()s, with a value like "abc" — tonumber returns nil, and the subsequent arithmetic raises attempt to perform arithmetic on a nil value.
Send a request with no Cookie header to a script that calls userstate:Username(req) and indexes the result — the resulting nil-index error returns the source.
For Pongo2: send a query parameter that is referenced in a filter where the filter argument is the wrong type ({{ foo|length }} where foo is the int the script just read from req).

These are not exotic conditions; they are first-five-minutes-of-fuzzing behaviour.

PoC

Variant A — `.lua` single-file invocation does not reach `PrettyError`

Important constraint discovered during live verification: a single-file .lua invocation is routed through RunConfiguration, which registers handle() routes via engine/luahandler.go:38-58. Errors inside a handle()-registered Lua function are caught by poolL.PCall and reported through logrus.Error("Handler for "+handlePath+" failed:", err) only — they do not reach PrettyError, so a handle("/", function() error("oops") end) script does not disclose its source on the wire. The forced debugMode = true is still active for the process, and any other code path that calls PrettyError (Pongo2/Amber/Lua-file-served-from-disk) will disclose; the bare .lua single-file case alone does not. The advisory below has been narrowed accordingly — the operational exploit path is Variant B.

Variant B — `.po2` single-file invocation, template-side trigger

page.po2:

{# Demonstrate template error disclosure under singleFileMode #}
<h1>Hello {{ user.name }}</h1>
<p>Internal token: {{ admin_token }}</p>

data.lua (sibling, picked up automatically by PongoHandler at engine/handlers.go:64-93):

admin_token = "AKIA-FAKE-DEMO-AAAAAAAAAA/SECRET=demoSecretBYTES"
user = nil   -- forces {{ user.name }} to raise

algernon page.po2 &
curl -s 'http://localhost:3000/'
# => "Lua Error" page citing /home/op/data.lua, source inlined,
#    `admin_token = "..."` visible to the unauthenticated requester.

Note the disclosed file is data.lua, not the template — Pongo's variable resolution drops into Lua2funcMap, raises, and PongoHandler calls PrettyError(w, req, luafilename, luablock.Bytes(), err.Error(), "lua"). The "single-file" invocation was for page.po2, but the disclosed file is the sibling data.lua that contains the actual credentials.

Variant C — `--prod` does not block this for non-`.lua` extensions

algernon --prod page.po2 &
curl -s 'http://localhost:3000/'
# => Same disclosure. --prod sets productionMode=true and
#    finalConfiguration would normally clamp debugMode back to false,
#    but for .po2 the singleFileMode → debugMode=true write happens at
#    line 499 of engine/config.go, and singleFileMode stays true (no
#    follow-up reset), so the engine treats this as a debug-on
#    single-file deployment regardless of --prod.

The mismatch between operator intent (--prod) and runtime state (debugMode=true) is the core severity multiplier here. The flag should win; today, file-extension detection wins.

Impact

Confidentiality: high. Disclosure of server-side script source. In single-file demos, the disclosed file is typically the entire application — every secret, every credential, every business rule. In --prod deployments where an operator stitched together serverconf.lua + a single app.lua, the disclosed file is app.lua plus any data.lua consulted during the failing request.
Integrity: none directly.
Availability: none directly.

Affected population:

Every developer running algernon foo.lua / algernon page.po2 for a demo, evaluation, or local dev — the documented quickstart workflow.
Every operator running Algernon as a system service whose ExecStart references a single Lua/Pongo/Amber file (a common pattern given that the binary is positioned as "drop-in, single-file deploy").
Every CI test job that exercises Algernon in single-file mode against attacker-controlled HTTP input (fuzz harnesses, integration tests with adversarial payloads).

Suggestions to fix

Primary fix — flip the default. singleFileMode should not force debugMode on; it should default it on only when --debug/-d was passed explicitly.

// engine/config.go:498-502  -- replace
if ac.singleFileMode {
    // Single-file mode is a convenience for quick demos. It should
    // imply the relaxed serving model (no HTTPS, etc) but it must NOT
    // override the operator's debug/production stance.
    ac.serveJustHTTP = true
    // (do not touch ac.debugMode)
}

If the developer wants the helpful error pages for the quickstart, they can pass -d (which is documented and explicit). The current behaviour is a hidden side-channel of file-extension detection.

Secondary fix — let --prod win unconditionally. Hoist the production-mode clamp above the single-file detection block, so production deployments cannot have debug re-enabled by any later code path:

// engine/config.go -- early in MustServe, before single-file detection runs
if ac.productionMode {
    ac.debugMode = false
}
// ... single-file detection still runs but its debugMode assignment is now gated:
if ac.singleFileMode && !ac.productionMode {
    ac.debugMode = true
}

A --prod invocation that also asks for debug should be treated as a configuration error and refused at startup with a clear log line, not silently resolved in one direction or the other.

Defence in depth — narrow what PrettyError discloses even when debugMode is on.

Truncate Filename to its basename (filepath.Base) so the absolute disk path of the script is not leaked; the file name alone is enough for the developer to find the file in their editor.
Cap Code to ±20 lines around linenr; the developer rarely needs the full file to fix the error, and the cap meaningfully reduces secret leak when the file is large.
Set Cache-Control: no-store on the response so intermediate caches and browser back-buttons do not retain it.
Optionally, gate PrettyError behind a loopback / 127.0.0.1-only check when debugMode is on. A developer hitting localhost:3000 still gets the friendly error page; a remote client gets a generic 500. This matches the convention used by Rails' consider_all_requests_local and Django's DEBUG = True.

Documentation fix. TUTORIAL.md and the README should call out the behaviour explicitly: "algernon foo.lua enables debug-mode features that disclose your script's source on errors. Do not use single-file mode to serve real workloads; use algernon --prod /srv/algernon against a directory." Pair the doc fix with one of the code fixes above — docs alone are not enough.

Live verification (2026-05-11, Algernon 1.17.6)

Reproduced against a fresh go build of xyproto/algernon@main on Windows 10.

Setup (Variant B — .po2 single-file):

poc4c/
  page.po2        # contains {{ user.name }} and {{ admin_token }}
  data.lua        # contains: local SECRET = "sk-LEAKCANARY-DATALUA-PRIVATE"
                  #           this is intentionally bad lua    <-- parse error

Run (no --debug, no --server, no extra hardening):

$ ./algernon.exe --nodb --httponly --addr 127.0.0.1:18777 --quiet poc4c/page.po2 </dev/null &
$ curl -s -o po2b.html -w "HTTP %{http_code}  bytes %{size_download}\n" http://127.0.0.1:18777/
HTTP 200  bytes 1013

Response body (excerpt — entire file is the PrettyError page):

<title>Lua Error</title>
...
<div style="font-size: 3em; font-weight: bold;">Lua Error</div>
Contents of poc-test\poc4c\data.lua:
<div>
  <pre><code>local SECRET = "sk-LEAKCANARY-DATALUA-PRIVATE"
<font style='color: red !important'>this is intentionally bad lua</font>
</code></pre>
</div>
Error message:
<div>
  <pre id="wrap"><code style="color: #A00000;">&lt;string&gt; line:2(column:7) near 'is':   parse error</code></pre>
</div>

The SECRET from data.lua is rendered into the HTML response body of an unauthenticated GET /. No flag was passed to enable debug. The Contents of poc-test\poc4c\data.lua: line confirms the engine intended this as the verbose debug response, gated on ac.debugMode == true.

Baseline comparison — same files served in directory mode:

poc4c-dir/
  page.po2
  data.lua        # same broken file

$ ./algernon.exe --nodb --httponly --server --addr 127.0.0.1:18778 --quiet poc4c-dir </dev/null &
$ curl -s -o po2c.html -w "dir-mode: HTTP %{http_code}  bytes %{size_download}\n" http://127.0.0.1:18778/page.po2
dir-mode: HTTP 200  bytes 0

Empty body. The Lua parse error is logged but the source is not disclosed to the client. The difference between "leaks data.lua source verbatim" and "logs internally" is exactly the forced debugMode = true from singleFileMode.

Variant A — .lua single-file does NOT trigger this code path. Verified separately: a single-file Lua script that registers handle("/", function() error("…") end) returned HTTP 200 with 0-byte body when triggered. The error was visible only in the server-process log via logrus.Error("Handler for / failed: …"). PrettyError is unreachable from handle()-registered errors; see engine/luahandler.go:38-58. The Variant A scenario was dropped from the advisory.

Why .po2 doesn't get the .lua reset. The reset to singleFileMode = false at engine/config.go:547 only fires for filepath.Ext(...) == ".lua". For .po2 (and .amber, .html, .tmpl, .tl, .pongo2) the reset never runs, the forced debugMode = true persists, and PongoHandler's call to PrettyError on data-file errors disclose the source.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.17.6"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/xyproto/algernon"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.17.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45728"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-209",
      "CWE-489",
      "CWE-540"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-19T14:35:51Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nWhen Algernon is invoked with a single file path instead of a directory \u2014 the documented \"quick demo\" workflow (`algernon foo.lua`, `algernon page.po2`, `algernon index.html`, `algernon mywebsite.alg`) \u2014 `singleFileMode` is set to true and **`debugMode` is forcibly enabled** with no opt-out:\n\n```go\n// engine/config.go:498-502\n// Make a few changes to the defaults if we are serving a single file\nif ac.singleFileMode {\n    ac.debugMode = true\n    ac.serveJustHTTP = true\n}\n```\n\n`debugMode` activates the `PrettyError` renderer, which on any Lua or template error response dumps:\n\n1. The **absolute path** of the file that errored (`Filename` field of the error template).\n2. The **complete byte contents** of that file, HTML-escaped, with the offending line wrapped in `\u003cfont style=\u0027color: red !important\u0027\u003e\u2026\u003c/font\u003e`.\n3. The exception or parser error text \u2014 which in turn often quotes additional file content (Pongo2 errors include surrounding template lines; Lua tracebacks include argument values).\n\nThis 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 single-file invocations entirely. Any client able to reach the server and able to provoke a runtime error in the served script obtains the full server-side source of that script and of any sibling Lua data file consulted during the request.\n\nThis combines particularly badly with `--prod` *not* being effective: `--prod` sets `productionMode = true` and calls `ac.debugMode = false` inside `finalConfiguration`, but `singleFileMode` is computed *after* `--prod` in `MustServe` (line 499 vs `finalConfiguration` further down) and the forced `debugMode = true` happens before `--prod`\u0027s `debugMode = false` clamp runs \u2014 so even an operator who reasoned \"I will pass `--prod` to be safe\" gets debug-mode-on if they also pass a single Lua file. Operators routinely combine the two when running Algernon as a system unit (`ExecStart=algernon --prod /etc/algernon/site.lua`), unaware that single-file detection has overridden their hardening flag.\n\n### Details\n\n#### Root cause 1 \u2014 single-file detection forces `debugMode = true`\n\n```go\n// engine/config.go:441-502  (inside MustServe \u2014 abridged)\nswitch strings.ToLower(filepath.Ext(serverFile)) {\ncase \".md\", \".markdown\":\n    ...\ncase \".zip\", \".alg\":\n    ...\ndefault:\n    ac.singleFileMode = true\n}\n// ...\n// Make a few changes to the defaults if we are serving a single file\nif ac.singleFileMode {\n    ac.debugMode = true\n    ac.serveJustHTTP = true\n}\n```\n\nAny single-file invocation whose extension is *not* `.md`/`.zip`/`.alg` lands in the `default:` branch and turns into `singleFileMode = true`, which then sets `debugMode = true`. That includes the natural quickstart inputs \u2014 `.lua`, `.po2`, `.pongo2`, `.html`, `.amber`, `.tmpl`, `.jsx`, `.tl`, `.prompt` \u2014 every file extension Algernon recognises as a server-renderable handler.\n\nThe `.lua` case has a follow-up at [engine/config.go:536-548](../engine/config.go) that resets `singleFileMode = false` so the script can read sibling files, but `debugMode` has already been written to `true` and is not unset.\n\n#### Root cause 2 \u2014 `--prod`\u0027s clamp runs *after* the forced enable, so it is the wrong direction\n\n```go\n// engine/config.go:393-397  (finalConfiguration, called from MustServe)\n// Turn off debug mode if production mode is enabled\nif ac.productionMode {\n    // Turn off debug mode\n    ac.debugMode = false\n}\n```\n\nThis clamp is in `finalConfiguration`. `finalConfiguration` is invoked from `MustServe` *after* the single-file block (`MustServe` line 632: `ac.finalConfiguration(ac.serverHost)`). So the order is:\n\n```\n1. flag parsing       -\u003e productionMode=true, debugMode=false\n2. single-file detect -\u003e debugMode = true     (overrides production)\n3. finalConfiguration -\u003e if productionMode { debugMode = false }\n```\n\nOn paper step 3 wins. In practice the operator-controlled execution path through `MustServe` for `.lua` files is:\n\n```\n1. flag parsing                                            -\u003e productionMode=true, debugMode=false\n2. single-file detect (line 493 default branch)            -\u003e singleFileMode = true\n3. if singleFileMode { debugMode = true } (line 499)       -\u003e debugMode = true\n4. if singleFileMode \u0026\u0026 ext==\".lua\" { singleFileMode = false; serverDir = Dir(...) }\n5. ac.RunConfiguration(luaServerFilename, mux, true)       -\u003e Lua server-conf script runs, may register handlers\n6. ac.finalConfiguration(host)                              -\u003e if productionMode { debugMode = false }   \u2190 clamp restored\n```\n\nStep 5 happens *between* the forced enable and the production clamp, and inside the configuration script Lua code may already check or expose `debugMode` (the `debug()` global is wired in [engine/serverconf.go]). Anything that latches on `debugMode` during step 5 \u2014 including `RegisterHandlers` itself when called from within the server-conf script \u2014 picks up the wrong value. The clamp at step 6 may or may not retroactively fix downstream behaviour; for `PrettyError`, which reads `ac.debugMode` at request-time, the clamp does win for `.lua` single-file mode \u2014 but only because of the late ordering inside `MustServe`. For the other single-file extensions (`.po2`, `.html`, `.amber`, \u2026), step 4\u0027s reset does not run, `singleFileMode` stays true, and `--prod` collides with `singleFileMode` semantically (a \"single file\" cannot meaningfully be a production system service). The forced `debugMode = true` survives because no later code branches re-clamp it for non-`.lua` paths.\n\nEmpirically: `algernon --prod foo.po2` (or `.amber`, `.tmpl`) on a stock Algernon binary serves `PrettyError`-style debug responses on template failures. `--prod` does not save the operator.\n\n#### Root cause 3 \u2014 `PrettyError` discloses absolute path + full source\n\n```go\n// engine/prettyerror.go:82-147  (abridged)\nfunc (ac *Config) PrettyError(w http.ResponseWriter, req *http.Request, filename string, filebytes []byte, errormessage, lang string) {\n    w.WriteHeader(http.StatusOK)\n    w.Header().Add(contentType, htmlUTF8)\n    // ... linenr parsing elided ...\n    filebytes = bytes.ReplaceAll(filebytes, []byte(\"\u003c\"), []byte(\"\u0026lt;\"))\n    bytelines := bytes.Split(filebytes, []byte(\"\\n\"))\n    if (linenr \u003e= 0) \u0026\u0026 (linenr \u003c len(bytelines)) {\n        bytelines[linenr] = []byte(preHighlight + string(bytelines[linenr]) + postHighlight)\n    }\n    code = string(bytes.Join(bytelines, []byte(\"\\n\")))\n    title := errorPageTitle(lang)\n    data := struct {\n        Title         string\n        Filename      string\n        Code          string\n        ErrorMessage  string\n        VersionString string\n    }{\n        Title:         title,\n        Filename:      filename,        // absolute path on disk\n        Code:          code,            // entire file\n        ErrorMessage:  strings.TrimSpace(errormessage),\n        VersionString: ac.versionString,\n    }\n    ...\n}\n```\n\nThe HTML template at the top of the file embeds those fields directly:\n\n```html\nContents of {{.Filename}}:\n\u003cdiv\u003e\n  \u003cpre\u003e\u003ccode\u003e{{.Code}}\u003c/code\u003e\u003c/pre\u003e\n\u003c/div\u003e\nError message:\n\u003cdiv\u003e\n  \u003cpre id=\"wrap\"\u003e\u003ccode style=\"color: #A00000;\"\u003e{{.ErrorMessage}}\u003c/code\u003e\u003c/pre\u003e\n\u003c/div\u003e\n```\n\nEvery byte of the script \u2014 including any DB connection string, API key, JWT signing secret, S3 access key, or hard-coded admin credential the operator left in `index.lua` for the demo \u2014 is returned to the requester. The status code is `200 OK`, so caches and logs may persist the disclosure further.\n\n#### Root cause 4 \u2014 call sites that reach `PrettyError` are exercised by ordinary, attacker-influenceable inputs\n\n```go\n// engine/handlers.go (Lua handler with debugMode):\nif ac.debugMode {\n    ...\n    if err := ac.RunLua(recorder, req, filename, flushFunc, httpStatus); err != nil {\n        errortext := err.Error()\n        fileblock, err := ac.cache.Read(filename, ac.shouldCache(ext))\n        if err != nil {\n            fileblock = datablock.NewDataBlock([]byte(err.Error()), true)\n        }\n        ac.PrettyError(w, req, filename, fileblock.Bytes(), errortext, \"lua\")\n    }\n}\n```\n\nAnd in `PongoHandler` ([engine/handlers.go:81-92](../engine/handlers.go)):\n\n```go\nif err != nil {\n    if ac.debugMode {\n        luablock, luablockErr := ac.cache.Read(luafilename, ac.shouldCache(ext))\n        if luablockErr != nil {\n            luablock = datablock.EmptyDataBlock\n        }\n        ac.PrettyError(w, req, luafilename, luablock.Bytes(), err.Error(), \"lua\")\n    }\n    ...\n}\n```\n\nThe Pongo2/Amber call sites do the same for their template languages. To trigger a Lua error, an attacker needs to push the script onto a code path the developer did not test:\n\n- Send a `GET` to an endpoint the script handles only on `POST` \u2014 most `handle()` implementations index `req` fields that crash on the wrong method.\n- Submit a parameter the script `tonumber()`s, with a value like `\"abc\"` \u2014 `tonumber` returns `nil`, and the subsequent arithmetic raises `attempt to perform arithmetic on a nil value`.\n- Send a request with no `Cookie` header to a script that calls `userstate:Username(req)` and indexes the result \u2014 the resulting nil-index error returns the source.\n- For Pongo2: send a query parameter that is referenced in a filter where the filter argument is the wrong type (`{{ foo|length }}` where `foo` is the int the script just read from `req`).\n\nThese are not exotic conditions; they are first-five-minutes-of-fuzzing behaviour.\n\n### PoC\n\n#### Variant A \u2014 `.lua` single-file invocation **does not reach `PrettyError`**\n\nImportant constraint discovered during live verification: a single-file `.lua` invocation is routed through `RunConfiguration`, which registers `handle()` routes via [engine/luahandler.go:38-58](../engine/luahandler.go). Errors inside a `handle()`-registered Lua function are caught by `poolL.PCall` and reported through `logrus.Error(\"Handler for \"+handlePath+\" failed:\", err)` only \u2014 they do **not** reach `PrettyError`, so a `handle(\"/\", function() error(\"oops\") end)` script does not disclose its source on the wire. The forced `debugMode = true` is still active for the process, and any *other* code path that calls `PrettyError` (Pongo2/Amber/Lua-file-served-from-disk) will disclose; the bare `.lua` single-file case alone does not. The advisory below has been narrowed accordingly \u2014 the operational exploit path is Variant B.\n\n#### Variant B \u2014 `.po2` single-file invocation, template-side trigger\n\n`page.po2`:\n\n```html\n{# Demonstrate template error disclosure under singleFileMode #}\n\u003ch1\u003eHello {{ user.name }}\u003c/h1\u003e\n\u003cp\u003eInternal token: {{ admin_token }}\u003c/p\u003e\n```\n\n`data.lua` (sibling, picked up automatically by `PongoHandler` at [engine/handlers.go:64-93](../engine/handlers.go)):\n\n```lua\nadmin_token = \"AKIA-FAKE-DEMO-AAAAAAAAAA/SECRET=demoSecretBYTES\"\nuser = nil   -- forces {{ user.name }} to raise\n```\n\n```bash\nalgernon page.po2 \u0026\ncurl -s \u0027http://localhost:3000/\u0027\n# =\u003e \"Lua Error\" page citing /home/op/data.lua, source inlined,\n#    `admin_token = \"...\"` visible to the unauthenticated requester.\n```\n\nNote the disclosed file is `data.lua`, not the template \u2014 Pongo\u0027s variable resolution drops into `Lua2funcMap`, raises, and `PongoHandler` calls `PrettyError(w, req, luafilename, luablock.Bytes(), err.Error(), \"lua\")`. The \"single-file\" invocation was for `page.po2`, but the *disclosed* file is the sibling `data.lua` that contains the actual credentials.\n\n#### Variant C \u2014 `--prod` does not block this for non-`.lua` extensions\n\n```bash\nalgernon --prod page.po2 \u0026\ncurl -s \u0027http://localhost:3000/\u0027\n# =\u003e Same disclosure. --prod sets productionMode=true and\n#    finalConfiguration would normally clamp debugMode back to false,\n#    but for .po2 the singleFileMode \u2192 debugMode=true write happens at\n#    line 499 of engine/config.go, and singleFileMode stays true (no\n#    follow-up reset), so the engine treats this as a debug-on\n#    single-file deployment regardless of --prod.\n```\n\nThe mismatch between operator intent (`--prod`) and runtime state (`debugMode=true`) is the core severity multiplier here. The flag should win; today, file-extension detection wins.\n\n### Impact\n\n- **Confidentiality:** high. Disclosure of server-side script source. In single-file demos, the disclosed file is typically the *entire* application \u2014 every secret, every credential, every business rule. In `--prod` deployments where an operator stitched together `serverconf.lua` + a single `app.lua`, the disclosed file is `app.lua` plus any `data.lua` consulted during the failing request.\n- **Integrity:** none directly.\n- **Availability:** none directly.\n\n**Affected population:**\n\n- Every developer running `algernon foo.lua` / `algernon page.po2` for a demo, evaluation, or local dev \u2014 the documented quickstart workflow.\n- Every operator running Algernon as a system service whose `ExecStart` references a single Lua/Pongo/Amber file (a common pattern given that the binary is positioned as \"drop-in, single-file deploy\").\n- Every CI test job that exercises Algernon in single-file mode against attacker-controlled HTTP input (fuzz harnesses, integration tests with adversarial payloads).\n\n### Suggestions to fix\n\n**Primary fix \u2014 flip the default. `singleFileMode` should *not* force `debugMode` on; it should default it on only when `--debug`/`-d` was passed explicitly.**\n\n```go\n// engine/config.go:498-502  -- replace\nif ac.singleFileMode {\n    // Single-file mode is a convenience for quick demos. It should\n    // imply the relaxed serving model (no HTTPS, etc) but it must NOT\n    // override the operator\u0027s debug/production stance.\n    ac.serveJustHTTP = true\n    // (do not touch ac.debugMode)\n}\n```\n\nIf the developer wants the helpful error pages for the quickstart, they can pass `-d` (which is documented and explicit). The current behaviour is a hidden side-channel of file-extension detection.\n\n**Secondary fix \u2014 let `--prod` win unconditionally.** Hoist the production-mode clamp above the single-file detection block, so production deployments cannot have debug re-enabled by any later code path:\n\n```go\n// engine/config.go -- early in MustServe, before single-file detection runs\nif ac.productionMode {\n    ac.debugMode = false\n}\n// ... single-file detection still runs but its debugMode assignment is now gated:\nif ac.singleFileMode \u0026\u0026 !ac.productionMode {\n    ac.debugMode = true\n}\n```\n\nA `--prod` invocation that *also* asks for debug should be treated as a configuration error and refused at startup with a clear log line, not silently resolved in one direction or the other.\n\n**Defence in depth \u2014 narrow what `PrettyError` discloses even when debugMode is on.**\n\n- Truncate `Filename` to its basename (`filepath.Base`) so the absolute disk path of the script is not leaked; the file name alone is enough for the developer to find the file in their editor.\n- Cap `Code` to \u00b120 lines around `linenr`; the developer rarely needs the full file to fix the error, and the cap meaningfully reduces secret leak when the file is large.\n- Set `Cache-Control: no-store` on the response so intermediate caches and browser back-buttons do not retain it.\n- Optionally, gate `PrettyError` behind a loopback / `127.0.0.1`-only check when `debugMode` is on. A developer hitting `localhost:3000` still gets the friendly error page; a remote client gets a generic 500. This matches the convention used by Rails\u0027 `consider_all_requests_local` and Django\u0027s `DEBUG = True`.\n\n**Documentation fix.** `TUTORIAL.md` and the README should call out the behaviour explicitly: \"`algernon foo.lua` enables debug-mode features that disclose your script\u0027s source on errors. Do not use single-file mode to serve real workloads; use `algernon --prod /srv/algernon` against a directory.\" Pair the doc fix with one of the code fixes above \u2014 docs alone are not enough.\n\n### Live verification (2026-05-11, Algernon 1.17.6)\n\nReproduced against a fresh `go build` of `xyproto/algernon@main` on Windows 10.\n\n**Setup (Variant B \u2014 `.po2` single-file):**\n\n```\npoc4c/\n  page.po2        # contains {{ user.name }} and {{ admin_token }}\n  data.lua        # contains: local SECRET = \"sk-LEAKCANARY-DATALUA-PRIVATE\"\n                  #           this is intentionally bad lua    \u003c-- parse error\n```\n\n**Run (no `--debug`, no `--server`, no extra hardening):**\n\n```\n$ ./algernon.exe --nodb --httponly --addr 127.0.0.1:18777 --quiet poc4c/page.po2 \u003c/dev/null \u0026\n$ curl -s -o po2b.html -w \"HTTP %{http_code}  bytes %{size_download}\\n\" http://127.0.0.1:18777/\nHTTP 200  bytes 1013\n```\n\n**Response body (excerpt \u2014 entire file is the PrettyError page):**\n\n```html\n\u003ctitle\u003eLua Error\u003c/title\u003e\n...\n\u003cdiv style=\"font-size: 3em; font-weight: bold;\"\u003eLua Error\u003c/div\u003e\nContents of poc-test\\poc4c\\data.lua:\n\u003cdiv\u003e\n  \u003cpre\u003e\u003ccode\u003elocal SECRET = \"sk-LEAKCANARY-DATALUA-PRIVATE\"\n\u003cfont style=\u0027color: red !important\u0027\u003ethis is intentionally bad lua\u003c/font\u003e\n\u003c/code\u003e\u003c/pre\u003e\n\u003c/div\u003e\nError message:\n\u003cdiv\u003e\n  \u003cpre id=\"wrap\"\u003e\u003ccode style=\"color: #A00000;\"\u003e\u0026lt;string\u0026gt; line:2(column:7) near \u0027is\u0027:   parse error\u003c/code\u003e\u003c/pre\u003e\n\u003c/div\u003e\n```\n\nThe `SECRET` from `data.lua` is rendered into the HTML response body of an unauthenticated `GET /`. No flag was passed to enable debug. The `Contents of poc-test\\poc4c\\data.lua:` line confirms the engine intended this as the verbose debug response, gated on `ac.debugMode == true`.\n\n**Baseline comparison \u2014 same files served in directory mode:**\n\n```\npoc4c-dir/\n  page.po2\n  data.lua        # same broken file\n\n$ ./algernon.exe --nodb --httponly --server --addr 127.0.0.1:18778 --quiet poc4c-dir \u003c/dev/null \u0026\n$ curl -s -o po2c.html -w \"dir-mode: HTTP %{http_code}  bytes %{size_download}\\n\" http://127.0.0.1:18778/page.po2\ndir-mode: HTTP 200  bytes 0\n```\n\nEmpty body. The Lua parse error is logged but the source is not disclosed to the client. The difference between \"leaks `data.lua` source verbatim\" and \"logs internally\" is exactly the forced `debugMode = true` from `singleFileMode`.\n\n**Variant A \u2014 `.lua` single-file does NOT trigger this code path.** Verified separately: a single-file Lua script that registers `handle(\"/\", function() error(\"\u2026\") end)` returned `HTTP 200` with 0-byte body when triggered. The error was visible only in the server-process log via `logrus.Error(\"Handler for / failed: \u2026\")`. `PrettyError` is unreachable from `handle()`-registered errors; see `engine/luahandler.go:38-58`. The Variant A scenario was dropped from the advisory.\n\n**Why `.po2` doesn\u0027t get the `.lua` reset.** The reset to `singleFileMode = false` at [engine/config.go:547](../engine/config.go) only fires for `filepath.Ext(...) == \".lua\"`. For `.po2` (and `.amber`, `.html`, `.tmpl`, `.tl`, `.pongo2`) the reset never runs, the forced `debugMode = true` persists, and `PongoHandler`\u0027s call to `PrettyError` on data-file errors disclose the source.",
  "id": "GHSA-fwqx-8365-9983",
  "modified": "2026-05-19T14:35:51Z",
  "published": "2026-05-19T14:35:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xyproto/algernon/security/advisories/GHSA-fwqx-8365-9983"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xyproto/algernon"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Algernon: Single-file mode unconditionally enables debug mode"
}

CVE-2026-45728 (GCVE-0-2026-45728)

Vulnerability from cvelistv5 – Published: 2026-05-26 16:38 – Updated: 2026-05-26 17:31

Title

Algernon: Single-file mode unconditionally enables debug mode

Summary

Algernon is a small self-contained pure-Go web server. Prior to 1.17.7, when Algernon is invoked with a single file path instead of a directory, singleFileMode is set to true and debugMode is forcibly enabled. debugMode activates the PrettyError renderer, which on any Lua or template error response dumps the absolute path of the file that errored, complete byte contents of that file, and exception or parser error text. This response is served with HTTP 200 OK to whoever sent the request that triggered the error. Any client able to reach the server and able to provoke a runtime error in the served script obtains the full server-side source of that script and of any sibling Lua data file consulted during the request. This vulnerability is fixed in 1.17.7.

Severity

7.5 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

CWE

CWE-209 - Generation of Error Message Containing Sensitive Information
CWE-489 - Active Debug Code
CWE-540 - Inclusion of Sensitive Information in Source Code
CWE-1188 - Insecure Default Initialization of Resource

Assigner

GitHub_M

References

1 reference

URL	Tags
https://github.com/xyproto/algernon/security/advi…	x_refsource_CONFIRM

Impacted products

1 product

Vendor	Product	Version
xyproto	algernon	Affected: < 1.17.7

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-45728",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-05-26T17:31:16.231606Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-05-26T17:31:40.280Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/xyproto/algernon/security/advisories/GHSA-fwqx-8365-9983"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "algernon",
          "vendor": "xyproto",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.17.7"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Algernon is a small self-contained pure-Go web server. Prior to 1.17.7, when Algernon is invoked with a single file path instead of a directory, singleFileMode is set to true and debugMode is forcibly enabled. debugMode activates the PrettyError renderer, which on any Lua or template error response dumps the absolute path of the file that errored, complete byte contents of that file, and exception or parser error text. This response is served with HTTP 200 OK to whoever sent the request that triggered the error. Any client able to reach the server and able to provoke a runtime error in the served script obtains the full server-side source of that script and of any sibling Lua data file consulted during the request. This vulnerability is fixed in 1.17.7."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-209",
              "description": "CWE-209: Generation of Error Message Containing Sensitive Information",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-489",
              "description": "CWE-489: Active Debug Code",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-540",
              "description": "CWE-540: Inclusion of Sensitive Information in Source Code",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-1188",
              "description": "CWE-1188: Insecure Default Initialization of Resource",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-26T16:38:50.435Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/xyproto/algernon/security/advisories/GHSA-fwqx-8365-9983",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/xyproto/algernon/security/advisories/GHSA-fwqx-8365-9983"
        }
      ],
      "source": {
        "advisory": "GHSA-fwqx-8365-9983",
        "discovery": "UNKNOWN"
      },
      "title": "Algernon: Single-file mode unconditionally enables debug mode"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-45728",
    "datePublished": "2026-05-26T16:38:50.435Z",
    "dateReserved": "2026-05-13T05:51:48.667Z",
    "dateUpdated": "2026-05-26T17:31:40.280Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

GHSA-FWQX-8365-9983

Summary

Details

Root cause 1 — single-file detection forces debugMode = true

Root cause 2 — --prod's clamp runs after the forced enable, so it is the wrong direction

Root cause 3 — PrettyError discloses absolute path + full source

Root cause 4 — call sites that reach PrettyError are exercised by ordinary, attacker-influenceable inputs

PoC

Variant A — .lua single-file invocation does not reach PrettyError

Variant B — .po2 single-file invocation, template-side trigger

Variant C — --prod does not block this for non-.lua extensions

Impact

Suggestions to fix

Live verification (2026-05-11, Algernon 1.17.6)

CVE-2026-45728 (GCVE-0-2026-45728)

Tags

Sightings

Nomenclature

Root cause 1 — single-file detection forces `debugMode = true`

Root cause 2 — `--prod`'s clamp runs after the forced enable, so it is the wrong direction

Root cause 3 — `PrettyError` discloses absolute path + full source

Root cause 4 — call sites that reach `PrettyError` are exercised by ordinary, attacker-influenceable inputs

Variant A — `.lua` single-file invocation does not reach `PrettyError`

Variant B — `.po2` single-file invocation, template-side trigger

Variant C — `--prod` does not block this for non-`.lua` extensions