[Aikido] Fix security issue in urllib3 via minor version upgrade from 2.6.2 to 2.6.3 in scripts#25
Open
aikido-autofix[bot] wants to merge 1 commit intomainfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Upgrade urllib3 to mitigate decompression bomb vulnerability in streaming API, preventing potential DoS attacks from malicious servers
✅ Code not affected by breaking changes.
No breaking changes from the urllib3 upgrade affect this codebase.
The urllib3 package is only used as a transitive dependency through the
requestslibrary in two Python utility scripts:scripts/generate_parliament_iam_permissions/scrape_iam_permissions.py(urllib3 2.5.0)scripts/generate_aws_supported_endpoints/main.py(urllib3 2.6.3)These scripts make simple HTTP GET requests using
requests.get()without any custom retry configuration, timeout settings, orRetry-Afterheader handling. The change in urllib3 2.6.3 that capsRetry-Aftertimes at 6 hours only affects code that explicitly configures retry behavior or relies on specific retry delay timing. Since these scripts use the defaultrequestsbehavior without customization, the 6-hour cap on retry delays will not impact their functionality.The main codebase is written in Go and uses AWS SDK retry mechanisms (as seen in
aws/service.go), which are completely independent of urllib3.All breaking changes by upgrading urllib3 from version 2.6.2 to 2.6.3 (CHANGELOG)
Retry-Aftertimes greater than 6 hours as 6 hours by default, which restricts previously allowed retry delay behavior✅ 1 CVE resolved by this upgrade
This PR will resolve the following CVEs:
🔗 Related Tasks