Skip to content

gl: unencoded path and query segments flow into signed requests #493

Description

@euxaristia

Summary

Several gl request builders interpolate unencoded strings into URL paths and query strings: crates/gl/src/mcp.rs:689-717 (owner/name/tree path segments), :981-991 and crates/gl/src/bounty.rs:221-232 (?status={s} raw, while task_list at mcp.rs:1064-1070 correctly uses urlencoding::encode), crates/gl/src/protect.rs:105, crates/gl/src/repo.rs:654 (label in path), crates/gl/src/peer.rs:258 (peers/{did}/ping, while cmd_resolve at :282 encodes).

Impact

Untrusted values echoed from federated repo metadata or node error fields (resolve_owner, mcp.rs:1251-1258) can traverse to a different node endpoint, and the request is signed with the agent's own RFC 9421 signature (sign_request signs the path it is given), so the node receives a validly signed request for a route the caller never intended. The node still enforces per-route authz, so impact is endpoint confusion plus query injection in the bounty status filter.

Remediation

  1. Percent-encode every path segment and query value at the client builder (mirror the task_list pattern) or validate segments against the same rules the node applies.

Proposed labels: kind:security, crate:gl.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    crate:glgl — the contributor CLIkind:securityVulnerability fix or hardeningsev:mediumDegraded but workaround existssubsystem:apiNode REST API request/response surface

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions