CVE-2026-108770: 
Appwrite Platform Análisis y mitigación de vulnerabilidades

CVE-2026-108770 is a Server-Side Request Forgery (SSRF) vulnerability in Appwrite's Browser Screenshot Service affecting versions 2.0 through 2.3.0. The flaw resides in the PublicHostname function within src/Appwrite/Platform/Modules/Avatars/Http/Screenshots/Get.php, where the url argument is not properly validated, allowing unauthenticated remote attackers to manipulate the server into issuing arbitrary HTTP requests. It was published on October 11, 2026, with a patch available in Appwrite 2.4.0. The vulnerability carries a CVSS v3.1 base score of 5.3 (Medium) and a CVSS v4.0 base score of 6.9 (Medium) (GitHub Advisory, Feedly).

The root cause is insufficient input validation (CWE-918: Server-Side Request Forgery) on the url parameter accepted by the Browser Screenshot Service endpoint (/v1/avatars/screenshots). Prior to the fix, the endpoint used a generic URL validator that only checked for valid HTTP/HTTPS scheme syntax, without verifying that the target host resolved to a publicly routable address. This allowed an attacker to supply URLs pointing to internal Docker service names (e.g., http://appwrite-mariadb:3306/), loopback addresses (http://127.0.0.1/), or cloud instance metadata endpoints (http://169.254.169.254/) and have the Appwrite server fetch them on the attacker's behalf. The fix introduced a PublicURL validator (src/Appwrite/Network/Validator/PublicURL.php) that requires the host to be a known public domain or public IP resolving only to publicly routable addresses, and additionally blocks cloud metadata service headers (Metadata, Metadata-Flavor, X-Google-Metadata-Request, AWS/Alibaba metadata token headers, and Host) (GitHub PR #13995, Patch Commit).

An unauthenticated remote attacker can manipulate the url parameter to cause the Appwrite server to perform HTTP requests to arbitrary internal or external systems, potentially exposing restricted internal resources, cloud instance metadata (e.g., AWS IMDSv1 credentials at 169.254.169.254), and backend services not intended to be publicly accessible. The primary impact is a low confidentiality breach — the attacker can read responses from internal services the Appwrite server can reach — with no direct integrity or availability impact. In cloud-hosted deployments, successful exploitation could expose IAM credentials or other sensitive metadata, enabling lateral movement or privilege escalation beyond the Appwrite instance (GitHub Advisory, Feedly).

No public proof-of-concept exploit code is known to exist, and there is no evidence of active in-the-wild exploitation at the time of disclosure. The vulnerability requires no authentication and no user interaction, making it trivially exploitable by any network-accessible attacker against exposed Appwrite instances. The EPSS score is 0.0, reflecting low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory, Feedly).

1. Reconnaissance: Identify internet-facing Appwrite instances running versions 2.0–2.3.0 using tools like Shodan or Censys, searching for Appwrite-specific HTTP response headers or the Appwrite console login page.
2. Identify the vulnerable endpoint: Target the Browser Screenshot Service at GET /v1/avatars/screenshots?url=<payload>, which accepts a user-supplied URL without adequate host validation in affected versions.
3. Craft an SSRF payload: Supply an internal URL as the url parameter, such as http://169.254.169.254/latest/meta-data/iam/security-credentials/ (AWS IMDS), http://appwrite-mariadb:3306/, or http://127.0.0.1:<internal_port>/.
4. Send the request: Issue the crafted HTTP GET request to the Appwrite API (no authentication required): GET /v1/avatars/screenshots?url=http://169.254.169.254/latest/meta-data/ HTTP/1.1
5. Retrieve the response: The Appwrite server fetches the internal resource and returns the screenshot or response content, potentially exposing cloud credentials, internal service banners, or other sensitive data to the attacker (GitHub PR #13995, Patch Commit).

• Network: Outbound HTTP requests from the Appwrite server or appwrite-browser container to 169.254.169.254 (AWS/GCP/Azure IMDS), 100.100.100.200 (Alibaba IMDS), internal RFC-1918 addresses, or internal Docker service hostnames (e.g., appwrite-mariadb, redis).
• Logs: Appwrite access logs showing repeated GET /v1/avatars/screenshots or GET /v1/avatars/image or GET /v1/avatars/favicon requests with url parameters containing private IP ranges, loopback addresses, or cloud metadata service URLs.
• Logs: HTTP 200 responses to screenshot/image/favicon requests where the url parameter targets non-public hosts — in patched versions these return HTTP 400; unexpected 200s on unpatched instances may indicate exploitation.
• Network: Unusual DNS queries from the Appwrite server for internal service names or cloud metadata hostnames originating from the appwrite-browser container.

Upgrade Appwrite to version 2.4.0 or later, which introduces the PublicURL validator that enforces public-only host resolution for all avatar endpoints and blocks cloud metadata service headers on screenshot requests (Appwrite 2.4.0 Release, Patch Commit). The patch (commit 393255e7302ae5503331d45802e2eee01c6a47fe) also moves appwrite-browser to a dedicated Docker network isolated from internal services. If immediate patching is not possible, restrict network-level access to the /v1/avatars/screenshots, /v1/avatars/image, and /v1/avatars/favicon endpoints, implement egress firewall rules on the Appwrite server to block outbound connections to RFC-1918 and link-local address ranges, and monitor for suspicious requests to these endpoints. Self-hosted deployments should also configure _APP_ALLOWED_INTERNAL_ADDRESSES only for explicitly required private hosts.

The vulnerability was reported via an internal security report to the Appwrite team and addressed through PR #13995 merged on September 29, 2026. Automated code review bots (Greptile, Hansi) flagged residual SSRF risks in the patch — specifically that DNS rebinding attacks could still bypass the API-level check since the browser resolves hostnames independently, and that hardcoded public DNS resolvers could break self-hosted deployments with private resolvers. A follow-up PR (#13998) was merged to enforce a public-only egress policy at the HTTP client level as well. The vulnerability received standard aggregation coverage across CVE feeds and vulnerability databases with no notable broader media or researcher commentary (GitHub PR #13995).