When /etc/h*sts Breaks Your Substack Editor: An Adventure in Web Content Filtering

An exploration of web security mechanisms and their unexpected consequences

The Mysterious Network Error

I was working on a technical post about DNS resolution when I encountered something unexpected. Every time I typed the path to the hosts file (/etc/h*sts - intentionally obfuscated to avoid triggering the very issue I'm discussing), my Substack editor would display a "Network Error" and fail to autosave my draft.

At first, I assumed Substack was experiencing an outage. However, their status page showed all systems operational. Something else was happening.

The Investigation Begins

I noticed this error appeared consistently when I typed that specific file path. But when I wrote variations like /etc/h0sts or /etchosts, the editor worked fine. Curious about this pattern, I tested more system paths:

Path                  Result
/etc/h*sts            ❌ Error
/etc/h0sts            ✅ Works
/etchosts             ✅ Works
/etc/pass*d           ❌ Error
/etc/password         ✅ Works
/etc/ssh/sshd_conf*g  ❌ Error
/etc/ssh              ✅ Works
/etc/h*sts.allowed    ❌ Error
/etc/h*sts.foo        ❌ Error

(Note: the * is used to replace the actual character in the paths that result in an error)

A pattern emerged: paths to common Linux system configuration files were triggering errors, while slight variations sailed through.

What's Happening Behind the Scenes?

Looking at the browser's developer tools revealed something interesting:

The editor was making PUT requests to Substack's API to save the draft, but when the content contained certain system paths, the request received a 403 Forbidden response.

The response headers showed that Cloudflare was involved:

Server: cloudflare
Cf-Ray: 935d70ff6864bcf5-ATL

Understanding Web Application Security Filters

This behavior points to what's likely a Web Application Firewall (WAF) in action. But what's a WAF, and why would it block these paths?

WAFs Explained Simply

Think of a Web Application Firewall as a security guard for websites. It sits between users and the web application, examining all traffic and blocking anything suspicious.

Like a nightclub bouncer who has a list of troublemakers to watch for, a WAF has rules about what kinds of requests look dangerous. When it spots something on its "suspicious list," it rejects the request.

Path Traversal Attacks: The Reason for Caution

One common attack that WAFs defend against is called a "path traversal" attack. Here's a simple explanation:

Imagine your website has files organized in folders, like:

/images/profile.jpg
/docs/report.pdf

A hacker might try to "break out" of these folders by sending requests like:

/images/../../../etc/pass*d

This is an attempt to navigate up through directory levels to access sensitive system files like the password file on the server.

System paths like /etc/h*sts and /etc/pass*d are common targets in these attacks because they contain valuable system information. A hacker who gains access to these files might find usernames, password hashes, or network configurations that help them compromise the system further.

[For more information on path traversal attacks, check out OWASP's guide]

Command Injection: Another Security Concern

Another attack vector is "command injection," where an attacker tries to trick a web application into executing system commands. Mentioning system paths like /etc/h*sts might trigger filters designed to prevent command injection attempts.

In a command injection attack, an attacker might input something like:

; cat /etc/pass*d

If the web application doesn't properly sanitize this input before using it in a system command, it could execute the attacker's code and reveal sensitive information.

[Learn more about command injection at PortSwigger's Web Security Academy]

The Mystery Deepens: Historical Examples

Curious if others had encountered this issue, I searched for Substack posts containing these system paths. Interestingly, I found a post from March 4, 2025, that successfully included the string /etc/h*sts.allowed.

Another post from March 30, 2025, used the curious formulation etc -> hosts - perhaps a workaround for this same issue?

This suggests the filtering behavior might have been implemented or modified sometime between these dates.

Security vs. Usability: A Delicate Balance

This case highlights an interesting tension in web security: the balance between protection and usability.

Substack's filter is well-intentioned - protecting their platform from potential attacks. But for technical writers discussing system configurations, it creates a frustrating obstacle.

The implementation also leaves room for improvement:

1. The generic "Network Error" message is uninformative

2. The filter blocks legitimate technical content

3. There's no clear workaround for writers discussing these topics

A Look at the HTTP Response

The request to https://scalewithlee.substack.com/api/v1/drafts/162118646 fails with:

• Status Code: 403 Forbidden

• Request Method: PUT

• Content-Type: application/json

What's particularly telling is that this is happening at the API level, not just in the editor UI.

Better Solutions for Technical Content Platforms

How could Substack improve this situation for technical writers?

1. Contextual filtering: Recognize when system paths appear in code blocks or technical discussions

2. Clear error messages: Replace "Network Error" with something like "This content contains patterns that may be flagged by our security filters"

3. Documented workarounds: Provide guidance for technical writers on how to discuss sensitive paths

Conclusion: The Intersection of Security and Technical Writing

This quirk in Substack's editor reveals the complex challenges of building secure platforms that also serve technical writers. What looks like an attack pattern to a security filter might be legitimate content to an author writing about system administration or DevOps.

As a DevOps engineer, I find these edge cases fascinating - they highlight how security measures can sometimes have unintended consequences for legitimate use cases.

For now, I'll continue using workarounds like "/etc/h*sts" (with quotes) or alternative spellings when discussing system paths in my Substack posts. And perhaps this exploration will help other technical writers understand what's happening when they encounter similar mysterious "Network Errors" in their writing.

---

Have you encountered similar filtering issues on other platforms? I'd love to hear about your experiences in the comments!