factory: assert_pair_in_registry on limit-config admin fns (#455) #981

Merged

Brouie merged 1 commit from qa/455-factory-registry-guard into main

2026-06-30 21:56:07 +00:00

Brouie commented

2026-06-30 19:03:29 +00:00

(Migrated from gitlab.com)

Add the registry check to both, immediately after addr_validate, matching
set_pair_fee. Also corrected a wrong doc comment on the batch-max fn (it was the
update_config blurb). No behaviour change for valid governance ops on registered
pairs.

Tests: 3 new (batch-max + clean-config reject unregistered, both accept a
registered pair); factory lib 5/0, full workspace 460/0.

execute_set_pair_limit_batch_max and execute_set_pair_limit_clean_config validated the pair address with addr_validate but skipped assert_pair_in_registry — unlike every other single-pair admin fn (set_pair_fee, set_pair_hooks, set_discount_registry, set_pair_paused, sweep_pair). That let governance dispatch UpdateLimitOrderConfig / UpdateLimitCleanConfig to any valid-but-unregistered address, breaking the uniform registry-guard pattern (SEC-I03 F01). Add the registry check to both, immediately after addr_validate, matching set_pair_fee. Also corrected a wrong doc comment on the batch-max fn (it was the update_config blurb). No behaviour change for valid governance ops on registered pairs. Tests: 3 new (batch-max + clean-config reject unregistered, both accept a registered pair); factory lib 5/0, full workspace 460/0.

Brouie commented

2026-06-30 19:03:29 +00:00

(Migrated from gitlab.com)

assigned to @Brouie

Brouie commented

2026-06-30 19:03:31 +00:00

(Migrated from gitlab.com)

restored source branch qa/455-factory-registry-guard

restored source branch `qa/455-factory-registry-guard`

PlasticDigits commented

2026-06-30 19:06:10 +00:00

(Migrated from gitlab.com)

Security review — MR !981

Commit reviewed: f481b2b4b0ab4565425043b240256ce404f1423e
Scope: smartcontracts/contracts/factory/src/contract.rs — add assert_pair_in_registry to execute_set_pair_limit_batch_max and execute_set_pair_limit_clean_config; registry-guard unit tests (#455 / SEC-I03 F01).

Outcome: FINDINGS: 0 medium+

Summary: This MR closes a permission-boundary gap (factory governance could previously dispatch UpdateLimitOrderConfig / UpdateLimitCleanConfig via WasmMsg::Execute to any addr_validate-passing address, while every other single-pair admin wrapper already required PAIR_ADDR_REGISTERED). The fix mirrors execute_set_pair_fee: ensure_governance → addr_validate → assert_pair_in_registry → submessage. Downstream pair handlers remain factory-sender-gated (info.sender == pair_info.factory); the registry guard prevents the factory acting as a confused deputy toward unregistered targets. No new injection, authz bypass, or caller-controlled sink was introduced in the diff.

Inline threads: none (no medium+ findings).

Security review: no medium+ findings on this diff.

## Security review — MR !981 **Commit reviewed:** `f481b2b4b0ab4565425043b240256ce404f1423e` **Scope:** `smartcontracts/contracts/factory/src/contract.rs` — add `assert_pair_in_registry` to `execute_set_pair_limit_batch_max` and `execute_set_pair_limit_clean_config`; registry-guard unit tests (#455 / SEC-I03 F01). **Outcome:** `FINDINGS: 0` medium+ **Summary:** This MR closes a permission-boundary gap (factory governance could previously dispatch `UpdateLimitOrderConfig` / `UpdateLimitCleanConfig` via `WasmMsg::Execute` to any `addr_validate`-passing address, while every other single-pair admin wrapper already required `PAIR_ADDR_REGISTERED`). The fix mirrors `execute_set_pair_fee`: `ensure_governance` → `addr_validate` → `assert_pair_in_registry` → submessage. Downstream pair handlers remain factory-sender-gated (`info.sender == pair_info.factory`); the registry guard prevents the factory acting as a confused deputy toward unregistered targets. No new injection, authz bypass, or caller-controlled sink was introduced in the diff. **Inline threads:** none (no medium+ findings). Security review: no medium+ findings on this diff.

Brouie commented

2026-06-30 19:08:17 +00:00

(Migrated from gitlab.com)

mentioned in issue #455