Supported deployment default exposes a protected service
A supported installation path creates permissive service exposure or permissions that contradict the product's stated deployment boundary.
Candidate CWE: CWE-276
Test hypothesis#
Freeze the documented install inputs, render with synthetic values, deploy in the owned lab and compare one canary operation from allowed and disallowed network positions. Change only the implicated setting and repeat.
Evidence required#
Versioned installation instructions, values, rendered resource, actual endpoint and unauthorized canary result alongside the corrected default.
Rule out false positives#
Development-only templates, operator-added unsafe overrides, a public port still protected by appropriate authentication, or a rendered rule never deployed.
Playbook and command references#
- Infrastructure configuration: from repository default to deployed impact — Trace IaC, charts, Compose and image packaging into supported deployments, including exposed services and sensitive artifacts.
- Database, cache, queue and management service boundaries — Move from a reachable socket to a minimal proof of unintended service authority using synthetic records and paired identities.
Find the associated command snippets
Referenced by these target playbooks#
Report checklist#
- Capture the affected version, configuration, identities, and object ownership.
- Preserve a valid baseline and a negative control.
- Reproduce the forbidden data access, action, or state change on controlled fixtures.
- Explain the intended security rule and why the observed behavior violates it.
- State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.
Conditional ATT&CK mapping#
No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the mapping guide.