Quick Take
- What: Three AI proxy endpoints in Hugo Blog accept unauthenticated requests and forward them to upstream LLM services using the operator’s API key
- Who is affected: Operators who deploy Hugo Blog following the documented Nginx reverse-proxy setup with AI assistant features enabled
- Severity: CVSS 8.2 (High), enables unlimited quota consumption and cost exhaustion
- Status: No patch available at time of publication (commit 744ca15 and prior affected)
- What to do: Disable public access to /api/blog-assistant, /api/blog-search-embedding, and /api/blog-search-rerank endpoints until a patch is released
In plain English
A tech blog platform called Hugo Blog has a feature that lets visitors ask questions to an AI assistant. The code that handles these AI requests does not check who is making the request. Anyone on the internet can send requests that get forwarded to OpenAI or similar services, and the blog owner’s API key pays for every request. An attacker can run up the blog owner’s bill or use up their entire monthly quota, making the AI assistant stop working for real visitors.
What you should do: If you run a Hugo Blog site with the AI assistant turned on, you should block public access to those three API endpoints right away. If you just read blogs and do not run one yourself, this does not affect you.
What happened
The AI assistant proxy in lanshi17/hugo_blog contains a missing authentication vulnerability in the file server/ai-assistant-proxy.mjs. The route gate at line 249 checks only the HTTP method and path for three endpoints: POST /api/blog-assistant, POST /api/blog-search-embedding, and POST /api/blog-search-rerank. No authentication or authorization logic follows this check.
After the route check, the proxy parses the request body at line 258 and forwards the attacker-controlled payload to the upstream LLM, embedding, or rerank service at lines 368 to 380. The requestUpstream() function at lines 118 to 125 unconditionally attaches the operator’s server-side API key (OPENAI_API_KEY or AI_SEARCH_API_KEY) in the Authorization: Bearer header.
The default CORS configuration sets ALLOWED_ORIGIN to * (line 15), meaning any cross-origin browser-based attacker can also exploit the vulnerability. The documented deployment path in docs/ai-assistant-openai-compatible.md (lines 36 to 38) instructs operators to set OPENAI_API_KEY server-side, run npm run ai-proxy, and expose /api/* publicly via Nginx (docs/ai-assistant-nginx.example.conf lines 4 to 5 and 18 to 30). This makes the vulnerability present in the default documented deployment.
A proof-of-concept using Docker demonstrates that an unauthenticated HTTP POST to http://127.0.0.1:18787/api/blog-assistant returns HTTP 200, includes Access-Control-Allow-Origin: *, and causes the mock upstream to log receipt of the server API key Bearer sk-test-secret.
What you should do
Operators who have deployed Hugo Blog with the AI assistant proxy should immediately restrict public access to the three affected endpoints: /api/blog-assistant, /api/blog-search-embedding, and /api/blog-search-rerank. This can be done by modifying the Nginx configuration to require authentication or by blocking these paths entirely until a patch is released.
Monitor API usage and billing dashboards for unexpected spikes in LLM, embedding, or rerank API calls. Review server logs for POST requests to the three endpoints from unfamiliar IP addresses or user agents.
What it means
This is a CWE-306 (Missing Authentication for Critical Function) vulnerability. Any unauthenticated remote user on the internet can call the three AI proxy endpoints and cause the server to consume the operator’s LLM, embedding, or rerank API quota on their behalf.
Operators who deploy the blog following the documented Nginx reverse-proxy guide bear the full financial cost of the attacker’s LLM calls and may face sudden quota exhaustion or service disruption. End users of the blog will find the AI assistant unavailable if the operator’s API key is exhausted.
Attack scenarios include automated scripts sending high volumes of requests to exhaust API quota (Availability impact rated High in the advisory) and indirect financial damage from unbounded LLM API billing. Cross-origin browser-based abuse is also possible due to the Access-Control-Allow-Origin: * default (Integrity impact rated Low). The vulnerability is exploitable with zero prior access and no credentials.
