CNV-91916:[CNV-4.20] Starlette: request.form() limits silently ignored for application/x-www-form-urlencoded enable DoS - #5974
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Report bugs in Issues Welcome! 🎉This pull request will be automatically processed with the following features: 🔄 Automatic Actions
📋 Available CommandsPR Status Management
Review & Approval
Testing & Validation
Container Operations
Cherry-pick Operations
Branch Management
Label Management
✅ Merge RequirementsThis PR will be automatically approved when the following conditions are met:
📊 Review ProcessApprovers and ReviewersApprovers:
Reviewers:
Available Labels
AI Features
Security Checks
💡 Tips
📌 Additional InformationCustom Commands:
For more information, please refer to the project documentation or contact the maintainers. |
|
Clean rebase detected — no code changes compared to previous head ( |
|
Clean rebase detected — no code changes compared to previous head ( |
What this PR does / why we need it:
Since the project is using the
starlettepackage as a transitive dependency(openshift-python-wrapper → fastmcp → mcp → starlette), it is affected byCVE-2026-54283 (GHSA-82w8-qh3p-5jfq). This vulnerability allows Denial of Service unbounded resource allocation inrequest.form()for URL-encoded requests (CVSS 7.5). This PR bumps starlette to >= 1.3.1 whichcontains the fix.
Which issue(s) this PR fixes:
CVE-2026-54283 — starlette
request.form()silently ignores configured limits (max_fields, max_part_size) for application/x-www-form-urlencoded requests, allowing field count and field size attacks.Special notes for reviewer:
The dependency is transitive (4 levels deep) and only the lock file needs updating. No direct code changes are required. Practical risk is low since this is a test framework, but bumping resolves the vulnerability in dependency scanners.
jira-ticket:
https://redhat.atlassian.net/browse/CNV-91916