Algernon — CraftedSignal Threat Feedhttps://feed.craftedsignal.io/products/algernon/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioTue, 19 May 2026 14:40:16 +0000Algernon handler.lua Discovery Leads to Remote Code Executionhttps://feed.craftedsignal.io/briefs/2026-05-algernon-rce/Tue, 19 May 2026 14:40:16 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-05-algernon-rce/Algernon is vulnerable to remote code execution due to unbounded upward directory traversal when searching for `handler.lua`, allowing attackers with write access to parent directories to execute arbitrary code.Algernon is susceptible to a critical remote code execution vulnerability. When a URL path resolves to a directory lacking an index file, Algernon’s DirPage function recursively searches parent directories for a handler.lua file. Critically, this search extends beyond the configured server root, creating an opportunity for attackers to inject malicious Lua code. If an attacker can write a handler.lua file to any parent directory of the Algernon server root, that file will be executed with full Algernon API access, including functions like run3(), httpclient, os.execute, and direct database access. This occurs without authentication, as the handler lookup precedes permission checks. This vulnerability impacts any Algernon deployment where a less-trusted principal can write to a parent directory of the server root. The issue was introduced due to an unbounded upward search in the DirPage function, as detailed in the GHSA-xwcr-wm99-g9jc advisory.

Attack Chain

  1. Attacker identifies an Algernon instance and its server root directory.
  2. Attacker gains write access to a parent directory of the server root (e.g., /srv, /tmp, ~/).
  3. Attacker crafts a malicious handler.lua file containing arbitrary code for execution.
  4. Attacker writes the malicious handler.lua file to the chosen parent directory.
  5. Attacker sends an HTTP request to the Algernon server, targeting a directory without an index.* file (e.g., /nope/).
  6. Algernon’s DirPage function initiates an upward directory search for handler.lua.
  7. The search locates the attacker’s malicious handler.lua in a parent directory.
  8. Algernon executes the handler.lua file using a Lua interpreter with full API access, resulting in RCE.

Impact

Successful exploitation of this vulnerability allows attackers to execute arbitrary code on the Algernon server with the privileges of the Algernon process. This can lead to complete compromise of the server, including data theft, modification, or destruction. Multi-tenant environments are especially at risk, as a compromised tenant could inject a handler.lua that affects other tenants. The scope of the impact is changed, as a write primitive against a parent directory crosses into the Algernon process’s authority.

Recommendation

  • Apply the provided patch to clamp the DirPage directory traversal to the server root as described in the GHSA advisory.
  • Implement the boundary check in engine/dirhandler.go to prevent traversal beyond the server root as detailed in the fix suggestions.
  • Deploy the Sigma rule “Detect Algernon handler.lua Discovery” to identify potential exploitation attempts via web server logs.
  • Monitor file creation events in parent directories of Algernon server roots for suspicious handler.lua file creations using the “Detect handler.lua Creation in Parent Directories” rule.
  • Review and remove any unnecessary handler.lua files present in parent directories of Algernon server roots to reduce the attack surface.
]]>criticaladvisoryalgernonrcedirectory-traversal