exploitability scoring

Exploitability Scoring Methodology

Overview

ClawSec's exploitability scoring system provides context-aware vulnerability assessment specifically designed for AI agent deployments (OpenClaw/NanoClaw). Unlike generic CVSS scores that treat all environments equally, our scoring considers the unique attack surface and usage patterns of AI agents to reduce alert fatigue and prioritize actionable threats.

Scoring Levels

Level	Severity	Meaning
high	Critical/High	Exploitable in typical agent deployments, immediate attention required
medium	Medium	May be exploitable depending on configuration, warrants investigation
low	Low	Limited exploitability in agent context, low priority
unknown	Unknown	Insufficient data to assess exploitability

Scoring Factors

1. CVSS Base Score (Baseline)

The analysis starts with the CVSS base score as a foundation:

• CVSS ≥ 9.0: Critical severity → initial score high
• CVSS 7.0-8.9: High severity → initial score high
• CVSS 4.0-6.9: Medium severity → initial score medium
• CVSS 1.0-3.9: Low severity → initial score low
• No CVSS: → initial score unknown

2. Attack Vector Analysis (CVSS Metrics)

The analyzer parses CVSS v2, v3.0, and v3.1 vectors to assess:

Network Accessibility

• AV:N (Network): Remotely exploitable over network
• AV:A (Adjacent): Requires local network access
• AV:L (Local): Requires local system access
• AV:P (Physical): Requires physical access

Impact on agents: Network-accessible vulnerabilities are elevated because agents typically run as network services or make external API calls.

Authentication Requirements

• PR:N / Au:NONE: No authentication required → elevates score
• PR:L / Au:SINGLE: Low privileges required
• PR:H / Au:MULTIPLE: High privileges required → reduces score

Impact on agents: Unauthenticated exploits are critical for publicly exposed agent APIs.

User Interaction

• UI:N: No user interaction required → elevates score
• UI:R: Requires user interaction → reduces score

Impact on agents: Agents often operate autonomously, so vulnerabilities requiring user interaction are less critical.

Attack Complexity

• AC:L: Low complexity → elevates score
• AC:M / AC:H: Medium/High complexity → neutral or reduces score

Impact on agents: Low-complexity exploits are more likely to be automated and used in mass attacks.

3. Vulnerability Type (Deployment Context)

ClawSec adjusts scores based on how vulnerability types affect AI agent deployments:

High-Risk Types in Agent Context

Remote Code Execution (RCE)

Score: Always HIGH
Rationale: RCE is critical in agent deployments

AI agents execute arbitrary code as part of their function. RCE vulnerabilities allow attackers to hijack agent execution flow, exfiltrate credentials, or pivot to other systems.

Server-Side Request Forgery (SSRF)

Score: Elevated to HIGH if CVSS ≥ 6.0
Rationale: SSRF affects agents making external requests

Agents frequently call external APIs, access internal services, and fetch remote resources. SSRF allows attackers to:

• Access internal cloud metadata services (AWS IMDSv1, GCP metadata)
• Pivot to internal networks
• Exfiltrate data through DNS tunneling

Path Traversal / Directory Traversal

Score: Elevated to HIGH if CVSS ≥ 6.0
Rationale: Path traversal affects agents with file access

Agents read files, execute scripts, and manage codebases. Path traversal enables:

• Reading sensitive configuration files (.env, credentials)
• Accessing SSH keys, API tokens
• Overwriting critical system files

Command Injection

Score: Always HIGH
Rationale: Command injection is critical in agent deployments

Similar to RCE, agents often execute shell commands to interact with systems. Command injection allows full system compromise.

Medium-Risk Types

Prototype Pollution (Node.js)

Score: Elevated from LOW to MEDIUM
Rationale: Prototype pollution can escalate in Node.js agents

Many agent frameworks run on Node.js. Prototype pollution can lead to:

• Bypass of authentication checks
• Privilege escalation
• Denial of service

SQL Injection / NoSQL Injection

Score: Elevated to HIGH if network-accessible and unauthenticated
Rationale: Injection affects agents with database access

Agents that store conversation history, user data, or tool results in databases are vulnerable to injection attacks.

Lower-Risk Types

Cross-Site Scripting (XSS)

Score: Reduced to MEDIUM if not network-accessible
Rationale: XSS has limited impact in headless agents

Agents typically don't render HTML in browsers, reducing XSS impact. However, XSS in agent management UIs or chat interfaces remains a concern.

4. Exploit Availability

