Description

Wallos is an open-source, self-hostable personal subscription tracker. Prior to version 4.9.4, endpoints/db/migrate.php executes database schema migrations when called over HTTP with zero authentication. Any unauthenticated attacker can trigger pending migration files against the live SQLite database. This issue has been patched in version 4.9.4.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-31T21:17:09.843Z",
  "pubdate": "2026-08-31T21:17:09.843Z",
  "executiveSummary": "A critical security vulnerability exists in Wallos, an open-source, self-hostable personal subscription tracker, prior to version 4.9.4. This vulnerability resides within the database migration endpoint and allows unauthenticated remote attackers to trigger pending database schema migrations.\nSpecifically, the file located at endpoints/db/migrate.php fails to implement any authentication or authorization controls before executing database operations. Consequently, an attacker can access this endpoint directly over HTTP without providing valid credentials or session tokens.\nThe impact of this flaw is significant, as it permits unauthorized users to alter the application's underlying database structure. Depending on the state of the application and the presence of pending migrations, this could lead to data corruption, service disruption, or unauthorized changes to the database schema.\nBecause Wallos utilizes an SQLite database, concurrent write operations or unexpected structural modifications can severely impact application stability and data integrity. Organizations and individuals self-hosting Wallos are strongly advised to upgrade to version 4.9.4 or later immediately to mitigate this risk, as the patch introduces proper authentication mechanisms to secure the database migration endpoint from external, unauthorized access.",
  "technicalDetails": "The root cause of this vulnerability lies in the lack of access control and session verification within the database migration endpoint of the Wallos application. In versions prior to 4.9.4, the file endpoints/db/migrate.php is publicly accessible over HTTP. When this endpoint receives an HTTP request, typically a GET or POST request, it automatically invokes the database migration logic without validating the identity or privilege level of the requesting client.\nThe migration logic is designed to locate pending migration files within the application directory and execute them against the live SQLite database. Under normal operations, schema migrations should only be executed during installation, updates, or by an authenticated administrator. However, because no authentication middleware or checks are implemented in endpoints/db/migrate.php, any network-adjacent or remote attacker can initiate this process.\nThe attack flow begins with the attacker identifying a deployment of Wallos running a version prior to 4.9.4. The attacker then sends a direct HTTP request to the target URI ending in /endpoints/db/migrate.php. Upon receiving the request, the PHP interpreter executes the script, which initializes the database connection and scans the migrations folder. If any schema migrations are marked as pending, the script executes the corresponding SQL statements against the active SQLite database file.\nWhile the direct impact depends on whether pending migrations exist at the time of the request, the exposure of database manipulation functions to unauthenticated users represents a severe security risk. For instance, if an update was recently deployed but migrations were not yet completed, an attacker could front-run the administrator, potentially disrupting the setup process.\nFurthermore, forcing the database engine to repeatedly process migration checks or run partial migrations can lead to database locking, transaction failures, or denial-of-service conditions due to SQLite's locking mechanisms. In environments where the application state is volatile, unexpected schema updates can cause data inconsistency, rendering the application unusable.\nThe vulnerability is fully resolved in version 4.9.4 by restricting access to endpoints/db/migrate.php, ensuring that database schema updates can only be executed by authorized administrators or via secure local CLI methods. Specifically, the patch introduces authentication checks that verify session states before allowing the PHP script to interact with the database, thereby closing the unauthenticated vector."
}