https://werc.cat-v.org/ is advertised to be "A sane web anti-framework" but in reality it's a shell-powered monstrosity. A simple GPT 5.5 security pass found a lot of shit, but the most critical:
1) If a default-install werc with _debug is hosted behind Apache (maybe Nginx/others too), _debug will expose a lot of env vars of werc. The issue is that werc's user auth path dumps the wrong password into one of the env vars (remember, it's all in shell after all), so if a werc-powered website uses Apache and has _debug, if you know the admin login you can get their password by simply doing
curl -sS -X POST https://host.com/_debug --data-urlencode 'user_name=admin' --data-urlencode 'user_password=wrong' | rg "Pass wrong"
You'll get something like:
_status=Notloggedin:Auth: Pass wrong doesnt match correctpassword
(Tested on a real werc-powered website, works)
2) Related to the 1st one, this time if the host is a Linux distro with PAM. You see, that auth thing has arbitrary path traversal in the username, but auth always works against the filename "password", so it's not useful for random files. But on modern Linux distros there's /var/lib/pam/password, and the first line is "Module: unix" (werc's auth splits by colon) so if you do something like
user_name=..%2F..%2F..%2F..%2F..%2Fvar%2Flib%2Fpam&user_password=unix
(the amount of ../ depends on the actual setup)
you will get authorized, and depending on perms could write wiki pages or comments.
3) Path traversal if rc-httpd is used, although seems like most hosts are mitigated (separate user, I guess?). It doesn't escape things like %2e%2e/%2e%2e
