원클릭으로
fix-cve
// Fix CVE vulnerabilities by upgrading affected dependencies across Python (uv), Go, and Rust layers. Use when the user mentions CVE numbers, asks to fix security vulnerabilities, or asks to patch dependencies for CVEs.
// Fix CVE vulnerabilities by upgrading affected dependencies across Python (uv), Go, and Rust layers. Use when the user mentions CVE numbers, asks to fix security vulnerabilities, or asks to patch dependencies for CVEs.
Append a learning to agent-learnings.md when the agent or user identifies a mistake, non-obvious pattern, or useful convention worth remembering. Use when the user says "capture this", "remember this", or "add to learnings".
Set up MSC credentials and MCP server integration for cloud storage access. Use when the user wants to interact with cloud storage (S3, GCS, Azure, OCI), asks to set up credentials, connect to a bucket, list objects, move files, or sync data. Checks for existing config first — only runs interactive setup if credentials are missing.
Produce a feature specification covering API changes, backward compatibility, cross-language impact, performance, and a file-level change plan. Use when designing a new feature, planning a significant change, or the user asks to spec something out.
Produce a test plan with specific test names, assertions, and coverage across Python, Rust, and Go. Use when planning tests for a feature, after generating a spec, or the user asks for a test plan.
Stage files, commit with correct format, push, and generate an MR description. Manual invocation only — has side effects (git operations). Use when the user explicitly asks to prepare, create, or submit an MR.
Prepares and automates the release process for multi-storage-client (version bump, release notes, checklist). Use when the user wants to cut a release, bump version, prepare release, publish a new version, or automate release steps.
| name | fix-cve |
| description | Fix CVE vulnerabilities by upgrading affected dependencies across Python (uv), Go, and Rust layers. Use when the user mentions CVE numbers, asks to fix security vulnerabilities, or asks to patch dependencies for CVEs. |
Fixes one or more CVE vulnerabilities in the multi-storage-client repository by identifying and upgrading affected dependencies.
The user provides one or more CVE identifiers (e.g. CVE-2026-27459).
Copy this checklist and track progress with TodoWrite:
- [ ] Step 1: Research each CVE
- [ ] Step 2: Locate affected dependencies
- [ ] Step 3: Plan fixes (present to user)
- [ ] Step 4: Apply fixes
- [ ] Step 5: Verify lock files and builds
- [ ] Step 6: Output commit message and PR description
For each CVE, web-search for:
Collect into a table:
| CVE | Package | Vulnerable | Fixed | CVSS | Severity |
|---|
Search the repo for each affected package across all layers:
| Layer | Files to check |
|---|---|
| Python direct | multi-storage-client/pyproject.toml [project.dependencies] and [project.optional-dependencies] |
| Python transitive | uv.lock — grep for the package name |
| Go direct | multi-storage-file-system/go.mod require blocks |
| Go transitive | multi-storage-file-system/go.sum |
| Rust | rust/Cargo.toml and rust/Cargo.lock |
If a package is not found anywhere, tell the user and skip it.
For each affected dependency, determine the fix strategy:
Bump the version floor in multi-storage-client/pyproject.toml. If the upper
bound excludes the fixed version, widen it.
Check whether the parent package (the one that pulls it in) has a version that already requires the fixed version. If so, bump the parent's floor.
If no parent version solves it, determine whether a constraint-dependencies
entry or an override-dependencies entry is needed:
constraint-dependencies (preferred) when the upstream allows the
fixed version but the lowest-direct resolver picks an older one. A
constraint tightens the floor without conflicting with upstream bounds.override-dependencies (last resort) only when an upstream package
has an explicit upper bound that blocks the fixed version. Overrides
silently ignore upstream constraints and should be documented with a
comment explaining why.To test which is needed: try constraint-dependencies first. If uv lock
fails with an unsolvable conflict, the upstream has a blocking upper bound
and an override is required.
Both live in the workspace-root pyproject.toml under [tool.uv].
cd multi-storage-file-system
go get <module>@<fixed-version>
go mod tidy
Edit rust/Cargo.toml version requirement, then cargo update -p <crate>.
Apply each fix. After modifying Python constraints/overrides, regenerate the lock file:
uv lock --upgrade-package <package1> --upgrade-package <package2>
Verify the lock file contains the expected versions:
grep -A2 'name = "<package>"' uv.lock
| Layer | Verification command |
|---|---|
| Go | cd multi-storage-file-system && go build ./... |
| Python | just multi-storage-client/run-unit-tests (or cd multi-storage-client && uv run pytest) |
| Rust | cd rust && cargo test |
Only run verification for layers that were changed.
Single line only — no body.
fix: upgrade <packages> for <CVE list>
Example:
fix: upgrade grpc-go, pyOpenSSL, and authlib for CVE-2026-33186, CVE-2026-27459, CVE-2026-27962
## Summary
- <Bullet per CVE: ID, severity, package, what the vulnerability allows, fixed version.>
## Changes
- <Bullet per file changed and what was done.>
## Override justification
<If any override-dependencies were added, explain why a constraint was
insufficient (which upstream package blocks the fixed version and what its
upper bound is). If no overrides, omit this section.>
## Test plan
- [ ] Go module builds: `cd multi-storage-file-system && go build ./...`
- [ ] Python unit tests pass
- [ ] Lock file contains expected versions
- [ ] No new linter errors
cryptography>=44,<46 → <47), flag the change and its implications.