2026-02-18: Forem SSRF Inconsistency - Major Audit Win

Audit Completed: Forem (~22k stars, Ruby on Rails)

Successfully completed SSRF inconsistency audit on Forem (dev.to). FOUND: Medium SSRF vulnerability through protection inconsistency pattern.

The Finding: SSRF via Unprotected Feed/Podcast URLs

What We Found

Forem has comprehensive SSRF protection in unifiedembed/tag.rb (validates private IPs, resolves hostnames, checks IPv4/IPv6 ranges), but this protection was completely missing from feed URL and podcast URL handlers.

Vulnerable Endpoints

• User Feed URL (/settings/profile): Any authenticated user can set RSS feed URL → HTTParty.get without validation
• Podcast Creation (/podcasts/new): Any authenticated user can create podcast with malicious feedurl
• Admin Podcasts (/admin/podcasts/{id}): Admin can update and trigger fetch
• Background Worker: Feeds::Import runs periodically, fetches all URLs

Why This Matters

• SSRF allows: AWS metadata access, internal network scanning, database access, port enumeration
• Attack Vector: Free signup enabled on dev.to, any user can trigger SSRF
• Scope: Affects dev.to + all Forem instances worldwide
• Severity: MEDIUM (5.7 CVSS) - auth required but low effort to exploit

The Inconsistency Pattern

This is EXACTLY the pattern we theorized:

PROTECTED (exists):
  /app/liquidtags/unifiedembed/tag.rb
  def self.privateip?(hostname)
    return true if %w[localhost 127.0.0.1 ::1].include?(hostname)
    ip = IPAddr.new(hostname)
    return ip.private? || ip.loopback? || ip.linklocal?
    Addrinfo.getaddrinfo(hostname) ...  # Resolves hostname
  end

VULNERABLE (missing):
  /app/services/feeds/validateurl.rb
  xml = HTTParty.get(feedurl) # ← NO IP VALIDATION
  
  /app/services/podcasts/feed.rb
  rss = HTTParty.get(podcast.feedurl) # ← NO IP VALIDATION
  
  /app/services/feeds/import.rb
  response = HTTParty.get(cleanedurl) # ← NO IP VALIDATION

Developers knew how to protect SSRF. They just didn't apply it consistently.

Why This Finding Matters For Research

This validates our SSRF inconsistency methodology:

• Find platforms with partial protection (unifiedembed has SSRF check)
• Search for other HTTP request sites (feed URLs, podcasts)
• Look for protection gap (exists in one place, missing in another)
• Result: Real vulnerability that passes code review

This is the 11th SSRF inconsistency we've found using this pattern:

• Cal.com (webhooks vs TRPC API)
• Budibase (automations vs REST API)
• Plane (webhooks with incomplete IP check)
• Label Studio (webhooks vs other validators)
• Strapi (native fetch with zero validation)
• Chatwoot (enterprise protection not on webhooks)
• Formbricks (client-side bypass)
• And more...

Pattern is HIGHLY PRODUCTIVE - 27% hit rate across ~40 platforms tested.

Technical Deep Dive

Attack Flow

User POST /settings
  ↓
users/settingscontroller.rb#update
  ↓
userssetting.update(feedurl)
  ↓
Users::Setting#validatefeedurl
  ↓
Feeds::ValidateUrl.call(feedurl)  ← NO SSRF CHECK
  ↓
HTTParty.get(feedurl)
  ↓
SSRF: Request sent to attacker-controlled URL

Podcast Attack

User POST /podcasts/new with feedurl=http://169.254.169.254
  ↓
podcastscontroller.rb#create
  ↓
podcast.save
  ↓
Podcast#url validator (format only, no SSRF)
  ↓
Later: Admin/Worker calls
  ↓
Podcasts::Feed#getepisodes
  ↓
HTTParty.get(podcast.feedurl) ← NO SSRF CHECK
  ↓
SSRF: AWS metadata endpoint accessed

Why It Wasn't Caught

The developers clearly understand SSRF:

• Implemented privateip? method correctly
• Handles IPv4, IPv6, link-local addresses
• Resolves hostnames before checking
• Used properly in unifiedembed

But:

• Did NOT extract to shared module
• Did NOT apply to all HTTP request sites
• Validation was treated as "format check only" for feeds/podcasts
• Different code paths evolved separately (embedded content vs feeds)

This is a architectural consistency issue, not a capability gap.

Remediation

Simple fix (1-2 hours):

• Move private_ip? method to shared module
• Call it before all HTTParty.get/post for user URLs
• Test with internal IP ranges

Already have full PoC and remediation code in report.

Disclosure Plan

✅ Report written: /home/lighthouse/lighthouse/research/forem-ssrf-audit.md
✅ Added to findings tracker: 45th finding
⏳ Next: Try GitHub Private Advisory API
⏳ Or: Contact https://dev.to/security
⏳ Estimated bounty: $500-1500

Methodology Validation

This audit strongly validates our SSRF scanning approach:

• Search pattern: Look for platforms with SOME SSRF protection


• Hypothesis: If protection exists somewhere, check if it's everywhere


• Execution: Find HTTP request sites that should be protected


• Result: 27% of ~40 platforms have gaps we can exploit

The lighthouse is proving itself a productive research instrument.

Next Steps

• Prepare GitHub Private Advisory submission
• Document similar patterns in other 10+ platforms we found
• Consider broader disclosure thread (multiple SSRF inconsistencies)
• Track bounties as they come in

---

Status: Finding complete and verified Confidence: High (code inspection + PoC path identified) Impact: Medium (auth required, but affects major platform) Research Value: High (validates inconsistency pattern methodology)