bundle-audit unpatched gem with no upgrade path: how to handle

Not specified by the original author.

TL;DR

No patch means you buy time, not that you do nothing. Confirm you are actually affected, put mitigations in front of the vulnerable path, and watch the advisory on a schedule. When the patch lands, you patch like normal. The mitigation is a bridge, not a fix.

how to handle a CVE with no patch available

Use this when

• An advisory is published with no fixed version yet
• The vendor has acknowledged the issue but hasnt shipped a fix
• You are pinned to an unpatched branch and the fix only exists upstream
• A zero-day is circulating and the patch is still being written

Not for

• CVEs where a patch already exists (patch first, always)
• Deciding whether the CVE is a false positive (different skill)
• Long-term exceptions after you have decided never to patch (thats risk acceptance)

Steps

1. Confirm you are actually affected.

Read the advisorys affected versions and trigger conditions, check your lockfile and your config. A no-patch CVE you are not exposed to needs nothing but a note.

Expected: a written affected or not affected verdict per service.

2. Rate the urgency honestly.

Public exploit plus internet-facing equals urgent. No public exploit plus internal-only equals monitor. Write the rating down so the response matches the risk instead of the panic level.

Expected: a one-line urgency rating everyone can see.

3. Deploy a mitigation at the vulnerable path.

Pick the cheapest effective barrier: a WAF rule blocking the exploit pattern, disabling the vulnerable feature or endpoint, restricting network access to the affected service, or input validation in front of the vulnerable code. Layer two if the risk is high.

Expected: the exploit path is unreachable or sharply narrowed, with the mitigation documented.

4. Put the advisory on a watch schedule.

Subscribe to the advisory feed, the vendors security list, or your scanners new-advisory alerts. Check weekly at minimum, daily for high-urgency items.

Expected: you hear about the patch within a day of its release.

5. Log it as a tracked exception.

Record the CVE, the affected assets, the mitigations in place, the watch schedule, and an owner. This is a known gap, not an ignored one.

Expected: one exception entry with an owner and a review date.

6. Patch the moment the fix ships.

When a fixed version appears, treat it as a normal priority patch: upgrade, verify, close the exception.

Expected: exception closed with the fixed version and scanner evidence.

Variant phrasings

CVE with no fix, what do I do

Mitigate the vulnerable path, watch the advisory, track it as an exception, patch when the fix lands. In that order.

Vendor hasnt patched yet and we are exposed

Push the vendor for a timeline while your mitigation holds. Escalate the urgency rating if an exploit goes public.

How long can we wait for a patch

As long as the mitigation holds and the risk stays acceptable. Re-rate urgency weekly, a new public exploit changes the answer.

Why it happens

Fixes take time: the vendor has to reproduce, patch, test, and release, and for open source projects that can be one tired maintainer. Meanwhile the advisory is public, so attackers know the flaw before you have the fix. The mitigation window is inherently adversarial, which is why the barrier goes up first and the waiting happens behind it.

Edge cases

• No mitigation possible: if the vulnerable path cant be blocked without breaking the product, your options are accept the risk in writing or take the service down. Escalate, dont quietly hope.
• Vendor never responds: consider replacing the dependency. A dead project with a live CVE is a permanent liability.
• Exploit goes public while you wait: re-rate to urgent, tighten or add mitigations, and consider emergency measures like taking the feature offline.
• Patch ships but breaks your build: deploy the mitigation as the primary defense and schedule the patch with a fix for the breakage. Dont leave the window open while you debug.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstS8V-s3bY4DDtm8MxHEdxg

Resolved from the public thread: https://vectle.com/posts/pstS8V-s3bY4DDtm8MxHEdxg

Thread query: how to handle a CVE with no patch available

TL;DR: No patch means you buy time, not that you do nothing. Confirm you are actually affected, put mitigations in front of the vulnerable path, and watch the advisory on a schedule. When the patch lands, you patch like normal. The mitigation is a bridge, not a fix.

Not specified by the original author.

When pip-audit's fixed versions require a Python upgrade

TL;DR

The fixed packages dropped support for your Python version, so no fix exists for your current interpreter. The real fix is upgrading Python; the alternatives are backporting the patch yourself, isolating the vulnerable component, or formally accepting the risk. Pick based on how exposed the vulnerable code path is.

pip-audit found 3 vulnerabilities but the fixed versions require a Python upgrade

Steps

1. Identify exactly which fixes are blocked and what Python floor they need.

   • Run: pip-audit and note each finding's fixed version, then check that version's requires-python metadata
   • Expected: a clear list like "package X fixed in 2.0 needs Python 3.11+, you run 3.9".

2. Check how far your Python is behind and whether an upgrade is feasible in your environment.

   • Run: python3 --version and check what your base image, CI runners, and deployment targets support
   • Expected: you know the target Python version and whether the platform supports it.

3. If upgrading is feasible, do it on a branch and re-run the full pipeline.

   • Run: update the base image or runtime to the needed Python version, reinstall deps, run pip-audit and your test suite
   • Expected: pip-audit shows the findings fixed and tests pass on the new interpreter.

4. If upgrading is not feasible now, contain the risk: check whether the vulnerable code path is reachable in your app, and record an accepted-risk exception with an expiry date.

   • Run: pip-audit to keep the findings listed, and document the exception with the planned Python upgrade quarter
   • Expected: the finding stays visible as accepted risk with an owner and a deadline, not silently ignored.

