Threat-intelligence correlation endpoint has dead exploit-scoring logic and returns fabricated IP/hash results with no indication they're simulated

Summary

The indicator-correlation logic behind the vulnerability/threat-intelligence feature has two distinct defects: (1) a key-name mismatch silently disables the "known public exploit" threat-score boost for every CVE indicator, and (2) IP-address and file-hash indicators are given entirely hardcoded/simulated "analysis" results — not a real lookup of any kind — with nothing in the API response distinguishing this fabricated data from the real CVE analysis returned in the same response.

Evidence

(1) Dead exploit-availability score boost — key-name mismatch:

• hexstrike_server.py:6592 (CVEIntelligenceManager.search_existing_exploits): the returned dict sets the key "exploits_found": "exploits_found": len(all_exploits),
• hexstrike_server.py:15752-15760 (the correlation route, processing CVE indicators): reads a different key that is never set: if exploits.get("success") and exploits.get("total_exploits", 0) > 0: ... "exploits_found": exploits.get("total_exploits", 0), ... correlation_results["threat_score"] += 25
• grep -n "exploits_found\|total_exploits" hexstrike_server.py shows total_exploits is read at lines 15753 and 15757 but never written anywhere in the file — exploits.get("total_exploits", 0) is therefore always 0, so the > 0 check is always False and the +25 threat-score boost (plus the "exploit_availability" correlation entry) never fires, even for a CVE with dozens of known public exploits.

(2) Fabricated IP/hash "threat intelligence": hexstrike_server.py:15765-15790:

# Process IP indicators (basic reputation check simulation)
for ip in ip_indicators:
    # Simulate threat intelligence lookup
    correlation_results["correlations"].append({
        "indicator": ip,
        "type": "ip_reputation",
        "analysis": {"reputation": "unknown", "geolocation": "unknown", "associated_threats": []},
        "threat_level": "MEDIUM"  # Default for unknown IPs
    })

# Process hash indicators
for hash_val in hash_indicators:
    correlation_results["correlations"].append({
        "indicator": hash_val,
        "type": "file_hash",
        "analysis": {"hash_type": f"hash{len(hash_val)}", "malware_family": "unknown", "detection_rate": "unknown"},
        "threat_level": "MEDIUM"
    })

Every IP indicator gets identical, input-independent output ("unknown"/"unknown"/[]/"MEDIUM"), and every hash indicator gets identical output regardless of the actual hash value — this is not a lookup against any data source, it's a fixed template, and the source comment ("simulation") confirms this was known at write time.

Why this matters

This endpoint is presented to callers as a unified indicator-correlation/threat-scoring feature (the same response structure carries real CVE analysis alongside these two indicator types). An operator or an AI agent consuming this API has no way to tell that the ip_reputation/file_hash entries are fabricated placeholders rather than real intelligence, and separately, the one piece of real signal that should most increase a CVE's computed threat score — "this CVE has known public exploits" — silently never applies due to the key mismatch, systematically under-scoring exactly the CVEs that matter most.

Attack or failure scenario

Not a remote-attacker scenario — a correctness/trustworthiness defect. An operator (or an autonomous AI agent making triage decisions from this endpoint's output) receives a threat_score that never accounts for known exploit availability, and receives ip_reputation/file_hash correlation entries that look like real threat-intelligence results but are always "unknown"/"MEDIUM" regardless of the actual indicator — potentially causing a genuinely dangerous indicator (an IP with a known-bad reputation, a hash matching known malware) to be triaged identically to a benign one.

Root cause

(1) A renamed or refactored dict key (exploits_found) was not propagated to its consumer, which still reads the old/different key name (total_exploits), silently disabling the code path instead of raising an error. (2) Placeholder/simulated logic for IP and hash indicators was left in place with no flag distinguishing it from real analysis in the API contract.

Recommended fix

(1) Fix the key mismatch — have the correlation route read exploits.get("exploits_found", 0) (or rename the producer's key to match), and add a test that would have caught this. (2) Either implement real IP-reputation/hash lookups (e.g. against an actual threat-intel source) or, at minimum, mark these correlation entries explicitly (e.g. "simulated": true) so API consumers do not mistake them for real analysis.

Acceptance criteria

• A CVE indicator with known public exploits actually receives the +25 threat-score boost and an exploit_availability correlation entry.
• IP/hash correlation entries are either backed by a real data source or explicitly marked as simulated/placeholder in the response.

Suggested labels

bug

Priority

P2

Severity

Medium — a security/threat-scoring feature silently produces misleading or under-scored output with no indication to the consumer, which is a meaningful trust/correctness problem for a tool whose entire purpose is accurate risk triage.

Confidence

Confirmed — both defects read directly and cross-referenced via grep across the full file (the producer/consumer key mismatch, and the literal simulated-response code block).