Immutable. This exact content is served forever at /api/v1/blob/597395cef0f4c9ed.
---
name: fix
description: Get fix intelligence for a vulnerability and propose concrete remediation for the current repository
argument-hint: <vuln-id>
user-invocable: true
allowed-tools: Bash, Read, Glob, Grep, Edit, Write, WebFetch
---
# Vulnetix Fix Intelligence Skill
This skill fetches fix intelligence for a vulnerability and proposes concrete, actionable remediation steps for the current repository.
## Workflow
### Step 1: Fetch Fix Data
Run the Vulnetix VDB fixes command for both V1 and V2 endpoints:
```bash
vulnetix vdb fixes "$ARGUMENTS" -o json
vulnetix vdb fixes "$ARGUMENTS" -o json -V v2
```
**V1 response** (basic fixes):
```json
{
"fixes": [
{
"type": "version",
"package": "log4j-core",
"ecosystem": "maven",
"fixedIn": "2.17.1",
"description": "Upgrade to patched version"
}
]
}
```
**V2 response** (enhanced with registry, distro, source fixes):
```json
{
"fixes": [
{
"type": "registry",
"package": "log4j-core",
"ecosystem": "maven",
"fixedIn": "2.17.1",
"registryUrl": "https://repo1.maven.org/...",
"releaseDate": "2021-12-28"
},
{
"type": "distro-patch",
"distro": "ubuntu",
"version": "20.04",
"package": "liblog4j2-java",
"patchVersion": "2.17.1-0ubuntu1",
"aptCommand": "sudo apt-get install liblog4j2-java=2.17.1-0ubuntu1"
},
{
"type": "source-fix",
"commitUrl": "https://github.com/apache/logging-log4j2/commit/abc123",
"patchUrl": "https://github.com/apache/logging-log4j2/commit/abc123.patch"
}
]
}
```
### Step 2: Fetch Vulnerability Context
Get additional context about the vulnerability:
```bash
vulnetix vdb vuln "$ARGUMENTS" -o json
vulnetix vdb affected "$ARGUMENTS" -o json -V v2
```
Extract:
- **Affected package/product** names
- **Vulnerable version ranges** (e.g., `>=2.0.0, <2.17.1`)
- **CVSS/severity** (to assess urgency)
- **CISA KEV due date** (if applicable)
### Step 3: Analyze Repository Dependencies
Use **Glob** to find manifest files, then **Read** them to identify affected dependencies:
**npm** (`package.json`):
```json
{
"dependencies": {
"vulnerable-package": "1.2.3"
}
}
```
**Python** (`requirements.txt`, `pyproject.toml`, `Pipfile`):
```
vulnerable-package==1.2.3
```
**Go** (`go.mod`):
```
require vulnerable-package v1.2.3
```
**Cargo** (`Cargo.toml`):
```toml
[dependencies]
vulnerable-package = "1.2.3"
```
**Maven** (`pom.xml`):
```xml
<dependency>
<groupId>org.example</groupId>
<artifactId>vulnerable-package</artifactId>
<version>1.2.3</version>
</dependency>
```
Determine:
1. **Is the vulnerable package installed?** (exact name match)
2. **What version is installed?** (compare with vulnerable range)
3. **Is it a direct or transitive dependency?** (look for lock files)
If the package is **not found**, inform the user that the vulnerability may not affect this repository.
### Step 4: Present Fix Options
Categorize fixes into 4 categories (A-D) and present them in priority order:
---
#### **A. Version Bump** (Preferred)
If a patched version is available in the registry:
| Current Version | Target Version | Breaking Changes? | Manifest File |
|-----------------|----------------|-------------------|---------------|
| 2.14.1 | 2.17.1 | Likely (major) | pom.xml |
**Action:** Update dependency version in manifest file.
**Risk assessment:**
- **Patch version** (2.14.1 → 2.14.2): Low risk, backward compatible
- **Minor version** (2.14.x → 2.15.0): Medium risk, check changelog
- **Major version** (2.x → 3.0): High risk, breaking changes expected
---
#### **B. Patch** (Alternative)
If a source patch is available:
| Patch Source | Type | Applicability |
|--------------|------|---------------|
| GitHub commit abc123 | Source fix | Can be applied to local fork |
| Ubuntu 20.04 | Distro patch | Only if running on Ubuntu |
**Action:** Download patch and apply to local dependency copy (advanced users only).
---
#### **C. Workaround** (Temporary Mitigation)
If no fix is available yet, provide temporary mitigations:
- **Configuration changes** (disable vulnerable feature, enable safeguards)
- **Input validation** (sanitize untrusted input)
- **Network isolation** (firewall rules, rate limiting)
- **Vendor-recommended workarounds** (from advisory)
**Action:** Apply configuration changes to relevant files.
---
#### **D. Advisory Guidance** (Informational)
- **Vendor advisory links** (official fix documentation)
- **CISA KEV due date** (if listed, agencies must patch by this date)
- **Community discussion** (GitHub issues, Stack Overflow)
**Action:** No immediate action, but monitor for updates.
---
### Step 5: Propose Concrete Changes
For the **preferred fix option** (usually Version Bump), show the **exact edits** using the **Edit** tool:
**Example for Maven (pom.xml):**
```diff
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
- <version>2.14.1</version>
+ <version>2.17.1</version>
</dependency>
```
**Example for npm (package.json):**
```diff
{
"dependencies": {
- "express": "4.17.1",
+ "express": "4.18.2",
"other-package": "1.0.0"
}
}
```
**DO NOT APPLY THE EDIT YET** — show the diff and wait for user approval.
If a workaround configuration change is needed, show that edit as well.
### Step 6: Planning Interview
Ask the user:
1. **Which fix approach would you like to use?** (Version Bump / Patch / Workaround)
2. **Should I apply the changes now?** (If yes, execute the edits with **Edit** or **Write** tools)
3. **Run tests after applying the fix?** (If yes, identify test command from manifest and run it)
4. **Verify the fix with `vulnetix scan`?** (Recommend re-scanning to confirm vulnerability is resolved)
**Suggested workflow after user approves:**
```bash
# Apply the edit (already done via Edit tool)
# Install updated dependency
npm install # for npm
pip install -r requirements.txt # for Python
go mod tidy # for Go
cargo update # for Rust
mvn install # for Maven
# Run tests (if available)
npm test # or appropriate test command
# Verify fix
vulnetix scan --file <manifest> -f json
```
If the scan still shows the vulnerability, explain that it may be a transitive dependency and suggest:
- Using dependency update tools (`npm audit fix`, `cargo update`, etc.)
- Manually updating the parent dependency that pulls in the vulnerable package
- Checking if a newer version of the parent dependency exists
## Error Handling
- If `vulnetix vdb fixes` returns no results, inform the user that no official fix is available yet and suggest workarounds or monitoring
- If the package is not found in the repository, confirm with the user whether it's a transitive dependency
- If manifest format is complex (Gradle, multi-module Maven), ask the user which file to edit
- If breaking changes are expected, warn the user and recommend testing thoroughly
## Security Notes
- **Always upgrade to the latest patched version** unless there are known regressions
- If a vulnerability has a **CISA KEV due date**, prioritize it as urgent
- For **critical/high severity** vulnerabilities, recommend immediate patching even if it requires major version bumps
- Never downgrade to an older version as a "fix" — this may introduce other vulnerabilities
## Integration with Other Skills
- If exploits are known, suggest running `/vulnetix:exploits $ARGUMENTS` first to understand impact
- After fixing, suggest re-running `/vulnetix:package-search` if adding new dependencies as alternatives