Skip to main content

Command Palette

Search for a command to run...

Cloud Agents

Vulnerability Remediation

Vulnerability Remediation finds and fixes security issues in code that's already merged: pre-existing vulnerabilities, long-standing issues, and problems missed during PR review.

To check pull requests before they merge, use Security Review.

Setup

Open the Vulnerability Remediation page in Automations to create and configure Vulnerability Scanner agents. Vulnerability Scanner agents run on the Automations platform and require Cloud Agents.

Source control support

Vulnerability Scanner supports repositories on Origin, GitHub, GitLab, and Bitbucket Cloud.

Source control providerVulnerability Remediation
OriginSupported
GitHubSupported
GitLabSupported
Bitbucket CloudSupported
Bitbucket Data CenterNot supported
Azure DevOps ServicesNot supported

Triggers

Vulnerability Scanner agents support cron-based triggers. Use these triggers to scan your codebase on a recurring schedule, independent of pull request activity.

Vulnerability Scanner cron trigger configuration

Each Vulnerability Scanner has one schedule. To change when it runs, edit its existing trigger. To scan on another schedule, create a separate Vulnerability Scanner. A scan across more than 1,000 repositories can hit provider rate limits, so split large scopes into separate Vulnerability Scanners with smaller repository scopes.

CVE scanning

Vulnerability Scanner supports CVE scanning. On each run, it pulls the latest published CVE reports and scans your selected repositories against them. This allows for newly disclosed vulnerabilities to get caught and auto-remediated after each scheduled scan.

Security checks

Vulnerability Scanner includes built-in security checks. Enable or disable individual checks based on what you want each scanner to look for.

Custom instructions

Use custom instructions to give each scanner more context. You can describe the types of issues to prioritize, explain project-specific security expectations, or define how the agent should behave.

Tools and MCPs

A Vulnerability Scanner saves without a tool or MCP and reports its findings to the Remediation agents section on the Vulnerability Remediation page in Automations. Add tools and MCPs to connect it to the systems where your team tracks security work.

  • Send vulnerabilities to a Slack channel, issue tracker, or another connected system.
  • Add custom instructions that explain when and how the agent should use each MCP.
  • Give the agent extra context from tools or MCPs before it reports a finding.

Environment setup

On a team, Vulnerability Scanner runs its scans on Cursor-managed hosting instead of a Cloud Agent. Teams that require Self-Hosted Machines keep scans on Cloud Agents.

You can use Cursor's cloud with no additional setup.

Billing

Vulnerability Scanner and Remediation Agents are billed at the team usage level:

  • Usage is charged to the team's usage pool.
  • Agents run under a shared team service account, so they don't affect any individual user's usage.

Viewing runs

The Vulnerability Remediation page in Automations lists Recent Runs for your Vulnerability Scanner agents. Use the run history to see when a scanner ran, which tools it used, its final status, and how long it took.

Open a run to inspect the underlying Cloud Agent for more detail about what the agent did. A scan that ran on Cursor-managed hosting has no Cloud Agent.

Remediation Agents

Remediation Agents check the findings produced by the scanner and help you verify and fix them.

For each finding, Cursor starts an agent that writes exploit tests to verify the issue and automatically patches the confirmed ones.

Find them in the Vulnerability Remediation section and on each scanner's detail page.

How it works

Each finding moves through four steps:

  1. Flagged. Vulnerability Scanner reports the finding.
  2. Verified. A verification agent writes tests against the real code path and runs them. It returns one of three verdicts:
    • Confirmed: the tests confirm the issue.
    • Refuted: the tests show the issue can't happen.
    • Inconclusive: the agent couldn't reach a conclusion.
  3. Tests PR. For a confirmed finding, the verification agent opens a draft pull request with its tests. These tests fail on purpose until the issue is fixed.
  4. Fix PR. A patch agent writes the fix, checks it against the tests, and opens a draft pull request for you to review.

Cursor never merges a fix for you. Merging is always your call.

Remediation settings

Each Vulnerability Scanner has two remediation settings. Turn them on in the scanner's settings in Automations.

SettingWhat it does
Verify new findingsStarts a verification agent for each new finding the scanner reports.
Open fix PRs for confirmed findingsStarts a patch agent for each confirmed finding, which opens a draft fix PR.

