https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 18:01:56 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-369639 EUVD-2026-369639 https://cve.radiocsirt.org/vuln/euvd-2026-369639 https://cve.radiocsirt.org/vuln/fkie_cve-2026-59157 <p>webhookd is a minimalist webhook server that triggers shell scripts and external processes through HTTP requests. Prior to 1.22.0, webhookd deployments without htpasswd authentication forwarded all incoming HTTP headers through HTTPParamsToShellVars in pkg/api/index.go into the hook script environment without an allowlist. When an upstream reverse proxy did not strip a client-supplied X-WebAuthn-User header and a hook script trusted that variable for identity or privilege, a remote unauthenticated attacker could spoof another user, bypass script security controls, and access or modify resources available to the impersonated identity. This issue is fixed in version 1.22.0.</p> <p>webhookd is a minimalist webhook server that triggers shell scripts and external processes through HTTP requests. Prior to 1.22.0, webhookd deployments without htpasswd authentication forwarded all incoming HTTP headers through HTTPParamsToShellVars in pkg/api/index.go into the hook script environment without an allowlist. When an upstream reverse proxy did not strip a client-supplied X-WebAuthn-User header and a hook script trusted that variable for identity or privilege, a remote unauthenticated attacker could spoof another user, bypass script security controls, and access or modify resources available to the impersonated identity. This issue is fixed in version 1.22.0.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-59157 https://cve.radiocsirt.org/vuln/ghsa-v25g-mvwr-f5fp <p><strong>Affected:</strong> Go: github.com/ncarlier/webhookd</p> <p>## Description Before 1.22, if the Basic Auth (`htpasswd`) middleware was not configured, all incoming HTTP headers were blindly forwarded to the webhook script execution environment as shell variables. While the Basic Auth middleware correctly strips the authentication header (`X-WebAuthn-User`) from the incoming request before conditionally re-injecting it on successful authentication, disabling Basic Auth left the system vulnerable if deployed behind an unhardened reverse proxy.</p> <p>## Impact If an upstream reverse proxy is not properly hardened to strip client-provided authentication headers, an attacker could manually supply these headers (e.g., `X-WebAuthn-User`). A webhook script relying on this forwarded header for privilege elevation or identity verification could therefore be exploited to bypass security controls and impersonate other users.</p> <p>## Mitigation The `WHD_ALLOWED_UPSTREAM_HEADERS` configuration setting has been introduced to enforce a strict allowlist of HTTP headers that can be converted into shell variables.</p> <p>Additionally, the default behavior has been changed to adhere to the principle of least privilege. It is no longer `*` (allow all). The default allowed headers are now restricted to standard operational headers: `Accept,Content-Type,Content-Length,User-Agent,X-Forwarded-For`</p> <p>Administrators relying on upstream authentication proxies must explicitly add their authentication headers (e.g., `WHD_ALLOWED_UPSTREAM_HEADERS=&#34;Accept,Content-Type,Content-Leng…</p> <p><strong>Affected:</strong> Go: github.com/ncarlier/webhookd</p> <p>## Description Before 1.22, if the Basic Auth (`htpasswd`) middleware was not configured, all incoming HTTP headers were blindly forwarded to the webhook script execution environment as shell variables. While the Basic Auth middleware correctly strips the authentication header (`X-WebAuthn-User`) from the incoming request before conditionally re-injecting it on successful authentication, disabling Basic Auth left the system vulnerable if deployed behind an unhardened reverse proxy.</p> <p>## Impact If an upstream reverse proxy is not properly hardened to strip client-provided authentication headers, an attacker could manually supply these headers (e.g., `X-WebAuthn-User`). A webhook script relying on this forwarded header for privilege elevation or identity verification could therefore be exploited to bypass security controls and impersonate other users.</p> <p>## Mitigation The `WHD_ALLOWED_UPSTREAM_HEADERS` configuration setting has been introduced to enforce a strict allowlist of HTTP headers that can be converted into shell variables.</p> <p>Additionally, the default behavior has been changed to adhere to the principle of least privilege. It is no longer `*` (allow all). The default allowed headers are now restricted to standard operational headers: `Accept,Content-Type,Content-Length,User-Agent,X-Forwarded-For`</p> <p>Administrators relying on upstream authentication proxies must explicitly add their authentication headers (e.g., `WHD_ALLOWED_UPSTREAM_HEADERS=&#34;Accept,Content-Type,Content-Leng…</p> https://cve.radiocsirt.org/vuln/ghsa-v25g-mvwr-f5fp