CVE-2026-105213
ZITADEL 4.x before 4.17.1 does not check an organization's inactive state during Login V2 authentication, verifying only the individual user
CVSS
8.2
Alto
EPSS
—
KEV
—
Exploit Today
0
0-100
Publicado: 4 oct 2026 · Última mod.: 4 oct 2026 · CWE-287
Sin historial EPSS suficiente todavía.
ZITADEL 4.x before 4.17.1 does not check an organization's inactive state during Login V2 authentication, verifying only the individual user's status. Users of a deactivated organization who hold valid credentials, an existing session, or a refresh token can still sign in, create sessions, and obtain or refresh tokens.
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-1051707.3 ALT—
——0A weakness has been identified in kishor-23 food-waste-management-system 411989e3ecb82895e53dca7865f72145f03d7d93/b3a70b2c492dc9904de5be1ad9389bd79b87f82c. Affected is an unknown function of the file admin/signup.php of the component Admin Signup. This manipulation of the argument sign causes missing authentication. The attack can be initiated remotely. The exploit has been made available to the public and could be used for attacks. Continious delivery with rolling releases is used by this product. Therefore, no version details of affected nor updated releases are available. The project was informed of the problem early through an issue report but has not responded yet.12hCVE-2026-1052127.5 ALT—
——0ZITADEL 3.x before 3.4.14 and 4.x before 4.16.2 contains an authentication bypass in the hosted Login V1 and Login V2 UIs that accepts passkey or other authenticator enrollment on identify-only login sessions, before any primary factor is verified. Unauthenticated attackers knowing only a victim's login name can register an attacker-controlled authenticator and log in as that user, bypassing existing passwords and MFA.21hCVE-2026-1052108.2 ALT—
——0ZITADEL 3.x before 3.4.15 and 4.x before 4.17.1 contains a missing authentication flaw in the hosted Login V1 UI, whose second-factor enrollment and initialization handlers act on an identify-only session before any primary factor is verified. Attackers knowing only a victim's login name can enroll attacker-controlled TOTP, OTP-SMS, OTP-Email, or U2F factors, overwrite the verified phone number, and enumerate users through discrepant errors.21hCVE-2026-1051337.3 ALT30.0%
——9A vulnerability was detected in Ahsay AhsayCBS up to 10.3.2. This affects the function checkSysPwd of the file com/ahsay/obs/api/ApiStructsAction.java of the component API. Performing a manipulation of the argument random results in improper authentication. It is possible to initiate the attack remotely. The exploit is now public and may be used. Upgrading to version 10.3.4 is able to mitigate this issue. It is recommended to upgrade the affected component.1dCVE-2026-71885—7.5%
——2In Bouncy Castle for Java before 1.86, the Messaging Layer Security (MLS, RFC 9420) implementation did not bind an X.509 credential to a LeafNode's signature_key. LeafNode.verify() checked a leaf's signature against the signature_key carried in the leaf itself, while the credential's X.509 certificate chain was stored but never parsed or validated, so the end-entity certificate's public key was never required to match signature_key as RFC 9420 sec. 5.3 requires. A party could therefore present another party's certificate as its credential while signing the leaf, and the enclosing KeyPackage, with an unrelated key, and be accepted under that other party's identity through KeyPackage.verify() and the Group leaf-validation path. In a deployment that admits external commits without an independent credential-admission check, an unauthenticated attacker could be admitted under a victim's X.509 identity, evict the victim (resynchronization compares whole credentials rather than signing keys), derive the current epoch, decrypt subsequent group messages, and send messages accepted as the victim. TreeKEM.LeafNode now requires the end-entity certificate's subject public key, in the cipher suite's signature encoding, to equal signature_key for an X.509 credential and rejects the leaf otherwise, including an empty chain or a certificate whose key type does not match the cipher suite; certificate-chain and identity validation to a trust anchor remain the application's responsibility per RFC 9420 sec. 5.3.1. Deployments using only basic credentials are unaffected.2dCVE-2026-973434.3 MED20.5%
——6The Burst Statistics – Simple WordPress Analytics (Google Analytics Alternative) plugin for WordPress is vulnerable to Improper Authentication leading to Account Persistence in all versions up to, and including, 3.7.1. This is due to the `maybe_load_shared_dashboard()` handler issuing a genuine WordPress session cookie for the `burst_statistics_viewer` account to any visitor presenting a valid share token via `wp_set_auth_cookie()`, while the plugin only blocks Application Passwords for the resulting `burst_viewer` role and does not restrict the core `/wp-json/wp/v2/users/me` password update endpoint or filter the `edit_user` capability for that account — leaving WordPress core's built-in rule that any authenticated user may update their own account fully in effect. This makes it possible for unauthenticated attackers to set an attacker-chosen password on the `burst_statistics_viewer` WordPress account, constituting a permanent takeover of that limited-privilege (`view_burst_statistics`) account that persists through share-token revocation, share-token expiration, and execution of the plugin's daily `cleanup_viewer_sessions()` routine. Exploitation requires that the attacker have obtained a valid `burst_share_token`, such as one that has been shared publicly or distributed to an untrusted party.2d