← Back to all sparks
C

CommaFeed

COLLAB
Velocity5.0

Self-hosted Google Reader inspired RSS feed reader

CommaFeed's security pass turns inward, from hostile feeds to hostile users

rss-readerself-hostedsecurity-hardeningaccess-controlmulti-tenancyopen-source
Current state
CommaFeed's 7.x line has become a sustained security pass, shipped one fix per patch release. The newest, 7.3.2, closes a cross-user data exposure: users could star or tag entries that were not theirs and then read them, filed as GHSA-prfv-88mm-5gpg. Behind it sit Host header injection on the password recovery endpoint with a new commafeed.password-recovery-public-base-url setting, local address blocking made secure by default alongside Google Reader API support in 7.3.0, and javascript: URL filtering moved to parse time.
Where it's heading
The earlier fixes in this run all closed paths where something from outside the instance was trusted too far — feed URLs reaching internal addresses, proxied images, javascript: links, a request header shaping an outbound email. 7.3.2 is a different shape: nothing external is involved, the attacker is a legitimate signed-in user, and the flaw is an ownership check missing on a write path that then leaks through a read path. That is the class of bug you find once you start auditing multi-tenancy rather than input handling, and it suggests the review has moved past the perimeter into the authorization model that the 7.0.0 multi-user rework put in place.
Prediction
If the audit is now working through ownership checks rather than input validation, the other per-user write paths — subscription and category mutations, saved searches — are the likely next findings. The pattern of shipping each fix as its own patch release with a GHSA reference should continue rather than batching them.

Recent moves

  1. 25d ago

    Cross-user entry disclosure via starring and tagging closed

    Starring or tagging an entry belonging to another user made it readable to the attacker — an ownership check missing on the write path, leaking through the read path. It is the first fix in this run that is about users abusing each other rather than about hostile external input, which moves the security pass from the perimeter to the authorization model.

    View source ↗
  2. 29d ago

    Host header injection closed on the password recovery endpoint

    The password recovery email had been building its base URL from the incoming request. A new configuration setting makes that URL explicit, removing an attacker-controlled header from the path of an outbound credential email.

    View source ↗
  3. 1mo ago

    Google Reader API support and secure-by-default local address blocking

    Adds Google Reader API compatibility while flipping local address blocking to on by default, closing the server-side request forgery path a feed fetcher inherits. A feature and a hardening default shipped together.

    View source ↗
  4. 1mo ago

    javascript: URLs now filtered at parse time, not just in the renderer

    Moves javascript: URL filtering earlier, so hostile feed content is stripped as it is parsed rather than relied upon to be neutralised at render. Defence moved closer to the untrusted boundary.

    View source ↗
  5. 2mo ago

    Feed-declared icons, starred-entry search, and image-proxy SSRF fix

    User-facing additions — feed-declared icons, search across starred entries — bundled with a server-side request forgery fix in the image proxy. One of the releases where ordinary feature work and the security pass ship in the same tag.

    View source ↗
  6. 5mo ago

    Mobile unread count in the header plus a graceful refresh shutdown

    An unread count in the mobile header and cleaner shutdown behaviour during feed refresh. Ordinary product maintenance from the stretch before the security work came to dominate the line.

    View source ↗