Fetch fixes for vulnerabilities in a repository, scan, or uploaded manifest

Fetches available fixes for vulnerabilities in a repository, scan, or uploaded manifest.
Requires exactly one of repo_slug, full_scan_id, or tar_hash, as well as vulnerability_ids to be provided.
vulnerability_ids can be a comma-separated list of GHSA or CVE IDs, or "*" for all vulnerabilities.

Response Structure

The response contains a fixDetails object where each key is a vulnerability ID (GHSA or CVE) and the value is a discriminated union based on the type field.

Common Fields

All response variants include:

  • type: Discriminator field (one of: "fixFound", "partialFixFound", "noFixAvailable", "fixNotApplicable", "errorComputingFix")
  • value: Object containing the variant-specific data

The value object always contains:

  • ghsa: string | null - The GHSA ID
  • cve: string | null - The CVE ID (if available)
  • advisoryDetails: object | null - Advisory details (only if include_details=true)

Response Variants

fixFound: A complete fix is available for all vulnerable packages

  • value.fixDetails.fixes: Array of fix objects, each containing:
    • purl: Package URL to upgrade
    • fixedVersion: Version to upgrade to
    • manifestFiles: Array of manifest files containing the package
    • updateType: "patch" | "minor" | "major" | "unknown"
  • value.fixDetails.responsibleDirectDependencies: (optional) Map of direct dependencies responsible for the vulnerability

partialFixFound: Fixes available for some but not all vulnerable packages

  • Same as fixFound, plus:
  • value.fixDetails.unfixablePurls: Array of packages that cannot be fixed, each containing:
    • purl: Package URL
    • manifestFiles: Array of manifest files
    • reasons: Human-readable explanations of why the package cannot be upgraded. May contain multiple distinct entries when different dependency chains are blocked for different causes (e.g. one chain has no compatible upstream version; another would require a major version bump skipped by --no-major-updates).
    • dependencyChain: (optional) Installed PURLs along the dependency chain where the fix search was blocked, from the blocking package down to this package. Present only when a chain was recorded; the first reasons entry describes this chain.
    • withheldFix: (optional) Present when a fix exists but this request's policy withheld it: { purl, version, reason } where purl is the package (without version), version the lowest safe version the policy removed from the fix search, and reason one of majorUpdate (a major update while allow_major_updates=false), releaseAge (younger than minimum_release_age) or publishDateUnknown (publish date unavailable, so minimum_release_age cannot be verified). Lifting the policy is not guaranteed to make the fix applicable — other version constraints in the dependency tree may still block this version.

noFixAvailable: No fix exists for this vulnerability (no patched version published)

  • value.vulnerableArtifacts: Array of vulnerable packages with their manifest files; each carries a static reasons entry stating that no patched version has been published

fixNotApplicable: A patched version of the vulnerable package exists but cannot be applied. The most common cause is that there is no upgrade path through the dependency tree — for example, given a chain App → [email protected][email protected] where B < 2.0.0 is vulnerable, if no version of A accepts [email protected] the fix cannot be applied without a manual override (e.g. pnpm overrides). Other causes include callers passing --no-major-updates when the only patched version is a major bump.

  • value.vulnerableArtifacts: Array of vulnerable packages with their manifest files, each with per-artifact reasons explaining why the fix could not be applied (always at least one entry; a static fallback when the fix search reported no per-package cause) and an optional dependencyChain — installed PURLs from the package that blocked the upgrade down to the vulnerable package, present when a chain was recorded (the first reasons entry describes it), and an optional withheldFix — present when a fix exists but this request's policy withheld it (see the partialFixFound field list)

errorComputingFix: An error occurred while computing fixes

  • value.message: Error description

Fix version alignment

When several requested vulnerabilities are fixed by upgrading the same package, their fix entries carry the SAME fixedVersion — the server computes a version that clears all of them together and verifies it against each advisory's affected ranges. Clients can apply the fixes per package without reconciling versions. Only when no single in-policy version fixes all advisories on a package (non-monotonic affected ranges) can entries differ; each is then the minimal upgrade for its own advisory.

Advisory Details (when include_details=true)

  • title: string | null
  • description: string | null
  • cwes: string[] - CWE identifiers
  • severity: "LOW" | "MODERATE" | "HIGH" | "CRITICAL"
  • cvssVector: string | null
  • publishedAt: string (ISO date)
  • kev: boolean - Whether it's a Known Exploited Vulnerability
  • epss: number | null - Exploit Prediction Scoring System score
  • affectedPurls: Array of affected packages with version ranges

Stateful Alert IDs (when include_stateful_alert_ids=true)

Top-level statefulAlertIds field — a map of GHSA ID → array of open stateful alert IDs (the human-readable SOCKET-XXX-N identifiers also returned by /v0/orgs/{org_slug}/alerts). The lookup is org-scoped, so the same GHSA may map to multiple alert IDs when it appears in alerts across different repos or branches. Callers that need a repo/branch filter should intersect this map with results from the alerts API.

The lookup honors the same scan-type visibility as /v0/orgs/{org_slug}/alerts — when the enableTier1OrgAlertApiRead feature flag is off for the org, only socket scans are visible (no socket_tier1).

Note on scopes: this field surfaces identifiers that are otherwise reachable via /v0/orgs/{org_slug}/alerts (which requires alerts:list). The fixes route is gated on fixes:list alone; the GHSAs the alert IDs are keyed to are already part of every /fixes response, and exposing the matching alert IDs through this opt-in flag is intentional — it lets a caller with only fixes:list complete the correlation back to /alerts on a token that already has that scope. If you require strict scope separation, do not enable this flag.

This endpoint consumes 10 units of your quota.

This endpoint requires the following org token scopes:

  • fixes:list
Recent Requests
Log in to see full request history
TimeStatusUser Agent
Retrieving recent requests…
Loading…
Responses

Language
Credentials
Loading…
Response
Click Try It! to start a request and see the response here! Or choose an example:
application/json