TT-6075: Update rate limit implementation #7941
Merged
probelabs / Visor: security
succeeded
Apr 20, 2026 in 41s
✅ Check Passed (Warnings Found)
security check passed. Found 2 warnings, but fail_if condition was not met.
Details
📊 Summary
- Total Issues: 2
- Warning Issues: 2
🔍 Failure Condition Results
Passed Conditions
- global_fail_if: Condition passed
Issues by Category
Security (2)
⚠️ gateway/session_manager.go:185 - ThelimitSentinelfunction spawns a 'fire-and-forget' goroutine for every request to update the Redis rolling window counter. Under high traffic, this can lead to unbounded goroutine creation, causing excessive memory consumption, CPU scheduler contention, and potentially overwhelming the Redis server. This creates a denial-of-service vulnerability where the gateway can be crashed by a flood of requests.⚠️ gateway/session_manager.go:369 - The key for the in-memory rate-limiting bucket (bucketKey) is constructed usingsession.LastUpdated. Sincesession.LastUpdatedcan change on every request for certain configurations, a new in-memory bucket may be created for each request when using the default Distributed Rate Limiter (DRL) in single-node mode. This leads to unbounded memory growth as old buckets are never reused or garbage-collected, causing a memory leak that can result in a Denial of Service.
Powered by Visor from Probelabs
💡 TIP: You can chat with Visor using /visor ask <your question>
Annotations
Check warning on line 185 in gateway/session_manager.go
probelabs / Visor: security
security Issue
The `limitSentinel` function spawns a 'fire-and-forget' goroutine for every request to update the Redis rolling window counter. Under high traffic, this can lead to unbounded goroutine creation, causing excessive memory consumption, CPU scheduler contention, and potentially overwhelming the Redis server. This creates a denial-of-service vulnerability where the gateway can be crashed by a flood of requests.
Raw output
Replace the unbounded 'fire-and-forget' goroutine with a bounded worker pool. Requests to update the rate limiter should be sent to a channel, which is processed by a fixed number of worker goroutines. This will throttle the updates to Redis and prevent the creation of an excessive number of goroutines, protecting the gateway from resource exhaustion.
Check warning on line 369 in gateway/session_manager.go
probelabs / Visor: security
security Issue
The key for the in-memory rate-limiting bucket (`bucketKey`) is constructed using `session.LastUpdated`. Since `session.LastUpdated` can change on every request for certain configurations, a new in-memory bucket may be created for each request when using the default Distributed Rate Limiter (DRL) in single-node mode. This leads to unbounded memory growth as old buckets are never reused or garbage-collected, causing a memory leak that can result in a Denial of Service.
Raw output
The bucket key should not include transient data like `session.LastUpdated`. A stable key should be used, for example, by removing the `session.LastUpdated` component: `bucketKey := limiterKey`. If a unique bucket per session update cycle is truly required, a mechanism to expire and garbage-collect old, unused buckets must be implemented to prevent memory leaks.
Loading