# Unauthenticated Third-Party Airbnb MCP Server Launch

- **Severity:** Medium
- **Signature ID:** `3f7c9a1e-2b64-4d0f-9e51-8c6a4b2d7f13`
- **MITRE ATLAS:** AML.T0010 (AI Supply Chain Compromise)
- **OWASP:** LLM03 (Supply Chain)

## Summary

This detects when a machine running AI agents launches a popular but unofficial Airbnb data connector (the hasdata-airbnb-mcp package or similar) without any credential on the command that started it. That connector has no built-in login check of its own, so once it's running, anything on the local network that can talk to it gets full use of Airbnb's hosted data API for free, with no accountability for who made the request.

## How the attack works

An operator or automated deployment process starts the third-party Airbnb MCP server as a normal process. The rule inspects the full command used to launch it. Because this package has no authentication layer, the vendor's intended security model relies entirely on a key, token, or bearer credential being passed at launch. If none of that material appears anywhere in the launch command, the server is running open: any local process that can reach its endpoint inherits full query access to the backend Airbnb data API.

## Why it matters

Any process or user on the host (or reachable over the local stdio/SSE channel) can query Airbnb data through the organization's access, with no per-caller accounting, rate limiting, or ability to revoke a single caller's access — and the organization has no record of who made which query.

## What you can do

- Confirm whether the MCP server actually needs a credential, and if so supply it via environment variable, secrets manager, or mounted secret file rather than leaving it unauthenticated.
- Restrict which local processes or users can reach the MCP server's stdio or network endpoint, even if a credential is configured elsewhere.
- Treat this as a deployment review item, not an incident: check whether the launch is a real production deployment or a developer evaluating the package, and require sign-off before it moves to production.
- If you fork or vendor this package, add your own authentication proxy in front of it before exposing it beyond a single trusted caller.

## Known benign look-alikes

- Authenticated deployment where the API key is supplied via an already-exported environment variable, a .env file, or a secrets mount rather than on the command line. The argv is then indistinguishable from an unauthenticated launch, so the rule reports it. This is the dominant expected FP and the reason the action is report rather than block.
- A developer or platform engineer legitimately evaluating the package in a sandbox or on a workstation before deciding whether to adopt it.
- A vendored or forked build that keeps the upstream package/module name while adding its own authentication proxy in front of the hosted API.
- Process supervisors (systemd, supervisord, container entrypoints) re-launching an already-approved deployment, producing one report per restart.
- A different, unrelated MCP server whose name happens to contain both "airbnb" and "mcp" (the package-name regex is deliberately widened to the whole family).

## References

- https://attack.mitre.org/techniques/T1195/002/
- https://genai.owasp.org/llmrisk/llm032025-supply-chain/
- https://atlas.mitre.org/techniques/AML.T0010

---
Source: https://www.netzilo.com/threats/unauthenticated-airbnb-mcp-server-launch