Reviewing findings

The Vulnerability Remediation section groups findings into tabs by what they need next:

TabWhat's in it
Needs youFindings with a fix PR to review, confirmed findings waiting for a patch, and inconclusive findings.
In flightFindings being verified or patched, and findings queued for either.
Agent-refutedFindings the verification agent showed aren't vulnerabilities.
FixedFindings whose fix PR has merged.
Not verifiedFindings that haven't been queued for verification.

Open a finding to take manual actions on it as needed.

Vulnerability Remediation API

Enterprise teams can use the Vulnerability Remediation API to list findings, request verifications and fixes, and track their progress. Create an API key from Cursor Dashboard → API Keys and authenticate with Basic Authentication.

Each endpoint allows 20 requests per minute per team. List endpoints use cursor pagination: pass a response's nextCursor as cursor to read the next page. When nextCursor is null, there are no more pages.

If Vulnerability Remediation isn't enabled for your team, every endpoint returns 403 Forbidden.

List findings

GET/security/findings

Return the findings your team's Vulnerability Scanners have reported, sorted by repository and then by finding ID.

Requires an API key with read:* scope.

Query Parameters

limit number (optional)

Number of findings per page. Default: 50, max: 100.

cursor string (optional)

The nextCursor from the previous page.
curl --get https://api.cursor.com/security/findings \  -u YOUR_API_KEY: \  --data-urlencode 'limit=50'

Response:

{  "findings": [    {      "findingId": "3f2b8c1e-7a4d-4e2f-9b6a-1c5d8e0f2a47",      "repository": "github:your-org/your-repo",      "severity": "high",      "title": "Missing authorization check on invoice export",      "location": "src/billing/export.ts",      "status": "active"    }  ],  "nextCursor": "Z2l0aHViOnlvdXItb3JnL3lvdXItcmVwbwozZjJi..."}

severity is critical, high, or medium. status is active, or dismissed if someone dismissed the finding.

Request verifications and fixes

POST/security/verifications

Ask Cursor to verify findings, patch them, or both. The request returns as soon as the work is queued. Agents start within a few minutes.

Requires an API key with admin:* scope.

Request Body

findingIds string[] (required)

Finding IDs from GET /security/findings. Send 1 to 50 IDs per request.

verify boolean (required)

When true, verify every finding that hasn't been verified. A finding that's already verified, or being verified, keeps its existing verification.

patch boolean (required)

Whether confirmed findings get a fix PR. Set verify, patch, or both to true.
  • Both: verify, then open fix PRs for confirmed findings.
  • verify only: verify without opening fix PRs.
  • patch only: patch findings that already have a verdict, including refuted ones.

These flags override the scanner's Open fix PRs for confirmed findings setting.

curl --request POST \  --url https://api.cursor.com/security/verifications \  -u YOUR_API_KEY: \  --header 'Content-Type: application/json' \  --data '{    "findingIds": ["3f2b8c1e-7a4d-4e2f-9b6a-1c5d8e0f2a47"],    "verify": true,    "patch": true  }'

Response (202 Accepted):

{  "verifications": [    {      "findingId": "3f2b8c1e-7a4d-4e2f-9b6a-1c5d8e0f2a47",      "verificationId": "3f2b8c1e-7a4d-4e2f-9b6a-1c5d8e0f2a47"    }  ],  "skipped": []}

Save each verificationId to track its progress. A finding that couldn't be queued appears in skipped with a reason:

  • finding_not_found: no finding with this ID.
  • not_verifiable: can't be verified, such as on an unsupported host.
  • not_verified: no verdict yet to patch. Request verify first.

If your team doesn't have a running Vulnerability Scanner to take the request, the endpoint returns 409 Conflict:

{  "code": "error",  "message": "No vulnerability scanner is running for this team"}

List verifications

GET/security/verifications

Return your team's verifications, newest first.

Requires an API key with read:* scope.

Query Parameters

limit number (optional)

Number of verifications per page. Default: 50, max: 100.

cursor string (optional)

The nextCursor from the previous page.
curl --get https://api.cursor.com/security/verifications \  -u YOUR_API_KEY: \  --data-urlencode 'limit=50'

Response:

