CVE-2026-52792

This CVE exposes a semantic gap between Go's filepath utilities and Windows NTFS behavior that almost certainly exists in other Go web applications. The mechanism: filepath.Ext('x.lua::$DATA') returns '.lua' because it's a string operation, not a filesystem query. The routing layer sees a .lua extension, selects the Lua handler, and passes the path to OS-native file access — which resolves the alternate data stream alias and returns raw bytes instead of executing the script. The security boundary assumes extension-based routing implies execution semantics; the OS doesn't honor that assumption. The critical analytical distinction is whether the patch validates the resolved path's extension post-OS-access or simply blocklists known ADS suffixes like ::$DATA. Blocklisting is fragile — future NTFS features or edge cases will bypass it. Resolution-time validation is architecturally robust but may require rearchitecting how Algernon makes handler-selection decisions, since the security decision currently happens before file access. More importantly, this vulnerability rewards correct usage of Go's standard library, not developer error. filepath.Ext() behaves exactly as documented. The vulnerability exists in every Go web application on Windows that uses extension-based routing — which is the standard, recommended pattern taught throughout Go's ecosystem. This is not an Algernon bug; it's a systemic mismatch between what Go's path utilities promise and what Windows actually does. Audit any Go web server on Windows that routes based on filepath.Ext() or similar string-based extension checks. The fix in Algernon addresses this instance, but the underlying assumption — that extension strings map to execution semantics — is baked into the Go standard library and the broader ecosystem's best practices.

Reviewed through automated stages and approved by a human before publication.