Description

Mealie 3.26.0 through 3.28.0 contains a server-side request forgery vulnerability in the OpenID Connect avatar fetch that ignores ports when allowlisting the identity provider hostname. Authenticated OIDC users who control their picture URL can make the server send GET requests to arbitrary ports on the provider's internal address on each login.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.5",
  "pubDate": "2026-10-10T19:16:57.770Z",
  "pubdate": "2026-10-10T19:16:57.770Z",
  "executiveSummary": "Mealie versions 3.26.0 through 3.28.0 contain a Server-Side Request Forgery (SSRF) vulnerability within the OpenID Connect (OIDC) avatar retrieval process.\nThe vulnerability arises from a flawed validation mechanism that ignores port specifications when verifying the identity provider hostname against an allowlist.\nThis allows an authenticated user, capable of manipulating their OIDC profile picture URL, to force the Mealie server to initiate unauthorized GET requests to arbitrary ports on the identity provider's internal network infrastructure.\nThe impact includes unauthorized internal network reconnaissance and potential interaction with services residing on the provider's host, bypassing intended network segmentation.\nSuccessful exploitation requires the attacker to hold an authenticated account within the Mealie instance and have the ability to influence OIDC identity provider claims regarding their profile picture.\nThis flaw presents a significant security risk by enabling attackers to leverage the server as a proxy to probe internal services that may not be exposed to the public internet.",
  "technicalDetails": "The vulnerability exists in the logic responsible for fetching user avatars via OpenID Connect in Mealie versions 3.26.0 through 3.28.0. When an OIDC provider supplies a profile picture URL, the application attempts to validate the hostname of this URL against a predefined allowlist to prevent arbitrary requests.\nThe root cause is a deficiency in the hostname validation logic, which effectively performs a host-based check while failing to validate or enforce port constraints. By stripping or ignoring the port component of the target URL during the allowlist check, the validator allows requests to be directed to non-standard or sensitive ports on the host that would otherwise be restricted if the full URI were evaluated strictly.\nThe attack flow proceeds as follows: First, an attacker authenticates to the Mealie application using an OIDC identity provider they control or influence. During the OIDC callback or profile update process, the attacker provides a malicious 'picture' claim. This URL is crafted to target an internal address belonging to the OIDC provider's infrastructure (e.g., http://idp-internal-host:8080/sensitive-endpoint).\nUpon the next user login or session refresh, the Mealie application's OIDC avatar fetch component triggers a background GET request. Because the hostname (e.g., idp-internal-host) matches the allowlisted domain, the application proceeds with the request without validating the specified port 8080. The underlying HTTP client performs the GET request, causing the Mealie server to interact with the target port on the internal network.\nThis behavior facilitates SSRF, enabling an attacker to perform internal port scanning or interact with internal administrative interfaces within the OIDC provider's network boundary. Since the requests are initiated by the server, they originate from a trusted context, potentially bypassing firewall rules or security groups that would normally block direct access from the internet. The payload behavior is strictly limited to GET requests, but the ability to probe arbitrary ports provides a clear pathway for further exploitation of internal service endpoints that might lack robust authentication, relying instead on network-level perimeter security."
}