T09 · Insecure Skill Coding Practices
Warning
- Location
- pipeline-mcp.yaml:5
- Finding
- Unauthenticated Network-Exposed API Permits OpenAI Resource Abuse## Vulnerability Details **File Location**: `pipeline-mcp.yaml`, lines 5–12 **Vulnerability Type**: Unauthenticated externally exposed HTTP endpoint **Risk Level**: Medium ### Vulnerable Code ```yaml config: http: enabled: true address: "0.0.0.0:${PORT:-8080}" input: http_server: path: /detect allowed_verbs: [POST] timeout: 60s ``` ### Technical Analysis The MCP pipeline binds its HTTP service to `0.0.0.0`, making it reachable through every available network interface when host or infrastructure controls expose the selected port. The `/detect` endpoint accepts POST requests without any configured authentication or authorization control. Requests reaching this endpoint are subsequently processed using the operator-provided OpenAI API key. No explicit request-body size restriction or rate limit is present in the reviewed pipeline configuration. Consequently, any party able to reach the service can invoke the paid downstream AI operation using the deployment operator's resources. ### Attack Path 1. An operator starts `pipeline-mcp.yaml` on a host whose configured port, defaulting to TCP 8080, is reachable by an attacker. 2. The attacker discovers the exposed `/detect` endpoint. 3. The attacker sends repeated unauthenticated POST requests containing arbitrary text. 4. The pipeline forwards each accepted request to the OpenAI chat-completion processor using the operator's `OPENAI_API_KEY`. 5. Repeated or concurrent requests consume API quota and local processing capacity, potentially causing unexpected charges, throttling, or service degradation. ### Impact Assessment An attacker does not gain host-level privileges or direct access to the OpenAI API key from the reviewed configuration. However, the attacker can indirectly exercise the operator's OpenAI account through the exposed endpoint. The affected scope includes paid API quota, downstream rate limits, service availabi ...[truncated 144 chars]
- Remediation
- ## Remediation Suggestions - Bind the service to `127.0.0.1` by default unless external network access is explicitly required. - Require strong authentication, such as validated bearer tokens or mutual TLS, before requests enter the AI-processing pipeline. - Add authorization controls so each caller can access only the intended operation and quota. - Enforce strict request-body size and text-length limits before invoking OpenAI. - Apply per-client and global rate limits, concurrency limits, request timeouts, and usage quotas. - Place externally reachable deployments behind an authenticated reverse proxy or API gateway with TLS, logging, abuse detection, and network access controls. - Monitor request volume and downstream OpenAI usage, and alert on anomalous spending or traffic. - Document that exposing the default listener directly to untrusted networks is unsafe.
