CVE-2026-46556: FlaskBB SSRF Vulnerability

CVE-2026-46556 Overview

FlaskBB is a forum application written in Python on the Flask microframework. CVE-2026-46556 is a Server-Side Request Forgery (SSRF) vulnerability in the get_image_info() helper that lets any authenticated user coerce the server into issuing HTTP requests to arbitrary internal endpoints. Attackers can reach internal services, scan internal ports, and query cloud metadata endpoints such as 169.254.169.254. The flaw is a blind SSRF, but reachability and error timing confirm internal port scanning and internal API triggering. Version 2.2.1 fixes the issue by disabling HTTP redirects in the avatar fetch path. The weakness is classified as [CWE-918].

Critical Impact
Authenticated attackers can pivot through FlaskBB to reach internal-only services and cloud instance metadata, potentially exposing credentials tied to the hosting environment.

Affected Products

FlaskBB forum software prior to version 2.2.1
Deployments that expose user registration or allow authenticated avatar/profile image configuration
Cloud-hosted FlaskBB instances with reachable instance metadata endpoints (AWS IMDSv1, GCP, Azure)

Discovery Timeline

2026-07-21 - CVE-2026-46556 published to the National Vulnerability Database
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-46556

Vulnerability Analysis

The vulnerability lives in flaskbb/utils/helpers.py inside the get_image_info() function. FlaskBB calls this helper to retrieve remote avatar metadata using the requests library. The original implementation performed requests.get(url, timeout=(3.05, 27), stream=True) without restricting the URL scheme, target host, or redirect behavior. Any authenticated user who can submit an avatar URL can control the destination of the outbound HTTP request. Because redirects were enabled by default, an attacker-controlled server could return a 302 response pointing to http://169.254.169.254/latest/meta-data/ or another internal address. The server then follows the redirect from within its own network context, bypassing any perimeter filtering applied to the initial user-supplied URL.

Root Cause

The root cause is missing egress validation combined with default redirect-following in the requests client. FlaskBB neither validated that the supplied URL resolved to a public address nor constrained protocol handlers to safe schemes. This maps to [CWE-918] Server-Side Request Forgery.

Attack Vector

An authenticated user supplies a URL under their control to the avatar-processing flow. That URL points to an attacker-hosted redirector that responds with a redirect to an internal target, such as http://127.0.0.1:6379, http://localhost:8080/admin, or a cloud metadata IP. FlaskBB follows the redirect server-side, producing observable timing and error differences that enable blind port scanning and interaction with internal APIs.

python

     """
 
     try:
-        r = requests.get(url, timeout=(3.05, 27), stream=True)
+        r = requests.get(url, timeout=(3.05, 27), stream=True, allow_redirects=False)
     except requests.ConnectionError:
         return None

Source: FlaskBB patch commit e87e585

Detection Methods for CVE-2026-46556

Indicators of Compromise

Outbound HTTP requests from the FlaskBB application server to RFC1918 addresses, 127.0.0.0/8, or 169.254.169.254
Web server access logs showing avatar or profile image updates immediately followed by internal DNS lookups
Unexpected User-Agent: python-requests/* traffic originating from the FlaskBB host toward internal services
Cloud audit events showing instance metadata queries from the FlaskBB workload without a legitimate cause

Detection Strategies

Alert on any egress from the FlaskBB server whose destination falls inside internal, loopback, or link-local ranges
Correlate authenticated FlaskBB profile-update events with outbound HTTP requests occurring within a short time window
Inspect application logs for get_image_info() invocations that resulted in non-image content types or unusual response sizes

Monitoring Recommendations

Forward FlaskBB and reverse-proxy logs to a central analytics platform and pivot on user identifier plus outbound destination
Enable VPC flow log or NetFlow monitoring for the FlaskBB subnet and baseline expected external destinations
Monitor cloud metadata service access with IMDSv2 enforcement and alert on any IMDSv1 fallback requests

How to Mitigate CVE-2026-46556

Immediate Actions Required

Upgrade FlaskBB to version 2.2.1 or later on every deployment
Enforce IMDSv2 on AWS instances hosting FlaskBB and require session tokens for metadata access
Restrict outbound network access from the FlaskBB host to only the destinations required for operation
Review authentication logs for suspicious accounts that registered specifically to test avatar URLs

Patch Information

The fix is delivered in FlaskBB 2.2.1 through commit e87e585f54bbe36694e91d52ee9b2d2e65dd4ab5. The patch adds allow_redirects=False to the requests.get() call inside get_image_info(), preventing attacker-controlled redirects from steering the request to internal targets. Full advisory details are available in the GitHub Security Advisory GHSA-xq32-9g7q-7297.

Workarounds

Place FlaskBB behind an egress proxy that denies requests to RFC1918, loopback, and link-local destinations
Disable avatar URL functionality until the upgrade is applied, if the deployment permits
Apply host firewall rules blocking outbound access to 169.254.169.254 from the FlaskBB process user

bash

# Example iptables egress restriction for the FlaskBB service user
iptables -A OUTPUT -m owner --uid-owner flaskbb -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner flaskbb -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner flaskbb -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner flaskbb -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner flaskbb -d 192.168.0.0/16 -j REJECT