Description

Wallos is an open-source, self-hostable personal subscription tracker. Prior to version 4.9.1, endpoints/currency/update_exchange.php loads the first Fixer/API Layer credential globally instead of loading the credential for the authenticated user. As a result, a normal authenticated user without their own provider key can trigger exchange-rate refreshes using another user's stored provider credential. This issue has been patched in version 4.9.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-08-31T21:17:08.847Z",
  "pubdate": "2026-08-31T21:17:08.847Z",
  "executiveSummary": "Wallos versions prior to 4.9.1 are susceptible to an Insecure Credential Scope vulnerability located within the exchange-rate update mechanism. This flaw arises from an improper authorization implementation where the application globally retrieves API credentials for services like Fixer or API Layer, rather than scoping access to the specific authenticated user profile.\nThe vulnerability allows a standard authenticated user, who lacks their own provider API keys, to inadvertently or maliciously initiate exchange-rate refresh operations using the credentials stored by other users or administrators. This results in the unauthorized consumption of third-party API quotas and potential financial impact depending on the provider's billing structure.\nThe risk is primarily centered on resource abuse and unauthorized access to external service configurations. Exploitation requires an authenticated session within the Wallos platform. The issue is resolved by ensuring credential retrieval is strictly scoped to the context of the currently authenticated user identity.",
  "technicalDetails": "The vulnerability is localized within the 'endpoints/currency/update_exchange.php' script, which handles the synchronization of exchange rates for the Wallos application. The root cause of the flaw is an architectural oversight in the credential retrieval logic, where the system performs a global lookup for external provider credentials (specifically for Fixer.io or API Layer) instead of validating or filtering based on the session-based user ID.\nIn a secure implementation, the application should fetch API credentials associated exclusively with the current user's settings. However, due to the failure to properly isolate these configurations, the application defaults to the first available credential in the global configuration store. This behavior allows any authenticated user to trigger the 'update_exchange.php' endpoint, which subsequently consumes the stored API key to perform external requests.\nThe attack flow proceeds as follows: An authenticated user with low privileges identifies the existence of the endpoint 'endpoints/currency/update_exchange.php'. Because the server-side code fails to implement strict multi-tenancy or user-scoped credential isolation, the application fetches the globally stored API provider credentials—potentially belonging to an administrator or another user who has configured their own subscription key. The attacker sends a request to the endpoint, which triggers the backend script to perform an HTTP request to the external financial API. The API service logs this request against the stolen or incorrectly scoped credential, causing the quota of the legitimate key holder to be depleted.\nThis vulnerability is particularly significant in multi-user deployments of Wallos. An attacker does not require administrative privileges, merely a valid, standard user account. The attack is performed entirely over the network via the web interface. Because the endpoint triggers an external request, it could also be potentially utilized for reconnaissance or as a vector for triggering side-effects in the external API layer if the endpoint processing logic is flawed. The impact extends beyond simple quota exhaustion; it undermines the integrity of user-defined service configurations and allows for the unauthorized use of third-party assets integrated into the self-hosted instance. Version 4.9.1 addresses this by enforcing proper credential scoping, ensuring that only keys associated with the authenticated user's session can be utilized for exchange rate updates."
}