Description

Wallos is an open-source, self-hostable personal subscription tracker. From version 4.0.0 to before version 4.9.6, Wallos's OIDC login links an incoming OIDC identity to an existing local account by matching the email claim alone, without verifying that the IdP marked that email as verified (email_verified). When Wallos is configured against an IdP that lets a user present an arbitrary or unverified email (multi-tenant IdPs, IdPs with open self-registration, or any IdP the attacker partly controls), an attacker with no Wallos account can authenticate with the admin's email and be logged in as the admin — full account takeover, no password needed. This issue has been patched in version 4.9.6.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-31T21:17:17.373Z",
  "pubdate": "2026-08-31T21:17:17.373Z",
  "executiveSummary": "Wallos versions 4.0.0 through 4.9.5 are susceptible to an authentication bypass vulnerability stemming from insecure OpenID Connect (OIDC) identity validation.\nThe vulnerability occurs because the application performs account association based solely on the 'email' claim within an OIDC token, while failing to validate the 'email_verified' claim provided by the Identity Provider (IdP).\nThis flaw enables an attacker to perform a full account takeover, including the administrative account, by leveraging a malicious or misconfigured IdP that permits the use of arbitrary, unverified email addresses.\nBy presenting an email address already registered within the local Wallos instance, an unauthenticated attacker can deceive the application into linking their session to the targeted account.\nThe risk is severe, as it facilitates unauthorized access and administrative control without requiring knowledge of existing credentials. This vulnerability is applicable to deployments utilizing multi-tenant IdPs or any OIDC provider where an attacker can influence the email claim without formal ownership verification by the IdP.",
  "technicalDetails": "The root cause of this vulnerability is improper trust placed in the 'email' claim during the OIDC callback processing workflow in Wallos. The application architecture implicitly assumes that the presence of an email address in an OIDC ID token serves as sufficient proof of identity for the corresponding local user account.\nSpecifically, the OIDC authentication implementation fails to inspect the 'email_verified' boolean claim—a standard field in the OpenID Connect specification intended to signal whether the IdP has performed a verification check (e.g., confirmation email) on the user's address.\nIn scenarios where Wallos is configured to communicate with an IdP that allows for self-registration or contains multi-tenant weaknesses (such as Azure AD or other providers where an attacker can register an account with a target's email address), an attacker can craft or influence an identity assertion. When this assertion is presented to Wallos, the application parses the incoming email claim and queries the local database for a matching user record.\nThe attack flow proceeds as follows: 1) The attacker initiates an OIDC authentication flow directed at a target IdP; 2) The attacker ensures the IdP returns an identity token containing the target administrative email address; 3) Wallos receives the token and, upon finding a user with a matching email address in its local database, bypasses traditional password authentication mechanisms; 4) Wallos logs the attacker into the application as the administrative user associated with that email.\nBecause the application does not verify if the claim is officially validated, it effectively treats the IdP's assertion as authoritative even when the IdP has not confirmed ownership of the address. This logic error allows an attacker to hijack existing sessions or gain initial access to high-privileged accounts by creating a spoofed identity on an OIDC provider trusted by the Wallos installation.\nThe vulnerability is present in all Wallos versions from 4.0.0 to 4.9.5. Successful exploitation allows for complete account takeover, resulting in unauthorized access to sensitive subscription data and administrative configuration settings within the self-hosted environment."
}