# PETI Vulnerabilities
source: https://developer.mastercard.com/mastercard-threat-intelligence/documentation/use-cases/peti-vulnerabilities/index.md

## Overview {#overview}

This document provides practical usage scenarios for the Payment Ecosystem Threat Intelligence (PETI) High Risk Vulnerabilities API, illustrating how Issuers and Acquirers can use curated vulnerability intelligence to identify potential exposure to software vulnerabilities affecting the payment ecosystem.

This use case demonstrates how organizations can incorporate vulnerability intelligence into security operations, risk management, and remediation workflows to proactively reduce cyber and fraud-related risks. The API is intended to help customers assess vulnerabilities that affect payment and commerce software, review severity and lifecycle information, and prioritize remediation efforts.

## Monitor PETI High-Risk Vulnerabilities {#monitor-peti-high-risk-vulnerabilities}

### Context {#context}

Payment fraud increasingly originates from cyber compromises that exploit vulnerable software within the payment ecosystem. Issuers and Acquirers may rely on payment processing platforms, e-commerce technologies, merchant software, third-party integrations, and other digital services that are affected by newly disclosed vulnerabilities.

Security and fraud teams require actionable intelligence that helps them identify vulnerabilities most relevant to payment environments, understand their severity and lifecycle status, and prioritize remediation activities before they can be leveraged by threat actors. The PETI High Risk Vulnerabilities API provides curated vulnerability intelligence focused on technologies commonly used across the payment ecosystem.

### Goal {#goal}

Find high-risk Common Vulnerabilities and Exposures (CVE) records and assess their impact.

### Main actors {#main-actors}

The analyst, your application, and the Mastercard Threat Intelligence API.

### Preconditions {#preconditions}

* OAuth 2.0 credentials and access tokens have been obtained.
* Internal teams maintain an inventory of technologies, products, and platforms used within their merchant's environment.
* Vulnerability monitoring is an established operational process.

### Desired outcome {#desired-outcome}

* Relevant high-risk vulnerabilities affecting payment and commerce technologies are identified through the API.
* Vulnerabilities are prioritized according to risk and severity.
* Remediation activities are initiated where appropriate.
* Exposure is reduced through proactive security action.

## Steps {#steps}

1. Choose the search text and filters, such as severity label or lifecycle phase.
2. Send a search request with pagination and sorting.
3. Read the CVE records and their risk scores.
4. Match the affected products against your ecosystem.

### Sequence {#sequence}

Diagram mti-peti-vulnerabilities

## Endpoint {#endpoint}


API Reference: `GET /exposures/vulnerabilities`

### Key parameters {#key-parameters}

* `search_text`: free-text search across vulnerability fields.
* `severity_label`: filter by severity, for example `High`.
* `lifecycle_phase`: filter by phase, for example `Exploited` or `Exploit Likely`.
* `limit` and `offset`: pagination controls.
* `sort_by` and `sort_direction`: sorting controls.

## Example request {#example-request}

```text
GET /exposures/vulnerabilities?severity_label=High&lifecycle_phase=Exploited&limit=20&sort_by=riskScore&sort_direction=DESC
```

## Example response {#example-response}

```json
{
  "records": [
    {
      "cveId": "CVE-2018-7600",
      "riskScore": 95,
      "severityLabel": "High",
      "lifecyclePhase": "Exploited",
      "dateOfLifecycleChange": "2020-02-12T13:34:52Z",
      "affectedProducts": ["Website Tool 7.x"],
      "assessment": "Linked to Historical Cyber Exploit"
    }
  ],
  "page": { "limit": 20, "offset": 0, "total": 1 }
}
```

## Error Handling and Scenarios {#error-handling-and-scenarios}

Every endpoint uses the same error model. An error response includes `source`, `error`, `recoverable`, and `error_description`. The `recoverable` field indicates whether retrying could change the outcome.

The most common scenarios across all use cases are:

* `400 Bad Request`: a field fails validation, for example an out-of-range `limit` or an invalid `reason`. Correct the request and send it again.
* `403 Forbidden`: your project lacks access to the requested feature or data scope. Confirm your product enrollment, credentials, environment, and entitlements.

For detailed error questions and troubleshooting, see the [Codes and Formats](https://developer.mastercard.com/mastercard-threat-intelligence/documentation/code-and-formats/index.md) page. For the full list of status codes and error fields, see the error models in the [API Reference](https://developer.mastercard.com/mastercard-threat-intelligence/documentation/api-reference/index.md).