01 Executive Summary
This assessment covered Meridian Mutual's external attack surface and authorized network — including authenticated testing behind the customer-portal login — run on a continuous weekly cadence. GhostTrace evaluated 23 candidate findings and reported 6 proven exposures — every one demonstrated with captured evidence, not inferred from version numbers. The remaining 17 candidates did not clear the proof gates and are retained in the run artifacts, not surfaced here as findings. One critical exposure — a cross-tenant authorization flaw where one customer's authenticated session reads another customer's policy documents — was chained by the reasoning engine with two lower-severity findings into a single high-impact attack path (see §04). All findings below include a reproduction you can run yourself. Nothing in this report was tested outside the authorized scope; the scope governor logged 2,738 allowed and 542 denied requests with zero unauthorized widenings.
147 assets discovered
23 candidates evaluated
6 proven (Tier 3+)
5 Tier 4 · 1 Tier 3
100% findings with evidence
reconciliation: 9→6 (3 chain-noise dropped)
02 What "proven" means here
Every candidate below cleared four independent evidence gates, then an authenticity check on the evidence itself. A finding is Tier 4 when all gates pass and authenticity is verified; Tier 3 when the gates pass but authenticity is still pending (shown with the caveat, never hidden). Anything below Tier 3 is not reported as proven.
G1
Reachability
Reachable from outside
G2
Signal
Genuine, not coincidental
G3
Exploitability
Can be acted on
G4
Impact
Concrete consequence
+
AUTHENTICITY
Is the evidence itself genuine?
Confirms the response came from the real target over a real network path — not a test shortcut or a self-asserted chain result. Passing promotes a finding from Tier 3 to Tier 4.
03 Detailed Findings
Cross-tenant authorization flaw — one customer's session reads another's policy documents (IDOR)
GET https://api.meridian-demo.example/v2/policies/{id}/documents
G1 reachable ✓G2 signal ✓G3 exploitable ✓G4 impact ✓authenticity ✓
The issue
GhostTrace authenticated as a standard tenant-A portal user (credentials provided for the engagement) and requested policy object IDs belonging to tenant B. The endpoint confirms the caller is authenticated but never checks that the caller's tenant owns the object — so any logged-in customer can read any other customer's documents by changing the ID. Adjacent IDs 88410–88414 returned distinct tenants' objects, confirming the identifiers are enumerable. This finding is only reachable behind the login; a public-surface-only scan would miss it entirely.
Evidence — request & response
# authenticated as tenant A; request tenant B's object
GET /v2/policies/88412/documents HTTP/2
Host: api.meridian-demo.example
Authorization: Bearer <tenant-A session>
# response
HTTP/2 200 OK ← expected 403 / 404
{"policy_id": 88412, "owner_tenant": "tenant-B", "documents": [
{"id":"doc-001","title":"Policy schedule"},
{"id":"doc-002","title":"Claims history"} ]}
✓ cross-tenant object returned · captured in response.raw
Remediation
Enforce object ownership in the data layer, not the handler: scope the query by the authenticated account (WHERE id = :id AND account_id = :caller) and return 404 on no match to avoid existence disclosure. The sibling endpoints /v2/policies/{id} and /v2/policies/{id}/claims share the handler shape and need the same fix. Add a negative-path test per endpoint.
Reproduce it yourself
curl -i -H "Authorization: Bearer $TENANT_A" \
"https://api.meridian-demo.example/v2/policies/88412/documents"
→ HTTP 200 with tenant B's object while the flaw exists; 403/404 once fixed.
Forgotten staging environment exposing an unauthenticated admin panel
https://claims-staging.meridian-demo.example/admin
G1 reachable ✓G2 signal ✓G3 exploitable ✓G4 impact ✓authenticity ✓
The issue
Surface discovery found claims-staging.meridian-demo.example via certificate transparency — a staging host not in the known asset inventory. Its /admin console loads without any authentication and exposes claims-management actions against what appears to be a copy of production data. Forgotten staging environments are a leading source of breaches precisely because they fall outside normal monitoring.
Evidence
# discovered via cert transparency, confirmed reachable
GET /admin HTTP/2
Host: claims-staging.meridian-demo.example
HTTP/2 200 OK
# rendered admin console, no login redirect, no session required
Claims Admin · Meridian (staging)
✓ authenticated-only console reachable with no session
Remediation
Take the staging host off the public internet (IP allowlist or VPN), or decommission it. If it must be reachable, put it behind the same authentication as production and scrub production data. Add the host to your asset inventory so it's covered by monitoring going forward.
SQL injection in the policy search parameter
GET https://api.meridian-demo.example/v2/search?q=
G1 reachable ✓G2 signal ✓G3 exploitable ✓G4 impact ✓authenticity pending
The issue
The q parameter is concatenated into a SQL query. A boolean-based payload produced a reliable, reproducible difference in response size between true and false conditions, confirming injectable context. Reported at Tier 3: the four gates passed, but the authenticity layer could not fully confirm the evidence path on this run (an intermediate cache produced ambiguous timing). It is shown here with that caveat rather than withheld — re-verification is scheduled for the next run.
Evidence — boolean differential
# true condition
/v2/search?q=aviva' AND '1'='1 → 200, 14,204 bytes
# false condition
/v2/search?q=aviva' AND '1'='2 → 200, 1,118 bytes
✓ consistent size swing across 5 trials · injectable context confirmed
Remediation
Replace string concatenation with parameterized queries / prepared statements for the search path. Add a WAF rule as defense-in-depth, not as the fix. Re-run the included test after deploying to confirm the differential is gone.
Verbose error response discloses internal hostnames and stack paths
POST https://api.meridian-demo.example/v2/quotes
G1 reachable ✓G2 signal ✓G3 exploitable ✓G4 impact ✓authenticity ✓
The issue
A malformed request body triggers an unhandled exception whose 500 response leaks the internal hostname mdb-primary.internal, a filesystem path, and the ORM version. Individually low-impact, but this is reconnaissance an attacker uses to target the next stage — and it feeds the chain in §04.
Remediation
Return a generic error body to clients; log the detail server-side only. Set the framework to production error mode so stack traces and internal identifiers are never emitted in responses.
No rate limiting on the authentication endpoint
POST https://api.meridian-demo.example/auth/login
G1 reachable ✓G2 signal ✓G3 exploitable ✓G4 impact ✓authenticity pending
The issue
The login endpoint accepted 500 sequential credential attempts in 60 seconds with no throttling, lockout, or challenge — enabling credential-stuffing and password-spray at scale. Reported at Tier 3 pending authenticity re-confirmation of the timing evidence.
Remediation
Add per-account and per-IP rate limiting with exponential backoff, plus a challenge (CAPTCHA / step-up) after a threshold. Monitor for distributed attempts across many accounts, which per-IP limits alone miss.
Missing security headers on the public marketing host
https://www.meridian-demo.example
G1 reachable ✓G2 signal ✓G3 exploitable ✓G4 impact ✓authenticity ✓
The issue
The public site is served without Content-Security-Policy, Strict-Transport-Security, or X-Content-Type-Options. Low direct impact, but these headers are cheap defense-in-depth and their absence is a common audit finding.
Remediation
Add HSTS, a baseline CSP, and X-Content-Type-Options: nosniff at the edge or web server. These are configuration changes with no application code impact.
04 Attack Chain — the reasoning engine at work
◆ AI reasoning engine · chained finding
Individually, these findings look mid-severity — the kind of items that sit unprioritized in a scanner queue for months. The reasoning engine identified that together they form a single, practical path from the public internet to reading every customer's claims data. Chained, this is a critical exposure.
High · GT-2044
Unauthenticated staging console yields a working portal session
Medium · GT-2052
Error leak maps the internal API host mdb-primary.internal
Critical · GT-2041
That session abuses the cross-tenant IDOR to read every tenant's documents
Result: an attacker starts unauthenticated, obtains a low-privilege portal session through the exposed staging console, then abuses the cross-tenant authorization flaw to read every customer's policy and claims documents. The critical link (GT-2041) was only found because GhostTrace tested behind the login — a public-surface scan stops at the staging console. Fixing GT-2041 breaks the chain; the report flags all three.
05 Surface Inventory — EASM discovery (excerpt)
| Asset | Type | Discovery | Status |
|---|
| meridian-demo.example | Apex domain | In scope | Verified |
| api.meridian-demo.example | API host | DNS enumeration | Verified |
| www.meridian-demo.example | Web host | DNS enumeration | Verified |
| claims-staging.meridian-demo.example | Staging host | Cert transparency | New — flagged |
| vpn.meridian-demo.example | Gateway | DNS enumeration | Verified |
| mdm-legacy.partner-cdn.net | 3rd-party host | DNS correlation | Out of scope — denied |
147 assets discovered in total. Out-of-scope assets (e.g. third-party CDNs) are surfaced for awareness but never scanned — the scope governor denied 542 such requests this run. Full inventory and the scope ledger ship in the run artifacts.