How a hosts file entry broke an AI bot's voice transcription

An AI customer service platform lost the ability to process voice notes, photos, and documents for two days in October after a routine server migration. The root cause was a single line added to the system’s hosts file, which conflicted with an existing security guard designed to prevent server-side request forgery.

What happened

The team behind DOS AI, an assistant that handles customer interactions on WhatsApp, Instagram, and Telegram, recently moved their infrastructure from a managed cloud provider to a self-hosted server. As part of the hardening process, a script modified the /etc/hosts file to pin their domain names to the loopback address 127.0.0.1. The goal was to ensure that internal calls to storage and authentication services remained functional even if external DNS resolution failed. The application would resolve its own domains locally and rely on a reverse proxy to route traffic correctly using Server Name Indication (SNI).

However, this change triggered a silent failure in the application’s media processing pipeline. When customers sent voice notes or files, the WhatsApp gateway stored them in object storage and generated a URL pointing to the company’s own domain. Before downloading any content from a user-provided or internal URL, the application runs a Server-Side Request Forgery (SSRF) guard. This security measure resolves the hostname and blocks requests to private, loopback, or link-local IP addresses to prevent attackers from accessing internal metadata endpoints.

Because the hosts file now resolved the company’s storage domain to 127.0.0.1, the SSRF guard identified the legitimate internal request as a potential security threat and blocked it. The system did not crash, nor did it log errors at a high severity level, because blocking unsafe URLs is intended behavior. Consequently, the AI assistant responded to every voice message with a default error asking users to type their request instead. Over the course of two days, the system failed to process 314 of 339 voice notes, 241 of 248 photos, and 92 of 94 documents across thirteen different projects.

Key details

• The incident occurred in October 2026 following a migration from managed cloud to self-hosted infrastructure.
• A hardening script added 127.0.0.1 sb.dosai.pro dosai.pro to the /etc/hosts file to reduce DNS dependency.
• An SSRF guard blocked downloads from these domains because they resolved to the loopback address 127.0.0.1.
• The failure was silent; refused downloads were logged as warnings, not errors, delaying detection.
• Data loss included 314 voice notes, 241 photos, and 92 documents across 13 projects over two days.
• The fix involved updating the SSRF guard to recognize specific public hostnames as safe before checking IP addresses.

Background

Server-Side Request Forgery (SSRF) is a vulnerability where an attacker tricks a server into making requests to internal resources that are not publicly accessible. To mitigate this, applications often implement guards that inspect URLs before fetching them. These guards typically resolve the hostname to an IP address and reject any request targeting private ranges (like 127.0.0.1 or 192.168.x.x). This prevents an attacker from using the server to probe its own internal network or access local metadata services.

In self-hosted environments, it is common to map public domain names to localhost in the hosts file. This ensures that internal services can communicate with each other using their public-facing names without relying on external DNS servers. However, this creates a conflict with standard SSRF protections. The security guard sees a request to a public domain that resolves to a private IP and assumes it is an attack, even though it is a legitimate internal call. Resolving this requires the security logic to distinguish between malicious rebinding attacks and intentional local routing.

Why it matters

For teams running their own software, this incident highlights the hidden complexity of combining security best practices with infrastructure optimizations. Both the hosts file modification and the SSRF guard were correct in isolation. The hosts entry improved reliability by removing DNS dependencies, and the guard protected against a serious class of vulnerabilities. The failure emerged only from their interaction, demonstrating that security controls must be aware of the specific network topology and naming conventions of the environment they protect.

The silence of the failure mode is another critical lesson. Security tools are often configured to fail closed, meaning they block suspicious activity rather than allowing it through. While this is secure, it can lead to data loss if the blocked activity is actually legitimate business traffic. Without specific alerts for blocked internal requests or monitoring of business-level metrics (such as successful transcriptions), teams may remain unaware of the issue until customers complain. In this case, the founder noticed the problem only by observing a drop in ad leads, not through system alarms.

What you can do

• Audit your SSRF guards to ensure they can distinguish between your own public domains and external threats.
• Implement exact-match hostname allowlists in security checks rather than relying solely on IP address validation.
• Configure alerts for security warnings, not just errors, to detect when legitimate traffic is being blocked.
• Monitor business-level metrics, such as successful file uploads or transcriptions, to catch functional regressions early.
• Test security fixes by mocking DNS resolution to return loopback addresses for both owned and foreign hosts.
• Document infrastructure changes like hosts file modifications and review their impact on existing security policies.