explain how misconfigurations work

api-reference/enumerations/list-enumeration-misconfigurations.mdx

@@ -6,8 +6,24 @@
 
 | Type | Description |
 |---|---|
-| `dangling_dns` | DNS records pointing to resources that no longer exist, potentially vulnerable to subdomain takeover |
-| `origin_exposure` | Backend origin IPs exposed behind CDN or proxy services |
+| `dangling_dns` | AWS Elastic IPs that no longer exist, leaving DNS records vulnerable to subdomain takeover |
+| `origin_exposure` | Cloudflare-proxied origin IPs independently discoverable through other hostnames |
+
+### AWS Dangling DNS
+
+A dangling DNS finding is reported when a DNS record points to an AWS Elastic IP that no longer exists, making it potentially vulnerable to subdomain takeover. Requires an AWS cloud integration.
+
+### Cloudflare Origin IP Exposure
+
+When a domain is proxied through Cloudflare, its origin server IP is hidden behind Cloudflare's network. An origin exposure finding indicates that this origin IP is independently discoverable through another hostname that resolves to it directly, without going through Cloudflare.
+
+This finding requires two things:
+
+1. **A Cloudflare cloud integration** — This allows us to read your DNS records and identify which hostnames are proxied and what origin IPs they point to.
+
+2. **Asset inventory** — Hostnames and their resolved IPs from your attack surface discovery. The check runs against your entire inventory, excluding assets sourced from cloud integrations.
+
+When a hostname from your inventory resolves to the same IP as the origin behind one of your proxied Cloudflare records, it is flagged as an origin exposure finding.
 
 ### Event Details by Finding Type
 
@@ -16,7 +32,7 @@
 **`dangling_dns`**
 | Field | Description |
 |---|---|
 | `host` | The vulnerable hostname |
 | `ip` | The dangling IP address |
 | `provider` | Cloud provider (e.g., AWS) |
 
@@ -24,12 +40,12 @@
 | Field | Description |
 |---|---|
 | `origin_ip` | The exposed origin server IP |
-| `provider` | CDN provider (e.g., CloudFlare) |
-| `leaking_hosts` | Hostnames leaking the origin IP |
+| `provider` | CDN provider (e.g., Cloudflare) |
+| `leaking_hosts` | The hostnames from your inventory that resolve directly to the origin IP |
 
 ## Example Requests
 
 ### List all misconfigurations
 
 ```bash
 curl -X GET "https://api.projectdiscovery.io/v1/asset/enumerate/misconfiguration?limit=50" \

cloud/integrations.mdx

@@ -18,7 +18,7 @@
   <Card title="Webhook" icon="webhook" href="#webhook">
 
   </Card>
   <Card title="Jira" icon="jira" href="#jira">
 
   </Card>
   <Card title="GitHub" icon="github" href="#github">
@@ -48,7 +48,7 @@
   <Card title="Cloudflare" icon="cloudflare" href="#cloudflare">
 
   </Card>
   <Card title="Fastly" icon="bolt" href="#fastly">
 
   </Card>
   <Card title="DigitalOcean" icon="digital-ocean" href="#digitalocean">
@@ -188,7 +188,7 @@
   },
 
   "finished": null,
   "failed_stopped": null
 }
 ```
 
@@ -276,8 +276,8 @@
     - `medium` — Medium severity count
     - `low` — Low severity count
     - `info` — Info severity count
   - `rescan_new_vulnerabilities` — New vulns since last scan, rescans only (integer)
   - `rescan_vulns_list` — List of new vulnerabilities, **max 15 items**, rescans only (array)
     - `Name` — Vulnerability name/title
     - `Severity` — Severity level (critical, high, medium, low, info)
     - `Count` — Number of instances found
@@ -385,7 +385,7 @@
     <Accordion title="Enumeration Finished" icon="circle-check">
 
 <Info>
 **Trigger:** When asset disocvery completes successfully
 
 **Type:** `finished`
 </Info>
