You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
list_tasks has no MAX_LIMIT cap — a single call with limit=u32::MAX reads every task in the registry #82
Why this matters now:
This is a denial-of-service and budget exhaustion vector. list_tasks(cursor=0, limit=u32::MAX) will iterate through every task ID from 0 to task_count, reading each from persistent storage. At 1,000 tasks that is 1,000 persistent reads in one transaction — well above the Soroban 100-entry footprint limit. The transaction will fail, but any caller (including a malicious one) can use this to grief indexer bots by crafting calls that are guaranteed to hit budget limits, and the missing guard is inconsistent with the rest of the API design.
Problem / What: RegistryContract::list_tasks in registry.rs accepts limit: u32 with no upper bound check. The function loops while current < count && remaining > 0, where remaining starts at limit. Passing u32::MAX will attempt to read every task entry. The get_tasks_by_creator_paged function similarly has no cap. The fix is to define a MAX_PAGE_SIZE: u32 = 50 constant (matching the existing MAX_CREATOR_TASKS_QUERY value) and panic or clamp when limit > MAX_PAGE_SIZE.
Key Challenges:
Clamping vs. panicking: panicking is more explicit and forces callers to use correct page sizes; clamping silently truncates. Choose one and document it.
get_pending_verifications_paged and get_verifications_by_user in the engine have the same uncapped limit parameter — fix all three in one pass.
Existing tests that pass u32::MAX as limit (e.g., test_list_tasks_full_scan) must be updated to use the new cap or a documented override.
Acceptance Criteria:
list_tasks, get_tasks_by_creator_paged, get_pending_verifications_paged, get_verifications_by_user all reject limit > MAX_PAGE_SIZE with a descriptive panic.
MAX_PAGE_SIZE is a named constant defined in each contract's storage module.
Tests confirm the cap is enforced (e.g., #[should_panic] test passing MAX_PAGE_SIZE + 1).
All existing pagination tests updated to use valid limit values.
Activity
Jerry-Tekh commentedon Aug 26, 2026
Hello manager. i will implement the required fix. get me assigned to this issue and i will get it done correctly. thank you .
grantfox-oss commentedon Aug 26, 2026
🦊 GrantFox — @Jerry-Tekh has been assigned to this issue as part of the Third Campaign campaign!
Next steps:
Closes #82)Good luck! Track your progress on GrantFox.
fix: enforce MAX_PAGE_SIZE=50 on all paginated queries (closes #82) (#88
grantfox-oss commentedon Aug 29, 2026
🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!
@Jerry-Tekh's PR #88 was approved and merged by @cybermax4200.
🏆 @Jerry-Tekh: You earned 35 FoxPoints for this contribution! Your current tier: Builder (1,019 total points). Track your full progress on GrantFox.
👏 Great work, @Jerry-Tekh! Keep contributing to ecotask-network.