Ntfy uses topic names as de facto passwords for unauthenticated push notifications

Ntfy is an HTTP-based pub-sub notification service that lets you send push notifications to a phone or desktop from any script or REST API call. Publishing is as simple as a curl POST to a topic endpoint, and topics are created on the fly by subscribing or publishing to them. The service is open source and can be self-hosted, or used via the hosted ntfy.sh instance with free and paid tiers.

The security model is the most consequential design choice for engineers. Without sign-up, the topic name is essentially the password. There is no separate authentication token or credential in the free, no-account flow. Anyone who knows or guesses the topic string can subscribe to it and read every notification, and can also publish to it. The documentation explicitly warns to pick something not easily guessable, which is the sole access control mechanism in that mode.

Paid plans introduce reserved topics, which is the first real access control beyond obscurity. The Supporter plan ($5/month annually) includes 3 reserved topics, Pro ($10/month) includes 10, and Business ($20/month) includes 50. Reserved topics presumably prevent others from subscribing to or publishing on names you have claimed, though the extract does not detail the exact enforcement mechanism. This is the primary reason an engineer handling sensitive alerts would move off the free tier.

The service supports attachments up to 25 MB on the cheapest paid plan and 1 GB on Business, which means files sent through ntfy inherit the same topic-based access model. An unreserved topic carrying surveillance camera images or documents is readable by anyone who discovers the topic name. Engineers sending sensitive attachments should treat topic selection with the same care as credential selection, or use reserved topics on a paid plan.

Only one feed carried this event, so there is no cross-source corroboration or independent discussion of the security implications beyond what the project's own documentation states. The material is drawn entirely from the project's landing page, which means the security observations are the project's own framing rather than third-party analysis. Engineers evaluating ntfy for production alerting should test the reserved-topic enforcement directly and consider self-hosting with additional access controls if the topic-as-password model is insufficient for their threat model.