@@ -442,7 +442,7 @@
   - `total_assets` — Total number of assets in inventory (integer)
   - `new_assets` — Number of newly discovered assets (integer)
   - `new_assets_list` — Details of newly discovered assets (array)
     - `host` — Hostname or domain name
     - `port` — Port number
     - `ip` — List of IP addresses associated with the host (array of strings)
   </Accordion>
@@ -506,7 +506,7 @@
 
 **Type:** `new_vuln`
 
 **Note:** This event is only triggered for rescans when comparing against previous results
 </Info>
 
 ```json New Vulnerability Alert Payload
@@ -575,7 +575,7 @@
 </Tip>
 
 <Note>
 If you configured severity filters (e.g., only Critical and High), only new vulnerabilities matching those severities will trigger this event and be included in the `rescan_vulns_list`.
 </Note>
     </Accordion>
 
@@ -586,7 +586,7 @@
 
 **Type:** `new_asset`
 
 **Configuration:** Can be enabled for disocvery, scan, or both based on your alerting configuration
 </Info>
 
 ```json New Asset Alert Payload
@@ -651,7 +651,7 @@
   - `total_assets` — Total number of assets in your inventory (integer)
   - `new_assets` — **Number of NEWLY discovered assets** (integer)
   - `new_assets_list` — **List of NEWLY discovered assets only** (array)
     - `host` — Hostname or domain name
     - `port` — Port number
     - `ip` — List of IP addresses associated with the host (array of strings)
   </Accordion>
