FreshRSS, the self-hosted feed reader that many people quietly run as the backbone of their reading stack, shipped 1.30.1 on October 5, and its maintainers describe it as a security-oriented release carrying several patches in the continuation of 1.30.0. The notes point at the fixes without reciting exploits, but the changelog lists exactly what changed, and together it reads like a review of the doors a feed reader keeps. The release credits nineteen people, twelve of them newcomers, which is its own kind of security claim: enough hands to review, and enough turnover to keep reviewing.
What the hardening covers
Disabled accounts lose token access entirely: RSS and OPML exports and feed refreshes no longer work through their tokens, which closes the obvious gap where disabling a user left their tokens active, the kind that turns a disciplinary action into a sharing incident. The self-update path now requires a POST with a CSRF token before it will mutate anything. The login challenge nonce is one-time, so it cannot be replayed. Session identifiers rotate on every authenticated transition, not just sign-in. ZIP imports are bounded against decompression bombs. A vulnerable and unused error-display code path was removed outright. Around the edges, secret parameters take PHP’s attribute for keeping values out of stack traces, search length and depth get safer defaults, and the CI pipeline gained action security checks. The ordinary bug fixes ride along: domain-wide Retry-After, feeds muted by an HTTP 410 staying muted, a redirect loop, the reading view after marking articles read, a sharing-links regression, and NAT64 fetching on IPv6-only hosts. A small feature lands too: the CLI that actualizes a user now takes an optional feed argument, which makes scripted refreshes easier to target.
One operational note
The maintainers also say their rolling release channel is recommended for faster security patches, which is a sentence worth taking literally from a project that ships point releases like this one. If you track the versioned channel, you get the careful path; if security latency matters more to you than stability ceilings, the edge channel is their own recommendation. The versioned channel still gets everything eventually; the difference is weeks, and for a service that faces the internet on your behalf, weeks are the unit that matters.
My read
Nothing in this release asks for configuration; everything in it asks for the update. For the software that everything else in the stack reads from, that is the right shape: close the doors, keep the daily release cadence, and let the notes speak for themselves. Take it with your next maintenance window, and if you want the next one of these faster, take the maintainers up on their own advice about the rolling channel.
Source: the 1.30.1 release.