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.
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.
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-ATLThis 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?
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.
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.pdfA hacker might try to "break out" of these folders by sending requests like:
/images/../../../etc/pass*dThis 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]
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*dIf 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]
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.
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:
The generic "Network Error" message is uninformative
The filter blocks legitimate technical content
There's no clear workaround for writers discussing these topics
Examining the details of the failed request reveals more about what's happening:
The request to https://scalewithlee.substack.com/api/v1/drafts/162118646 fails with:
What's particularly telling is that this is happening at the API level, not just in the editor UI.
The request includes various cookies:
Nothing here immediately explains the filtering behavior, but it confirms this is happening during normal authenticated use of the platform.
How could Substack improve this situation for technical writers?
Contextual filtering: Recognize when system paths appear in code blocks or technical discussions
Clear error messages: Replace "Network Error" with something like "This content contains patterns that may be flagged by our security filters"
Documented workarounds: Provide guidance for technical writers on how to discuss sensitive paths
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!