When --check-exploits is enabled, the analyzer checks reference URLs for public exploits:

Exploit Indicators:

• exploit-db.com / exploit-database.com
• packetstormsecurity.com
• github.com/exploit, github.com/poc
• metasploit framework modules
• URLs containing "/exploit", "/poc", "/proof-of-concept"

Score Elevation:

• low → medium (exploit available)
• medium → high (exploit available)
• unknown → medium (exploit available + CVSS > 0)

Rationale: Public exploits lower the skill barrier for attackers and increase the likelihood of automated exploitation.

Scoring Algorithm

The analyzer follows this decision tree:

1. Parse CVSS score → set baseline (high/medium/low/unknown)
2. Parse CVSS vector → analyze attack characteristics
3. Adjust for attack vector:
   - Network-accessible + no auth + no UI → elevate to HIGH
   - Local-only access → reduce HIGH to MEDIUM
4. Adjust for vulnerability type:
   - Check against agent-specific risk categories
   - Elevate or reduce score based on deployment context
5. Check for public exploits (if enabled):
   - Elevate score if exploits detected
6. Generate rationale explaining the final score

Examples

Example 1: Critical RCE (High Exploitability)

{
  "cve_id": "CVE-2024-12345",
  "cvss_score": 9.8,
  "cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
  "type": "remote_code_execution",
  "description": "Unauthenticated RCE in Express.js framework"
}

Analysis Output:

{
  "exploitability_score": "high",
  "exploitability_rationale": "Critical CVSS score (9.8); remotely exploitable without authentication; RCE is critical in agent deployments"
}

Why HIGH: Critical CVSS + network accessible + no auth + RCE type.

Example 2: SSRF in Agent API (High Exploitability)

{
  "cve_id": "CVE-2024-23456",
  "cvss_score": 7.3,
  "cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
  "type": "server_side_request_forgery",
  "description": "SSRF in webhook handler allows internal network access"
}

Analysis Output:

{
  "exploitability_score": "high",
  "exploitability_rationale": "High CVSS score (7.3); remotely exploitable without authentication; SSRF affects agents making external requests"
}

Why HIGH: SSRF is critical for agents that make API calls (most do). Network-accessible without authentication elevates risk.

Example 3: Path Traversal with Public Exploit (High Exploitability)

{
  "cve_id": "CVE-2024-34567",
  "cvss_score": 6.5,
  "cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
  "type": "path_traversal",
  "references": [
    "https://exploit-db.com/exploits/51234",
    "https://nvd.nist.gov/vuln/detail/CVE-2024-34567"
  ]
}

Analysis Output (with --check-exploits):

{
  "exploitability_score": "high",
  "exploitability_rationale": "Medium CVSS score (6.5); network accessible; path traversal affects agents with file access; public exploit available (1 source)"
}

Why HIGH: Path traversal + agent file access + public exploit elevates medium CVSS to high exploitability.

Example 4: XSS in Agent UI (Medium Exploitability)

{
  "cve_id": "CVE-2024-45678",
  "cvss_score": 7.1,
  "cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L",
  "type": "cross_site_scripting",
  "description": "Stored XSS in agent management dashboard"
}

Analysis Output:

{
  "exploitability_score": "medium",
  "exploitability_rationale": "High CVSS score (7.1); network accessible; XSS has limited impact in headless agents"
}

Why MEDIUM: Despite high CVSS, XSS is less critical in agent deployments (headless operation). Requires user interaction.

Example 5: Local Privilege Escalation (Medium Exploitability)

{
  "cve_id": "CVE-2024-56789",
  "cvss_score": 8.8,
  "cvss_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
  "type": "privilege_escalation",
  "description": "Local privilege escalation via symbolic link attack"
}

Analysis Output:

{
  "exploitability_score": "medium",
  "exploitability_rationale": "High CVSS score (8.8); requires local access"
}

Why MEDIUM: Despite high CVSS, requires local access. Agents typically run in containerized/sandboxed environments where local escalation has limited impact.

Example 6: Prototype Pollution with Exploit (High Exploitability)

{
  "cve_id": "CVE-2024-67890",
  "cvss_score": 5.3,
  "cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
  "type": "prototype_pollution",
  "description": "Prototype pollution in lodash merge function",
  "references": [
    "https://github.com/exploit/prototype-pollution-poc",
    "https://snyk.io/vuln/SNYK-JS-LODASH-1234567"
  ]
}

Analysis Output (with --check-exploits):

