A state accumulation vulnerability exists in the GitHub Runner scaler due to the lack of cache eviction, pruning, or time-to-live (TTL) logic for internal state maps used by the enableEtags caching feature. The scaler maintains state for etags, previousJobs, previousWfrs, and previousRepos using resource identifiers like dynamic repository names or constructed URLs as keys.
Because githubApiURL is user-configurable, a user can configure a ScaledObject with enableEtags: "true" and point githubApiURL to a malicious, attacker-controlled server. This server can return a constantly rotating list of unique, large repository names on every polling interval. As these keys and values accumulate indefinitely within the long-lived operator process, it leads to unbounded memory growth.
To avoid this problem, we should implement some internal cache eviction policy, like a max amount of entries as well as pruning those from previous executions which are not present anymore in the response.
A state accumulation vulnerability exists in the GitHub Runner scaler due to the lack of cache eviction, pruning, or time-to-live (TTL) logic for internal state maps used by the enableEtags caching feature. The scaler maintains state for etags, previousJobs, previousWfrs, and previousRepos using resource identifiers like dynamic repository names or constructed URLs as keys.
Because githubApiURL is user-configurable, a user can configure a ScaledObject with enableEtags: "true" and point githubApiURL to a malicious, attacker-controlled server. This server can return a constantly rotating list of unique, large repository names on every polling interval. As these keys and values accumulate indefinitely within the long-lived operator process, it leads to unbounded memory growth.
To avoid this problem, we should implement some internal cache eviction policy, like a max amount of entries as well as pruning those from previous executions which are not present anymore in the response.