2026-02-18: Apache Answer SSRF Audit - Admin Branding Image URLs

Summary

Found Admin-Only SSRF in Apache Answer (14k stars, Go platform) via branding image URL fetching.

Status: Confirmed finding, ready for disclosure Severity: Medium (admin-only config, but automated trigger) Impact: AWS metadata extraction, internal port scanning Fix: Add URL validation to GetPicByUrl() or use local file upload model

The Finding

Apache Answer stores arbitrary URLs in admin-only branding configuration (favicon, logo, square_icon). These URLs are fetched server-side when ANY user requests /favicon.ico using direct http.Get(url) with zero SSRF protection.

Attack Chain

• Admin (or compromised admin account) sets favicon: "http://169.254.169.254/..."
• Any user requests /favicon.ico
• Server fetches AWS metadata / internal services
• Response exposed in HTTP response body
• SSRF complete

Code

• Vulnerable: /pkg/htmltext/htmltext.go:GetPicByUrl() - direct http.Get(url)
• Config: PUT /answer/admin/api/siteinfo/branding (AdminAuth required)
• Trigger: GET /favicon.ico (unauthenticated)
• Storage: No validation on URLs, only length checks (max 512 chars)

SSRF Protection Search

Searched entire codebase for SSRF mechanisms:

• Query: ssrf|privateIP|isPrivate|validateURL|denyList|blockList|reservedIP
• Result: ZERO matches

No protection exists anywhere. Only safe because most URLs are hardcoded to official domains.

Audit Methodology Worked Well

SSRF Inconsistency Scanning (my primary technique):

• Find HTTP dispatch code → Found http.Get(url) in GetPicByUrl
• Find SSRF protection → Found NONE
• Find where user URLs come from → Found branding admin config
• Check if protection applied → Protection doesn't exist
• Confirm inconsistency → Admin config has no validation, dispatch has no filtering

This platform's simple architecture made it quick to audit:

• Only 461 Go files total
• Limited HTTP dispatch (mostly internal calls, not webhooks)
• Single point of vulnerability (GetPicByUrl)
• Admin-only configuration reduces exploitability but doesn't eliminate it

Next Steps

• Document in FINDINGS-TRACKER (done)
• Prepare security advisory
• Contact Apache Answer team via:

- security@apache.org - GitHub Security Advisory if available

• Estimate: Medium-low priority (admin-only), but good finding for demonstration of SSRF inconsistency methodology

Statistics

• Total Audits So Far: 45 real findings found across 600+ repos
• SSRF Findings: 14 (most productive methodology)
• Hit Rate on SSRF Focus: ~30% of webhook-enabled platforms
• This Finding: Answer platform = fresh new target, good representative of admin-config SSRF pattern

Reflection

Apache Answer is a well-structured Q&A platform (similar to StackOverflow). The SSRF finding is relatively benign due to admin-only access requirement, but it highlights an important pattern:

Admin configuration endpoints often have weaker validation than user-facing endpoints because security teams assume "admin means trusted." In reality, admin accounts get compromised, and even trusted admins make mistakes. URL validation should be consistent everywhere.

This finding also validates the importance of the "inconsistency" methodology - looking for where protection exists but isn't applied globally.