{  "verifications": [    {      "verificationId": "3f2b8c1e-7a4d-4e2f-9b6a-1c5d8e0f2a47",      "findingId": "3f2b8c1e-7a4d-4e2f-9b6a-1c5d8e0f2a47",      "repository": "github:your-org/your-repo",      "commitSha": "9f3c2a1b7d8e4f5061728394a5b6c7d8e9f0a1b2",      "severity": "high",      "status": "completed",      "verdict": "confirmed",      "verifiedAt": "2026-10-20T18:04:11.000Z",      "testsPrUrl": "https://github.com/your-org/your-repo/pull/128",      "verificationAgent": {        "id": "bc-5b1e9d2a-0c47-4f8e-a3d6-7e2b9c4f1a08",        "url": "https://cursor.com/agents/bc-5b1e9d2a-0c47-4f8e-a3d6-7e2b9c4f1a08"      },      "patch": {        "status": "completed",        "agent": {          "id": "bc-8d4a7f3c-2e19-4b6d-9a05-c1f7e8b3d264",          "url": "https://cursor.com/agents/bc-8d4a7f3c-2e19-4b6d-9a05-c1f7e8b3d264"        },        "fixPrUrl": "https://github.com/your-org/your-repo/pull/129",        "fixPrMerged": false      }    }  ],  "nextCursor": null}

Get a verification

GET/security/verifications/{verificationId}

Return one verification. Use this to poll a request until it finishes.

Requires an API key with read:* scope.

The response is a single verification object, in the same shape as the items in GET /security/verifications. See Verification fields. If your team has no verification with that ID, the endpoint returns 404 Not Found.

curl https://api.cursor.com/security/verifications/3f2b8c1e-7a4d-4e2f-9b6a-1c5d8e0f2a47 \  -u YOUR_API_KEY:

Verification fields

FieldDescription
verificationIdID of the verification.
findingIdFinding this verification checks.
repositoryRepository, in host:owner/repo form.
commitShaCommit the verification ran against. null until known.
severitySeverity reported by the scanner.
statusWhere the work stands. See the table below.
verdictconfirmed, refuted, inconclusive, or null while verification runs.
verifiedAtWhen the verdict was reached. null until then.
testsPrUrlDraft pull request with the verification tests, when one was opened.
verificationAgentID and URL of the verification agent. null until it starts.
patchThe fix, once Cursor decides whether to patch. null until then.
patch.statusWhere the fix stands. See the table below.
patch.agentID and URL of the patch agent. null until it starts.
patch.fixPrUrlDraft pull request with the fix, once opened.
patch.fixPrMergedtrue once the fix PR is merged.

status values:

ValueMeaning
queuedWaiting for a verification agent to start.
verifyingThe verification agent is running.
patchingVerification finished and a fix is queued or in progress.
completedNothing more is running for this finding.

patch.status values:

ValueMeaning
queuedWaiting for a patch agent to start.
runningThe patch agent is working on a fix.
completedThe patch agent finished. Check fixPrUrl for the fix PR.
not_requestedNo fix was requested for this finding.
false_positiveThe finding was refuted, so no fix was needed.
no_tests_prVerification ended without a verdict or tests to build a fix on.
failedThe patch agent couldn't be started.

Errors

Errors return a JSON body with a message:

{  "code": "error",  "message": "Vulnerability verification is not enabled for this team"}
StatusWhen
400 Bad RequestThe request body or query is invalid, or the cursor wasn't issued by this API.
401 UnauthorizedThe API key is missing or doesn't have the required scope.
403 ForbiddenVulnerability Remediation isn't enabled for your team.
404 Not FoundThe verification doesn't exist for your team.
409 ConflictYour team has no running Vulnerability Scanner.
429 Too Many RequestsYou exceeded 20 requests per minute for this endpoint.

Verify and fix findings

  1. Call GET /security/findings and pick the findings you want to act on.
  2. Call POST /security/verifications with their findingIds. Set verify and patch to true to verify them and open fix PRs for confirmed ones.
  3. Save each returned verificationId.
  4. Poll GET /security/verifications/{verificationId} until status is completed.
  5. Review the pull request at patch.fixPrUrl.
  • Security Review checks pull requests for vulnerabilities before they merge.
  • Automations runs Vulnerability Scanner on a schedule.
  • Bugbot reviews pull requests for bugs before they merge.