Raise mcp & starlette dependency floors so GHSA fixes reach consumers#203
Merged
Conversation
The Socket security bumps (#199 etc.) only edited uv.lock, which is not published to PyPI. Consumers of keycardai-mcp resolve mcp against the declared floor in pyproject.toml, which was >=1.13.1 and still allowed versions vulnerable to three HIGH advisories fixed in mcp 1.28.1: - GHSA-jpw9-pfvf-9f58: HTTP transports serve session requests without verifying the authenticated principal (auth bypass) - GHSA-hvrp-rf83-w775: experimental task handlers cross-client access - GHSA-vj7q-gjh5-988w: WebSocket transport missing Host/Origin validation Raising the floor to >=1.28.1 (a minor bump within mcp 1.x) makes the fix propagate to downstream consumers. The lock already resolves 1.28.1.
Contributor
📦 Release PreviewThis analysis shows the expected release impact: 📈 Expected Version Changes📋 Package Details[
{
"package_name": "keycardai-mcp",
"package_dir": "packages/mcp",
"has_changes": true,
"current_version": "0.26.0",
"next_version": "0.27.0",
"increment": "MINOR"
}
]📝 Changelog PreviewThis comment was automatically generated by the release preview workflow. |
Same class of gap as the mcp bump. Socket PR #126 (May) patched the starlette lock to 1.0.1 for GHSA-86qp-5c8j-p5mr (missing Host header validation poisons request.url.path), but the published floor stayed >=0.47.3, so consumers could still resolve a vulnerable starlette (0.47.3-1.0.0) through keycardai-starlette. starlette never backported the fix to the 0.x line (patched only in 1.0.1), so >=1.0.1 is the minimum non-vulnerable floor. Our code already runs and tests against starlette 1.x (lock resolves 1.3.1). This drops starlette-0.x support, acceptable for a 0.x alpha package.
Larry-Osakwe
changed the title
Contributor
📦 Release PreviewThis analysis shows the expected release impact: 📈 Expected Version Changes📋 Package Details[
{
"package_name": "keycardai-starlette",
"package_dir": "packages/starlette",
"has_changes": true,
"current_version": "0.11.0",
"next_version": "0.11.1",
"increment": "PATCH"
},
{
"package_name": "keycardai-mcp",
"package_dir": "packages/mcp",
"has_changes": true,
"current_version": "0.26.0",
"next_version": "0.27.0",
"increment": "MINOR"
}
]📝 Changelog PreviewThis comment was automatically generated by the release preview workflow. |
Larry-Osakwe
marked this pull request as ready for review
July 20, 2026 18:57
mnoble
approved these changes
Jul 20, 2026
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
3 participants
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.
Important
Merge-commit this PR, do NOT squash. It carries two separately-released packages (
keycardai-mcpandkeycardai-starlette), one scoped commit each. Squashing collapses to a single subject, so only one package's release would fire. A merge commit preserves bothfix(...)commits so both release.Why
The Socket security PRs only edit
uv.lock, which is not published to PyPI. Consumers resolve transitive deps against the declared floors inpyproject.toml, so a lock-only bump leaves those floors stale and lets consumers pull vulnerable versions through our packages. An audit of floor-vs-lock drift across all direct deps found two such gaps (both HIGH):keycardai-mcp:mcp>=1.13.1→>=1.28.1Floor still allowed versions vulnerable to three HIGH advisories fixed in
mcp1.28.1:Minor bump within
mcp1.x; the lock already resolves 1.28.1.keycardai-starlette:starlette>=0.47.3→>=1.0.1Socket PR #126 (May) patched the lock to starlette 1.0.1 for GHSA-86qp-5c8j-p5mr (missing Host-header validation poisons
request.url.path), but the floor stayed>=0.47.3, still allowing vulnerable 0.47.3–1.0.0. Starlette never backported the fix to the 0.x line (patched only in 1.0.1), so>=1.0.1is the minimum non-vulnerable floor. This drops starlette-0.x support — acceptable for a 0.x alpha package, and our code already runs/tests against starlette 1.x (lock resolves 1.3.1; provider tests green).Verification
uv sync --all-packages --all-extras --frozenconsistent for both;keycardai-starletteprovider tests pass on the locked starlette 1.3.1.Not included
idna(GHSA-65pc, #125) is transitive with no floor of ours to raise — lock-only was correct there.joserfcfloor was already raised to>=1.6.8in #195.