is_https in crates/icaptcha-client/src/lib.rs:98 gates its http-loopback trust relaxation on std::env::var_os("GITLAWB_ICAPTCHA_INSECURE").is_some(), a presence check. An operator who sets GITLAWB_ICAPTCHA_INSECURE=0 or =false intending to disable it still enables the branch: only fully unsetting the variable disables it. Verified against a standalone build: =0, =false, and empty all yield is_some() == true; only unset yields false.
The insecure branch is release-reachable (not #[cfg(test)]-gated): is_https is called on the live path from resolve_solver_url (lib.rs:136, :154).
Blast radius is bounded, so this is a low-severity footgun, not an exploit. resolve_solver_url still contains a node-advertised loopback URL by two independent gates: the host-allowlist (allowed(origin_key(a)) at :154, which admits only the default https://icaptcha.gitlawb.com or the operator's configured GITLAWB_ICAPTCHA_URL origin) and the operator-origin key binding (:166, the bearer token is attached only when the resolved origin equals the operator origin). So setting the flag alone has no exploitable effect unless the operator also points GITLAWB_ICAPTCHA_URL at a loopback origin.
Repro: run any cfg(test)-off caller with GITLAWB_ICAPTCHA_INSECURE=0 and observe is_https("http://127.0.0.1") returns true.
Fix direction: parse the value and treat only an explicit truthy set ("1"/"true") as enabled, logging when a non-empty non-truthy value is seen; or drop the runtime env flag entirely in favor of a test/example-only injection seam so nothing insecure ships in the release binary.
Notes: this line is pre-existing main code (commit ad7c2b2, PR #168), not introduced by any open PR. Filing so the value-parse hardening itself has a public tracker; low severity, close if it's not worth pursuing.
is_httpsincrates/icaptcha-client/src/lib.rs:98gates itshttp-loopback trust relaxation onstd::env::var_os("GITLAWB_ICAPTCHA_INSECURE").is_some(), a presence check. An operator who setsGITLAWB_ICAPTCHA_INSECURE=0or=falseintending to disable it still enables the branch: only fully unsetting the variable disables it. Verified against a standalone build:=0,=false, and empty all yieldis_some() == true; only unset yieldsfalse.The insecure branch is release-reachable (not
#[cfg(test)]-gated):is_httpsis called on the live path fromresolve_solver_url(lib.rs:136,:154).Blast radius is bounded, so this is a low-severity footgun, not an exploit.
resolve_solver_urlstill contains a node-advertised loopback URL by two independent gates: the host-allowlist (allowed(origin_key(a))at:154, which admits only the defaulthttps://icaptcha.gitlawb.comor the operator's configuredGITLAWB_ICAPTCHA_URLorigin) and the operator-origin key binding (:166, the bearer token is attached only when the resolved origin equals the operator origin). So setting the flag alone has no exploitable effect unless the operator also pointsGITLAWB_ICAPTCHA_URLat a loopback origin.Repro: run any
cfg(test)-off caller withGITLAWB_ICAPTCHA_INSECURE=0and observeis_https("http://127.0.0.1")returnstrue.Fix direction: parse the value and treat only an explicit truthy set (
"1"/"true") as enabled, logging when a non-empty non-truthy value is seen; or drop the runtime env flag entirely in favor of a test/example-only injection seam so nothing insecure ships in the release binary.Notes: this line is pre-existing
maincode (commitad7c2b2, PR #168), not introduced by any open PR. Filing so the value-parse hardening itself has a public tracker; low severity, close if it's not worth pursuing.