T09 · Insecure Skill Coding Practices
- Location
CLAUDE.md:178- Finding
Unauthenticated Gateway API exposed on all network interfaces
- Content
View full analysis
Vulnerability Details
File Locations:
CLAUDE.md:178-181EXAMPLES.md:76-79EXAMPLES.md:353-356EXAMPLES.md:398-401EXAMPLES.md:419-426
Vulnerability Type: Insecure network exposure and missing authentication
Risk Level: MediumVulnerable Code
CLAUDE.md:178-181andEXAMPLES.md:76-79recommend binding the Gateway to every available network interface:yaml server: host: 0.0.0.0 port: 18789EXAMPLES.md:353-356states that the API has no authentication by default:markdown ## ⚠️ Notes - The API has no authentication by default; authentication is recommended for production - All endpoints return JSON - Error responses contain detailed error information - HTTPS deployment is recommendedEXAMPLES.md:398-401publishes the Gateway port on the Docker host:yaml ports: - "18789:18789"EXAMPLES.md:419-426provides a plaintext HTTP reverse-proxy configuration:nginx server { listen 80; server_name your-domain.com; location / { proxy_pass http://localhost:18789; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }Technical Analysis
Binding the Gateway to
0.0.0.0makes it listen on all host interfaces rather than limiting access to the loopback interface. The Docker mapping"18789:18789"similarly publishes the service on the host's available interfaces unless a more restrictive address is specified.These settings are particularly risky because the documentation explicitly says that the API has no authentication by default. The same examples describe message, session, and Skill-management endpoints. If those endpoints are implemented and deployed as documented, any network client able to reach port
18789may be able to invoke them without proving its identity.The reverse-proxy example listens on plaintext HTTP and does not c ...[truncated 2120 chars]
- Remediation
View remediation
Remediation Suggestions
-
Use a loopback binding by default
Replace the all-interface binding with:
yaml server: host: 127.0.0.1 port: 18789Only permit a non-loopback binding when the administrator explicitly configures authentication and network restrictions.
-
Restrict Docker port publication
Bind the published port to loopback:
yaml ports: - "127.0.0.1:18789:18789"Alternatively, avoid publishing the port and place the Gateway and reverse proxy on a private Docker network.
-
Require authentication
Include a complete authentication configuration in every runnable API and production-deployment example. The service should fail closed when started on a non-loopback interface without authentication.
Use securely generated credentials or tokens supplied through a protected secret manager or environment file. Do not embed real credentials in Markdown, images, or source-controlled Compose files.
-
Provide an HTTPS production configuration
Configure TLS on the reverse proxy and redirect plaintext HTTP to HTTPS. Restrict the upstream Gateway to loopback or a private container network. Use modern TLS settings and protect authentication tokens from transmission over plaintext connections.
-
Apply network access controls
Limit access with host firewalls, cloud security groups, private networks, VPNs, or explicit IP allowlists. Port
18789should not be directly exposed to the public Internet. -
Apply endpoint authorization
Separate read-only, messaging, session-management, and Skill-management privileges. Administrative endpoints should require stronger authorization than ordinary message submission.
-
Reduce information disclosure
Return generic errors to remote clients and retain detailed diagnostics only in access-controlled server logs.
-
Correct all reusable examples
Updat ...[truncated 217 chars]
-