{
  "exploitability_score": "high",
  "exploitability_rationale": "Medium CVSS score (5.3); remotely exploitable without authentication; prototype pollution can escalate in Node.js agents; public exploit available (1 source)"
}

Why HIGH: Prototype pollution in Node.js agents + public exploit + network-accessible without auth = high risk despite moderate CVSS.

Usage in ClawSec Workflows

Automated Scoring (NVD Feed)

The poll-nvd-cves.yml workflow automatically scores new CVEs:

# Workflow step
python utils/analyze_exploitability.py --json --check-exploits < cve-data.json

Advisories in advisories/feed.json can include:

{
  "id": "CVE-2024-12345",
  "severity": "high",
  "exploitability_score": "high",
  "exploitability_rationale": "Critical CVSS score (9.8); remotely exploitable without authentication; RCE is critical in agent deployments",
  "attack_vector_analysis": {
    "is_network_accessible": true,
    "requires_authentication": false,
    "requires_user_interaction": false,
    "complexity": "low"
  }
}

Manual Analysis

Security researchers can analyze CVEs manually:

# Basic analysis
echo '{"cve_id":"CVE-2024-12345","cvss_score":7.3,"type":"ssrf"}' | \
  python utils/analyze_exploitability.py --json

# With exploit detection
echo '{"cve_id":"CVE-2024-12345","cvss_score":7.3,"references":["https://exploit-db.com/exploits/51234"]}' | \
  python utils/analyze_exploitability.py --json --check-exploits

Filtering by Exploitability

Users can filter advisories by exploitability score:

# Get only high-exploitability advisories
curl -s https://clawsec.prompt.security/feed.json | \
  jq '.advisories[] | select(.exploitability_score == "high")'

# Prioritize by exploitability and severity
curl -s https://clawsec.prompt.security/feed.json | \
  jq '[.advisories[] | select(.exploitability_score == "high" and .severity == "critical")] | sort_by(.cvss_score) | reverse'

Backfilling Existing Advisories (Historical Maintenance)

scripts/backfill-exploitability.sh is retained as a historical maintainer utility for one-off repository maintenance. It is not the primary path for normal advisory generation.

Preferred paths:

1. CI canonical path: run the NVD workflow with init/reset to rebuild advisories from NVD and sign artifacts in pipeline.
2. Local developer path: run ./scripts/populate-local-feed.sh --force to repopulate local feeds with exploitability context.

Use backfill only when explicitly repairing legacy feed content that already exists in-repo.

Community Contributions

Community members can submit exploitability assessments:

1. Report via GitHub Issue: Use the advisory template to report CVEs with exploitability context
2. Automated Analysis: The community-advisory.yml workflow automatically scores community-reported CVEs
3. Manual Review: Maintainers review and approve exploitability assessments
4. Feed Update: Approved advisories are added to the feed with exploitability scores

Limitations and Future Work

Current Limitations

1. Static Analysis: Scoring is based on CVE metadata, not dynamic runtime analysis
2. No Version Detection: Doesn't check if specific versions are vulnerable
3. Binary Classification: Doesn't consider partial mitigations or defense-in-depth
4. Limited Context: Doesn't know exact agent configuration or deployed tools

Future Enhancements

1. EPSS Integration: Incorporate EPSS (Exploit Prediction Scoring System) probability scores
2. KEV Matching: Cross-reference with CISA KEV (Known Exploited Vulnerabilities) catalog
3. Agent Profiling: Consider deployed agent capabilities and exposed APIs
4. Mitigation Detection: Check for WAF rules, sandboxing, or other compensating controls
5. ML-Based Scoring: Use machine learning to predict exploitability based on historical data

References

• CVSS v3.1 Specification: https://www.first.org/cvss/v3.1/specification-document
• CVSS v2 Guide: https://www.first.org/cvss/v2/guide
• EPSS: https://www.first.org/epss/
• CISA KEV: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• NVD API: https://nvd.nist.gov/developers/vulnerabilities

Contributing

To improve the exploitability scoring methodology:

1. Submit Test Cases: Add test cases to utils/analyze_exploitability.py
2. Report False Positives/Negatives: Open GitHub issues with CVE examples
3. Propose Scoring Adjustments: Submit PRs with rationale and examples
4. Share Agent Context: Contribute agent-specific vulnerability patterns

See CONTRIBUTING.md for detailed contribution guidelines.

---

Maintained by: Prompt Security License: AGPL-3.0-or-later Last Updated: 2026-03-01