CVE-2025-60455 - Modular Max Serve unsafe deserialization
modular versions earlier than 25.6.0 are vulnerable to
unsafe deserialization in Max Serve. If deployed with
--experimental-enable-kvcache-agent, this can become remote
code execution.
When to use it
Use this recipe when a repository builds or deploys Modular Max Serve for AI inference and may enable the experimental kvcache agent. It is designed for source-code/deployment remediation, unsafe deserialization risk review, runtime flag governance, secret exposure assessment, and evidence that untrusted or cross-tenant requests cannot reach vulnerable deserialization paths.
Inputs
modularversion, Python dependency files, lockfiles, container images, inference service manifests, startup commands, kvcache flags, and SBOM or generated dependency reports.- Source/config paths that start Max Serve, enable
--experimental-enable-kvcache-agent, expose inference endpoints, mount model/cache directories, or pass tenant inputs to serving workers. - Regression or deployment checks for patched versions, disabled risky flags, isolated workers, secret redaction, and clean rollout of rebuilt images.
- Boundary evidence: tenant model/request sources, reachable secrets, writable volumes, service account privileges, logs, image owners, and rollout owner.
Affected versions
- modular (PyPI):
>=0, <25.6.0- vulnerable. - modular (PyPI):
25.6.0+- patched.
Indicator-of-exposure
Exposure requires all of the following:
- The deployed package version resolves to
<25.6.0. - Max Serve is started with
--experimental-enable-kvcache-agent. - Untrusted or cross-tenant input reaches that path.
Quick checks:
python -m pip show modular
ps aux | grep -E 'max serve|kvcache|experimental-enable-kvcache-agent'
Remediation strategy
- Upgrade to
modular>=25.6.0everywhere (requirements.txt, lockfiles, image build manifests). - Disable
--experimental-enable-kvcache-agentby default until upgrade rollout and validation are complete. - Redeploy services and rotate secrets reachable by affected processes if there is any suspicion of exploitation.
- Review runtime logs during the exposure window for suspicious requests or crashes.
The prompt
You are remediating CVE-2025-60455 (Modular Max Serve unsafe
deserialization).
Output exactly one of:
- A PR upgrading to modular 25.6.0+ and removing risky runtime
flag usage, or
- TRIAGE.md when a safe upgrade cannot be shipped now.
## Step 0 - Detect
1. Find every direct/transitive `modular` dependency and lockfile.
2. Confirm runtime invocations for Max Serve and detect use of
`--experimental-enable-kvcache-agent`.
## Step 1 - Remediate
1. Bump all manifests/locks to `modular>=25.6.0`.
2. Remove or hard-disable `--experimental-enable-kvcache-agent`
from production runtime profiles.
3. Update deployment artifacts and operational runbooks.
## Step 2 - Verify
1. Dependency graph resolves to `modular 25.6.0+` in all targets.
2. Startup/config output confirms the experimental flag is absent
from production workloads.
3. CI tests and smoke checks pass.
## Stop conditions
- Upgrade causes unresolved dependency conflicts.
- Service functionality depends on the experimental flag and no
compensating control exists.
- You cannot determine production runtime flags with confidence.
If any stop condition is met, produce TRIAGE.md with blockers,
containment actions, owner, and follow-up date.
Output contract
- A reviewer-ready PR or change request that upgrades
modular, removes or gates risky kvcache-agent flag usage, rebuilds deployment artifacts, and documents runtime/secret review. - Or a
TRIAGE.mdfile that lists inspected dependencies/images/manifests, owner, observed version, kvcache exposure boundary, required fix, and residual risk. - The output must include exact validation commands and must not deserialize untrusted payloads, expose model/provider secrets, or run exploit-like inference traffic.
Verification - what the reviewer looks for
- No manifest or lockfile keeps
modularbelow25.6.0. - Production runtime configs no longer enable the experimental kvcache agent.
- Build/test/deploy checks pass after the dependency change.
Watch for
- Hidden second copies of
modularin transitive lockfiles. - Rollback artifacts still launching with the experimental flag.
- Environment drift between development and production configs.
Related recipes
- Source code injection sink audit
- Source code secrets and data exposure audit
- Source code supply chain build integrity audit
- NIST SSDF repository evidence check