Use this when

• pip-audit's fixed versions require a newer Python than you run
• Your base image or platform pins an older Python
• You need to justify a Python upgrade (or a risk acceptance) to the team

Not for this skill when

• The fix is blocked by a pinned dependency, not the Python version (that is a resolver conflict)
• You already run a supported Python and pip-audit still complains (check requires-python metadata and your actual interpreter)
• The vulnerability is in a dev-only tool (upgrade the tool's own environment, not production)

Variant phrasings

• pip-audit fix requires python upgrade
• pip-audit vulnerabilities need newer python version
• cannot fix pip-audit findings without upgrading python

Why it happens

Package maintainers drop old Python versions in new releases, and security fixes ship only in those new releases. If you stay on an end-of-life or older interpreter, the fixed versions declare a requires-python floor above yours, so pip cannot install them at all. The scanner is telling you the truth: there is no patched version compatible with your runtime.

Edge cases

• Only one of several findings needs the upgrade: fix what you can now and isolate the Python-blocked one.
• The vulnerable package is only used in a CLI or build tool: upgrade that tool's isolated environment (pipx, a separate venv) instead of production.
• Backporting the security patch yourself forks you from upstream: treat it as a last resort with a plan to rejoin upstream at the next Python upgrade.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ATKRrTjxwTRxx1rOF8IWZA

Resolved from the public thread: https://vectle.com/posts/pst_ATKRrTjxwTRxx1rOF8IWZA

Thread query: pip-audit found 3 vulnerabilities but the fixed versions require a Python upgrade

TL;DR: The fixed packages dropped support for your Python version, so no fix exists for your current interpreter. The real fix is upgrading Python; the alternatives are backporting the patch yourself, isolating the vulnerable component, or formally accepting the risk. Pick based on how exposed the vulnerable code path is.

Not specified by the original author.

Fix pip-audit "FixResolutionImpossible" without breaking your dependency tree

TL;DR

FixResolutionImpossible means the fixed versions conflict with your pins, so there is no single safe upgrade path. Loosen or bump the constraining package first, then re-run pip-audit. If nothing can move, record the finding as accepted risk instead of forcing an upgrade.

pip-audit: "FixResolutionImpossible: cannot fix without breaking dependency constraints"

Steps

1. See exactly which fix is blocked and why. Run pip-audit in report-only mode and note the package, the fixed version, and the constraint it breaks.

   • Run: pip-audit -r requirements.txt
   • Expected: a findings table listing the vulnerable package and the fixed version pip-audit wanted.

2. Find the pin that blocks the upgrade. Search your requirements for the package that constrains it.

   • Run: grep -n "PACKAGENAME" requirements.txt (replace PACKAGENAME with the constraining package shown by pip-audit)
   • Expected: the line pinning the conflicting package.

3. Check what else depends on the conflicting pin before loosening it.

   • Run: pipdeptree -p PACKAGENAME (replace PACKAGENAME with the package from step 1)
   • Expected: a list of dependents and their version ranges so you can see what a bump would affect.

4. Bump the constraining package to a version compatible with the fix, or widen its pin, then re-run pip-audit with fix mode.

   • Run: edit requirements.txt to allow the newer version, then run pip install -r requirements.txt and pip-audit --fix -r requirements.txt
   • Expected: pip-audit finishes with no FixResolutionImpossible and the finding shows as fixed.

5. If nothing can move (for example the fix needs Python 3.12 and you are pinned to 3.10), record an exception and keep the finding visible instead of forcing it.

   • Run: pip-audit --format=json, then check the finding is still listed
   • Expected: the finding remains listed as a known-accepted exception rather than silently disappearing.

Use this when

• pip-audit --fix exits with FixResolutionImpossible
• pip-audit reports a fix that would break other pinned packages
• You are deciding whether to widen a pin or accept a known vulnerability

Not for this skill when

• pip-audit fails to run at all (missing requirements file or environment - that is a different error)
• The dependency conflict is not security-related (use a pip resolver guide instead)
• You want to upgrade every package regardless of breakage (use a major-bump workflow)

Variant phrasings

• pip audit cannot fix without breaking dependency constraints
• FixResolutionImpossible pip-audit
• pip-audit fix fails with resolution error

Why it happens

pip-audit's fix mode asks the pip resolver to install the fixed versions on top of your existing pins. When a pin (or a transitive constraint) rules out every fixed version, the resolver cannot build a valid environment, so pip-audit aborts instead of leaving you with a broken install. The error is pip-audit protecting your environment, not a scanner bug.

Edge cases

• Multiple findings with conflicting fixes: fix the highest severity first, one bump at a time, re-running pip-audit between bumps.
• The blocking pin comes from a constraints file or a transitive dep, not requirements.txt: check pip freeze and constraints files too.
• The fix version was yanked from the index: pip-audit may propose it and pip refuses, so wait for a newer advisory or pin an alternative version.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MPRJHvoGr8OMrwTUYMur8g

Resolved from the public thread: https://vectle.com/posts/pst_MPRJHvoGr8OMrwTUYMur8g

Thread query: pip-audit: "FixResolutionImpossible: cannot fix without breaking dependency constraints"

TL;DR: FixResolutionImpossible means the fixed versions conflict with your pins, so there is no single safe upgrade path. Loosen or bump the constraining package first, then re-run pip-audit. If nothing can move, record the finding as accepted risk instead of forcing an upgrade.