@@ -667,7 +667,7 @@
 
 ## Ticketing Integrations
 
 The integrations under Ticketing support ticketing functionality as part of scanning and include support for Jira, GitHub, GitLab, and Linear. Navigate to [Scans → Configurations → Ticketing](https://cloud.projectdiscovery.io/scans/configs?type=reporting) to configure your ticketing tools.
 
 <img
   height="300"
@@ -676,9 +676,9 @@
 
 ### Jira
 
 ProjectDiscovery provides integration support for Jira to create new tickets when vulnerabilities are found.
 
 Provide a name for the configuration, the Jira instance URL , the Account ID, the Email, and the associated API token.
 
 Details on creating an API token are available [in the Jira documentation here.](https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/)
 
@@ -689,7 +689,7 @@
 Provide a name for the configuration, the Organization or username, Project name, Issue Assignee, Token, and Issue Label. The Issue Label determines when a ticket is created. (For example, if critical severity is selected, any issues with a critical severity will create a ticket.)
 
 - The severity as label option adds a template result severity to any GitHub issues created.
 - Deduplicate posts any new results as comments on existing issues instead of creating new issues for the same result.
 
 Details on setting up access in GitHub [are available here.](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)
 
@@ -701,7 +701,7 @@
 (For example, if critical severity is selected, any issues with a critical severity will create a ticket.)
 
 - The severity as label option adds a template result severity to any GitLab issues created.
 - Deduplicate posts any new results as comments on existing issues instead of creating new issues for the same result.
 
 Refer to GitLab's documentation for details on [configuring a Project Access token.](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token)
 
@@ -756,7 +756,7 @@
   Click here to open the AWS integration configuration page in the ProjectDiscovery Cloud platform
 </Card>
 
 ProjectDiscovery's AWS integration allows the platform to automatically discover and monitor cloud assets across your AWS accounts. By connecting AWS to ProjectDiscovery, security teams and DevOps engineers gain continuous visibility into EC2 instances, S3 buckets, DNS records, and other resources without manual inventory. This integration leverages ProjectDiscovery's open-source **Cloudlist** engine to enumerate assets via AWS APIs. In short, it helps ensure no cloud asset goes unnoticed, enabling proactive security monitoring and easier management of your attack surface.
 
 <img
   src="/images/aws-integration.png"
@@ -768,7 +768,7 @@
 
 | Service                                               | Description                                   |
 | :---------------------------------------------------- | :-------------------------------------------- |
 | [EC2](https://aws.amazon.com/ec2/)                    | VM instances and their public IPs             |
 | [Route53](https://aws.amazon.com/route53/)            | DNS hosted zones and records                  |
 | [S3](https://aws.amazon.com/s3/)                      | Buckets (especially those public or with DNS) |
 | [Cloudfront](https://aws.amazon.com/cloudfront/)      | CDN distributions and their domains           |
@@ -776,8 +776,8 @@
 | [EKS](https://aws.amazon.com/eks/)                    | Kubernetes cluster endpoints                  |
 | [ELB](https://aws.amazon.com/elasticloadbalancing/)   | Load balancers (Classic ELB and ALB/NLB)      |
 | [ELBv2](https://aws.amazon.com/elasticloadbalancing/) | Load balancers (Classic ELB and ALB/NLB)      |
 | [Lambda](https://aws.amazon.com/lambda/)              | Serverless function endpoints                 |
 | [Lightsail](https://aws.amazon.com/lightsail/)        | Lightsail instances (simplified VPS)          |
 | [Apigateway](https://aws.amazon.com/api-gateway/)     | API endpoints deployed via Amazon API Gateway |
 
 By covering these services, ProjectDiscovery can map out a broad range of AWS assets in your account. (Support for additional services may be added over time.)
@@ -856,7 +856,7 @@
 - S3 - AmazonS3ReadOnlyAccess
 - Lambda - AWSLambda_ReadOnlyAccess
 - ELB - ElasticLoadBalancingReadOnly
 - Cloudfront - CloudFrontReadOnlyAccess
 
 Alternatively, you can use this custom policy for minimal permissions:
 
@@ -904,7 +904,7 @@
 - **Troubleshooting Errors:** If the integration fails or some assets are missing, consider these common issues:
   - _Incorrect Credentials:_ Double-check that the Access Key and Secret (if used) were entered correctly and correspond to an active IAM user. If you recently created the user, ensure you copied the keys exactly (no extra spaces or missing characters).
   - _Insufficient Permissions:_ If certain services aren't showing up, the IAM policy might be missing permissions. For example, if S3 buckets aren't listed, confirm that the policy includes `s3:ListAllMyBuckets`. Refer back to the Required Permissions and make sure all relevant actions are allowed. You can also use AWS IAM Policy Simulator or CloudTrail logs to see if any **AccessDenied** errors occur when ProjectDiscovery calls AWS APIs.
   - _Assume Role Failures:_ In multi-account or cross-account setups, a common issue is a misconfigured trust relationship. If ProjectDiscovery cannot assume a role, you might see an error in the UI or logs like "AccessDenied: Not authorized to perform sts:AssumeRole". In that case, check the following:
     - The trust policy of the IAM role (in target account) trusts the correct principal (either your primary account's IAM user/role ARN for multi-account, or ProjectDiscovery's external account ID for cross-account) and the External ID if applicable.
     - The role name or ARN in the ProjectDiscovery config exactly matches the one in AWS (spelling/case must match).
     - The primary credentials (for multi-account) have permission to call `AssumeRole`.
@@ -915,9 +915,9 @@
 
 #### API Setup
 
 You can set up the AWS integration entirely through the API. The process involves creating a cloudlist configuration, verifying it, and then using it to create an enumeration.
 
 The cloudlist configuration is a YAML array that must be **base64-encoded** before sending it to the API. Each connection method uses a different YAML structure, but the API calls are the same.
 
 **Configuration Format**
 
@@ -925,9 +925,9 @@
   <Accordion title="Single AWS Account (Access Key & Secret)">
     ```yaml
     - provider: aws
       aws_access_key: "AKIAIOSFODNN7EXAMPLE"
       aws_secret_key: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
       aws_session_token: "optional-session-token"
       services:
         - ec2
         - route53
@@ -938,10 +938,10 @@
   <Accordion title="Multiple AWS Accounts (Assume Role)">
     ```yaml
     - provider: aws
       aws_access_key: "AKIAIOSFODNN7EXAMPLE"
       aws_secret_key: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
       assume_role_name: "ProjectDiscoveryReadOnlyRole"
       account_ids:
         - "123456789012"
         - "987654321098"
       services:
@@ -954,9 +954,9 @@
   <Accordion title="Cross-Account Role (Role ARN)">
     ```yaml
     - provider: aws
       assume_role_arn: "arn:aws:iam::123456789012:role/ProjectDiscoveryRole"
       external_id: "your-external-id"
       assume_role_session_name: "projectdiscovery_role"
       services:
         - ec2
         - route53
@@ -1000,7 +1000,7 @@
 
 **Step 2: Create the Integration**
 
 Once verified, send the base64-encoded configuration to create a cloudlist config:
 
 ```bash
 curl -X POST https://api.projectdiscovery.io/v1/scans/config \
@@ -1060,9 +1060,9 @@
 |:---|:---|
 | [Cloud DNS](https://cloud.google.com/dns) | DNS zones and records |
 | [Kubernetes Engine](https://cloud.google.com/kubernetes-engine) | GKE cluster endpoints |
 | [Compute Engine](https://cloud.google.com/products/compute) | VM instances and public IPs |
 | [Cloud Storage](https://cloud.google.com/storage) | Buckets |
 | [Cloud Functions](https://cloud.google.com/functions) | Serverless function endpoints |
 | [Cloud Run](https://cloud.google.com/run) | Container service URLs |
 
 #### Enumeration Scope
@@ -1402,7 +1402,7 @@
 <Note>
 `YOUR_PROJECT_NUMBER` is the numeric project number, not the project ID. Find it with:
 ```bash
 gcloud projects describe YOUR_PROJECT_ID --format='value(projectNumber)'
 ```
 </Note>
 
@@ -1616,7 +1616,7 @@
 
    - If you only need specific services, you can further reduce actions. For example:
      - Virtual machines: `Microsoft.Compute/virtualMachines/read`, plus RG/subscription reads
      - Public IPs: `Microsoft.Network/publicIPAddresses/read`
      - Traffic Manager: `Microsoft.Network/trafficManagerProfiles/read`
      - Storage Accounts: `Microsoft.Storage/storageAccounts/read`
      - AKS Clusters: `Microsoft.ContainerService/managedClusters/read`
@@ -1639,9 +1639,9 @@
 
 
 
 ### Alibaba Cloud
 
 <Card title="Configure Alibaba Cloud Integration" icon="cloud" color="#FF6A00" href="https://cloud.projectdiscovery.io/assets/configure?provider=alibaba">
   Click here to open the Alibaba Cloud integration configuration page in the ProjectDiscovery Cloud platform
 </Card>
 
@@ -1652,13 +1652,13 @@
   style={{ width:"62%" }}
 />
 
 Supported Alibaba Cloud Services:
 
 - ECS Instances
 
 **Alibaba Integration Method**
 
 This guide details the secure, best-practice method for connecting to Alibaba Cloud using a dedicated RAM user with read-only permissions.
 
 1. **Create a RAM User for API Access:**
    - Navigate to the **RAM (Resource Access Management) console**. [Ref](https://ram.console.aliyun.com/manage/ak)
@@ -1676,11 +1676,11 @@
    - Select the **System Policy** type.
    - Search for and select the `AliyunReadOnlyAccess` policy and click **OK**. This is the official, managed policy for read-only access to all cloud resources.
 4. **Find Your Region ID and Connect:**
    - Identify the **Region ID** for the resources you plan to monitor. You can find the official list in the Alibaba Cloud documentation here: [Regions and zones](https://www.alibabacloud.com/help/en/doc-detail/40654.htm) (This link lists the specific IDs required for API configuration).
    - Use the credentials you have collected to fill in the fields in ProjectDiscovery:
      - **Alibaba Region ID**: The target region, for example, `us-east-1`.
      - **Alibaba Access Key**: The AccessKey ID from Step 2.
      - **Alibaba Access Key Secret**: The AccessKey Secret from Step 2.
    - Enter a unique **Integration Name** and click **Verify**.
 
 References:
@@ -1721,8 +1721,8 @@
   - Clusters with public IP addresses
 </Note>
 
 1. **Prepare Base64-Encoded Kubeconfig**
    - Your kubeconfig file is typically located at:
 
      ```
      ~/.kube/config
@@ -1732,11 +1732,11 @@
      ```
      cat ~/.kube/config | base64
      ```
    - Paste the output into the **Kubeconfig** field in the UI.
 
      > ⚠️ Ensure the entire content is copied without extra whitespace.
 2. **Specify Context (Optional)**
    - If your kubeconfig has multiple contexts, find them with:
 
      ```
      kubectl config get-contexts
@@ -1755,7 +1755,7 @@
 
 If your Kubernetes integration fails, the most common cause is cluster accessibility:
 
 - **Internal Clusters**: Clusters only accessible within private networks (VPN, internal VPCs) cannot be reached by ProjectDiscovery
 - **Firewall Restrictions**: Ensure your cluster's API server and services are accessible from the internet
 - **Network Policies**: Check that network policies allow external access to required endpoints
 - **Load Balancer Configuration**: Verify that external load balancers are properly configured and accessible
@@ -1785,6 +1785,10 @@
 
 - DNS and CDN assets
 
+<Note>
+  Connecting a Cloudflare integration also enables **origin IP exposure** detection under [Misconfigurations](/api-reference/enumerations/list-enumeration-misconfigurations). When a hostname from your asset inventory resolves to the same IP as the origin behind one of your proxied Cloudflare records, it is flagged as an origin exposure finding.
+</Note>
+
 **Cloudflare Integration Methods:**
 
 You can integrate Cloudflare into ProjectDiscovery via one of two methods:
@@ -1821,7 +1825,7 @@
 
 ### Fastly
 
 <Card title="Configure Fastly Integration" icon="bolt" color="#FF282D" href="https://cloud.projectdiscovery.io/assets/configure?provider=fastly">
   Click here to open the Fastly integration configuration page in the ProjectDiscovery Cloud platform
 </Card>
 
@@ -1832,16 +1836,16 @@
   style={{ width:"65%" }}
 />
 
 **Fastly Integration Method**
 
 - Go to Fastly [account settings](https://manage.fastly.com/account/personal).
 - Under **API**, click **Create API token** if you don’t already have one.
 - Copy the API Key.
 - Now enter API Key in ProjectDiscovery Cloud Platform.
 - Give a unique Integration name and click **Verify**.
 
   <Tip>
     Tip: In Fastly's documentation and interfaces, "API Key" and "API Token" refer to the same thing. You can use the terms interchangeably throughout this guide.
   </Tip>
 
 References:

openapi.yaml

@@ -13959,7 +13959,7 @@ paths:
     get:
       summary: List Misconfiguration Findings
       description: >-
-        Retrieve infrastructure misconfiguration findings discovered during asset enumeration, such as dangling DNS records and origin IP exposures.
+        Retrieve infrastructure misconfiguration findings discovered during asset enumeration. Currently detects AWS dangling DNS (Elastic IPs that no longer exist) and Cloudflare origin IP exposure.
       tags: []
       responses:
         '200':
@@ -18561,7 +18561,7 @@ components:
           enum:
             - dangling_dns
             - origin_exposure
-          description: Type of infrastructure misconfiguration
+          description: 'Type of misconfiguration: dangling_dns (AWS Elastic IP no longer exists) or origin_exposure (Cloudflare origin IP leaked)'
         host:
           type: string
           description: The affected hostname or domain
@@ -18590,7 +18590,7 @@ components:
         event:
           type: object
           additionalProperties: true
-          description: 'Type-specific finding details. For dangling_dns: host, ip, provider. For origin_exposure: provider, origin_ip, leaking_hosts.'
+          description: 'Type-specific finding details. For dangling_dns: host, ip, provider (AWS). For origin_exposure: provider (Cloudflare), origin_ip, leaking_hosts.'
         created_at:
           type: string
           format: date