Wallos EUVD-2026-68812

Exploitation requires that OIDC login be explicitly enabled in Wallos and that an IdP be configured - this is a non-default, operator-chosen configuration. The attacker must be able to present to Wallos an OIDC token containing the target user's email as the email claim without a email_verified=true assertion, which requires access to either: (a) a multi-tenant or open-registration IdP that the Wallos instance trusts and that does not enforce email verification before issuing claims; (b) partial administrative control over a self-hosted IdP (Keycloak, Authentik, etc.) configured for that Wallos instance; or (c) any IdP where email claim values are attacker-controllable. Limiting factors: Wallos instances using only local password authentication are entirely unaffected; instances using private corporate IdPs (e.g., Azure AD, Okta) that always verify and lock email claims are not exploitable in practice. No Wallos credentials are required (PR:N); no victim interaction is required (UI:N).

The CVSS 8.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) captures a high-severity flaw with network delivery, no required credentials, and full CIA impact, tempered by AC:H because exploitation depends on an IdP configuration that permits unverified email claims. No EPSS data was provided in the source intelligence; KEV status is not confirmed. No public exploit code has been identified at time of analysis. Real-world risk splits sharply by deployment context: instances using private, corporate, or otherwise controlled IdPs that guarantee email_verified=true for all tokens face minimal exploitability, while those pointed at permissive multi-tenant or self-registration IdPs face a practical, near-trivially-executable account takeover. Because Wallos is a self-hosted application, its users disproportionately configure third-party OIDC providers (Google Workspace, GitHub, Authentik, Keycloak) where email verification behavior varies - the AC:H rating should not encourage complacency. The scope of impact (S:U) is conservative; in single-admin deployments, full admin compromise is effectively total compromise of the instance.

An attacker identifies a Wallos instance with OIDC login enabled and determines the administrator's email address (often discoverable from public profiles or prior recon). The attacker registers or modifies an account on a permissive OIDC provider trusted by that Wallos instance - such as a self-hosted Authentik or Keycloak instance with open registration - setting the email claim to match the Wallos admin's address. Initiating the OIDC login flow against Wallos causes the application to match the email claim to the existing admin account and issue a fully authenticated admin session, with no password, MFA, or further interaction required.