Post cover image

September 3, 2026

How a Simple Dork Led to a Critical 10.0 CVSS

A critical (CVSS 10.0) vulnerability does not necessarily involve a complicated zero-day attack chain. At times, simple misconfigurations…

By 0x7ipher

3 min read

A critical (CVSS 10.0) vulnerability does not necessarily involve a complicated zero-day attack chain. At times, simple misconfigurations can provide attackers with a key to an unlocked front door.

Disclaimer: This paper is only intended for informative and educational use. The vulnerability described here in has been identified by a Vulnerability Disclosure Program (VDP) during a designated testing period. All sensitive information that includes identifiers, domain names, and any other organization-related information has been properly anonymized or substituted with generic terms to comply with non-disclosure requirements and target privacy. No data modification has occurred in the course of anonymizing the test data.

Technical Overview

  • Vulnerability Class: CWE-538 (Insertion of Sensitive Information into Externally-Accessible File or Directory)
  • Severity: Critical (CVSS v3.1: 10.0 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
  • Target Impact: Active API Token Disclosure & External Credential Compromise

Recently, while conducting a legitimate penetration test for a public Vulnerability Disclosure Program (VDP), I came across an exposed Laravel config file revealing live credentials for a third party. Here is how the discovery was made, as well as the process used to validate the issue.

Step 1: Dorking (The Entry Point)

The discovery took place at the reconnaissance stage. During the process of subdomain enumeration and indexing, I applied **GHDB (**Google Hacking Database) operators to search for publicly indexed environment files from the target endpoints:

site:*.target.com ".env"
None

Google Dorking may frequently expose some assets that have had their environment configuration files inadvertently indexed by the crawlers because of lack of proper access permissions or robots.txt. One of the search results exposed a live host with directory indexing enabled.

Step 2: Public Directory Listing

Direct access to the root domain https://subdomain.target.com/ showed that directory listings were enabled across all web server directories.

Rather than loading the production front-end compiled by the framework from its /public directory, the web server was improperly set up to load the whole application root directory.

Some of the listed directories were:

None

Step 3: Exposed .env Configuration

Access to the .env endpoint through https://subdomain.target.com/.env needed no authentication whatsoever. The application provided all the environmental settings in plaintext format.

The exposed file included valuable operational secrets:

  1. Application Framework Key: APP_KEY
  2. Database Access Keys: DB_USERNAME, DB_PASSWORD
  3. External Services: Zoom API keys and tokens (ZOOM_CLIENT_SECRET)
  4. Messaging Gateway: Twilio Account SID, Twilio Auth Token (TWILIO_SID, TWILIO_AUTH_TOKEN, TWILIO_VERIFY_SID)
None None

Step 4: Credential Validation (Twilio Authentication)

In order to achieve maximum impact without any breach of authorization procedures or any disturbance in operations, a non-destructive verification was done.

The following read-only authentication powershell script was made against the Twilio API through the exposed Account SID and Auth Token:

$SID="TWILIO_SID"
$TOKEN="TWILIO_AUTH_TOKEN"

$B64=[Convert]::ToBase64String(
    [Text.Encoding]::ASCII.GetBytes("${SID}:${TOKEN}")
)

$URL="https://api.twilio.com/2010-04-01/Accounts/$SID.json"

try {
    $r=Invoke-WebRequest `
        -Uri $URL `
        -Method GET `
        -Headers @{Authorization="Basic $B64"} `
        -ErrorAction Stop

    Write-Host ""
    Write-Host "========== TWILIO CREDENTIAL VALIDATION ==========" -ForegroundColor Cyan
    Write-Host "Timestamp:   $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss K')"
    Write-Host "Endpoint:    https://api.twilio.com/2010-04-01/Accounts/${SID}.json"
    Write-Host "HTTP Status: $($r.StatusCode)"

    $data=$r.Content | ConvertFrom-Json

    Write-Host "Account SID: $($data.sid)"
    Write-Host "Status:      $($data.status)"
    Write-Host "Type:        $($data.type)"
    Write-Host "==================================================" -ForegroundColor Cyan
}
catch {
    Write-Host ""
    Write-Host "========== REQUEST FAILED ==========" -ForegroundColor Red

    if ($_.Exception.Response) {
        Write-Host "HTTP Status: $([int]$_.Exception.Response.StatusCode)"
    }

    Write-Host "Error: $($_.Exception.Message)"
    Write-Host "===================================="
}
None

Testing Limitations & Responsible Disclosure

In strict accordance with responsible disclosure guidelines:

  1. No Harmful Operations: There were no messages sent, no modification of resources, no access to user data, and no destructive actions conducted using the validated credentials.
  2. Immediate Notification: This finding was immediately reported on the VDP reporting portal.
  3. Data Sanitization: All sensitive keys and real domain names have been redacted in the reporting evidence package.

Thank you for reading. I hope you enjoyed this story and found it helpful.😊

None