In mid-2022, security researchers uncovered a critical vulnerability in several versions of Appwrite—a popular open-source backend-as-a-service (BaaS) platform. Tracked as CVE-2022-25377, it affects Appwrite from version .5. up to, but not including, .12.2. This flaw allowed unauthenticated remote attackers to read arbitrary files on the server using a directory traversal (“../”) attack, but only if the APP_STORAGE_CERTIFICATES/.well-known/acme-challenge directory exists. This folder is created automatically if you use Appwrite’s built-in Let's Encrypt support.

This long-read post will explain the vulnerability in simple, clear language: how the bug worked, how someone could exploit it, and how to fix your system. In addition, you’ll see sample code and references to original sources, making this a one-stop resource for understanding CVE-2022-25377.

What is Appwrite?

Appwrite is an open-source backend server that provides developers with ready-to-use APIs for authentication, databases, file storage, cloud functions, and more. It’s mainly written in PHP and is typically deployed using Docker. Let’s Encrypt certificate management is a feature designed to help developers install HTTPS certificates easily.

The Vulnerable Endpoint

Let’s Encrypt uses the .well-known/acme-challenge endpoint to verify domain ownership. In Appwrite, when you set up HTTPS via Let's Encrypt, it exposes an endpoint like so:

/v1/well-known/acme-challenge/[TOKEN]

This path is supposed to serve a challenge file from the directory APP_STORAGE_CERTIFICATES/.well-known/acme-challenge/. However, there was insufficient sanitation of the path parameter in Appwrite versions <.12.2. This allowed attackers to inject directory traversal sequences (like ../../) in the endpoint URL.

Here’s a simplified outline of what happened in the background

// Pseudocode representation of the relevant code
$file = APP_STORAGE_CERTIFICATES . '/.well-known/acme-challenge/' . $token;

if (file_exists($file)) {
    // Serve file contents
    readfile($file);
}

Notice that $token (coming directly from the attacker's URL param) is appended without validation.

An attacker could send the following HTTP request

GET /v1/well-known/acme-challenge/../../../../../../etc/passwd HTTP/1.1
Host: target-appwrite-server.com

If the server running Appwrite had the vulnerable endpoint and the ACME challenge directory was present (from attempting to use Let's Encrypt), the attacker would receive the contents of /etc/passwd—or any other file readable by the Appwrite process.

Here is a minimal exploit using curl

curl http://target-appwrite-server.com/v1/well-known/acme-challenge/../../../../../../etc/passwd

If vulnerable, this would return the sensitive local file!

> Note: The traversal depth (../../..) depends on how deep APP_STORAGE_CERTIFICATES is set. Adjust as needed in your attempts.

ACME challenge directory must exist:

Attack only works if .well-known/acme-challenge exists in APP_STORAGE_CERTIFICATES—i.e., if you ever tried to configure Let's Encrypt in Appwrite.

Official Fix

The Appwrite maintainers resolved the issue in version .12.2 by sanitizing the path, ensuring no directory traversal is possible.

Patch Reference:
GitHub commit (fix)

Fixed Pseudocode Example

// Only allow alphanumeric and dash, reject anything else
if (!preg_match('/^[A-Za-z-9\-]+$/', $token)) {
    http_response_code(400);
    exit('Invalid token');
}

If you use Appwrite and have ever enabled Let's Encrypt, upgrade as soon as possible

docker pull appwrite/appwrite:.12.2
docker-compose up -d

To check if your installation is at risk

1. Does APP_STORAGE_CERTIFICATES/.well-known/acme-challenge exist on your server?

Are you running Appwrite <.12.2?

3. Does the endpoint /v1/well-known/acme-challenge/ respond at all?

Run the curl command above with a test file. If you see file contents returned that you shouldn’t, you are vulnerable.

Mitigation if You Cannot Upgrade

- Delete or restrict access to the .well-known/acme-challenge directory if not needed.
- Apply a webserver rule to block requests containing ../.

References and Further Reading

- CVE-2022-25377 in the National Vulnerability Database (NVD)
- Appwrite Security Advisory
- Patch Pull Request & Discussion
- Original Report

Conclusion

CVE-2022-25377 highlights the dangers of directory traversal flaws in web apps. Any feature that serves user-supplied file names—like ACME challenge handlers—must sanitize input strictly. If you use Appwrite and enabled Let's Encrypt, update to .12.2 or later immediately. This is a classic “trivial exploit; critical impact” bug.

Stay safe, audit your endpoints, and treat all user input as potentially dangerous.

Got questions or need help with patching? Drop them in the comments or contact your system admin!

*This post is an exclusive, original explanation designed for developers and admins working with Appwrite, based on public sources and independent analysis.*

Timeline

Published on: 02/22/2024 22:15:47 UTC
Last modified on: 08/21/2024 18:35:00 UTC