Appwrite runtime attack exposes internal credentials; 1,022 projects told to rotate secrets

Appwrite’s November 4 disclosure separates a targeted customer compromise from a platform attack. Initial access on October 30–31 came through that customer’s own application. On November 1, code deployed in the attacker’s own Appwrite project then exploited unsafe runtime-file handling to read internal service credentials. Appwrite confirms actual use of three credentials, including reading one customer’s function code and logs, running a function and changing its code for 31 seconds before restoring it. Active platform exploitation warrants L4; the report does not establish theft from every notified project.

A different access token could read the configuration of Functions and Sites on Frankfurt compute, including secrets, from 03:53 to 14:46 UTC on November 1. Frankfurt also serves Sites for some projects whose primary region is elsewhere. Appwrite is notifying owners of 1,022 projects meeting its runtime, variable-time and secret-name conditions. That count does not mean 1,022 separate organizations or confirmed secret thefts. The vendor found no evidence of environment-variable reads, but the provider’s audit log is incomplete and irrecoverable; its alternative configuration, workload and interactive-session records cannot reveal reads. Customers must rotate affected secrets as a precaution.

In the same session, a separate storage API flaw allowed a write outside the attacker’s project storage. Appwrite reports only the attacker’s own test file written through that flaw, now deleted, and says provider logs show no reads of other customers’ files. An unauthorized content-delivery configuration change never became active. These findings should not be expanded into a confirmed general storage breach.

The Cloud incident is contained according to Appwrite: attacker access is blocked, exposed service credentials are replaced and refused, and the root cause is fixed. The company reports rejecting planted links and non-plain runtime/build files, adding container security profiles, separating unprivileged customer workloads from platform services, splitting shared credentials and replacing signing/encryption keys. Re-encryption of stored data is still in progress. None of these actions rotates customers’ third-party secrets automatically.

Self-hosted release 2.7.1 updates Open Runtimes executor 1.1.2 to 1.3.1. The release describes symlinks in execution/build logs, output or cache, plus an unchecked runtime log ID, allowing access to executor-container files and its environment, including _APP_EXECUTOR_SECRET. That secret permits direct executor-API calls, and the executor controls host Docker. The stated prerequisite is allowing an untrusted party to deploy Functions or Sites. The vendor recommends upgrading and then rotating that secret where applicable; it does not claim self-hosted customers were victims of the Cloud attack. No CVE or complete older-branch support matrix is asserted by these sources.