CVE-2026-19806 in Support Genix Plugin
Summary
by MITRE • 09/01/2026
The Support Genix – Helpdesk, AI Chatbot, Knowledge Base & Customer Support Ticketing System plugin for WordPress is vulnerable to Authentication Bypass leading to Administrator Account Takeover in all versions up to, and including, 1.4.52 via the `guest_ticket_login()` function and its `p` parameter. This is due to the site-wide AES-256-CBC encryption key being derived from only three two-digit `wp_rand(10, 99)` values and a Unix timestamp via `md5()` — yielding approximately 19.5 bits of entropy — combined with a deterministic IV derived from the password, no authentication tag on the ciphertext, and no capability check, nonce, or session validation on the publicly reachable `/sgnix/?p=<token>` endpoint. This makes it possible for authenticated attackers, with subscriber-level access and above, who can obtain a single legitimate guest ticket token as a known-plaintext oracle and bound the plugin activation timestamp, to exhaust the ~729,000-candidate keyspace entirely offline, recover the site-wide encryption key, and forge a self-consistent `{ticket_id, ticket_user}` token targeting any administrator-owned ticket. Submitting the forged token to the unprotected endpoint causes `wp_set_auth_cookie()` to be called for that administrator, granting the attacker full administrative access to the WordPress site.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/01/2026
The Support Genix plugin for WordPress contains a critical authentication bypass vulnerability affecting versions up to 1.4.52, which allows attackers with subscriber-level or higher privileges to achieve complete administrative account takeover. This flaw is rooted in the `guest_ticket_login()` function and its associated endpoint `/sgnix/?p=`, where the security model fails due to weak cryptographic implementations and a lack of proper access controls. The vulnerability enables an attacker to forge authentication tokens that are accepted by the system as valid, thereby bypassing standard login mechanisms entirely without needing to guess passwords or exploit session hijacking techniques in the traditional sense.
The core technical flaw lies in how the site-wide AES-256-CBC encryption key is generated and managed. The plugin derives this critical cryptographic material from a combination of three two-digit random numbers, each selected using `wp_rand(10, 99)`, along with a Unix timestamp representing the plugin's activation time. This construction results in an entropy pool of approximately only 19.5 bits. While AES-256 provides strong theoretical security for the cipher itself, the key derivation process is severely compromised by this low entropy source. An attacker who can bound the possible range of the activation timestamp and observe a single legitimate guest ticket token can perform an offline brute-force attack against the small keyspace of roughly 729,000 candidates to recover the exact encryption key used for all subsequent operations.
Furthermore, the implementation exhibits several critical cryptographic anti-patterns that facilitate this exploitation. The initialization vector (IV) is deterministically derived from the password rather than being randomly generated and stored with the ciphertext, which violates standard practices for secure symmetric encryption. Additionally, there is no authentication tag on the ciphertext, meaning the system does not verify the integrity of the data before processing it. This lack of authenticated encryption allows attackers to manipulate the encrypted payload without detection, provided they can predict or control certain parameters. The absence of capability checks, nonces, or session validation on the public endpoint further exacerbates the issue by allowing any forged token that decrypts correctly to be accepted as a valid login credential.
The operational impact of this vulnerability is severe, resulting in full administrative access to the compromised WordPress installation once an attacker successfully forges and submits a targeted ticket token. By obtaining a single legitimate guest ticket token from a low-privileged user account, which serves as a known-plaintext oracle, the attacker can reverse-engineer the encryption key. With this key, they can generate valid tokens targeting any administrator-owned ticket ID. Submitting these forged tokens to the unprotected endpoint triggers `wp_set_auth_cookie()`, effectively logging the attacker in as an administrator. This grants unrestricted access to all site features, including the ability to install malicious plugins, modify core files, exfiltrate sensitive data, and maintain persistent backdoors within the environment.
From a classification perspective, this vulnerability aligns with CWE-287, which covers Improper Authentication, specifically regarding the failure to properly verify identity before granting access. It also relates to CWE-326, Inadequate Encryption Strength, due to the insufficient entropy in key generation and the use of weak random number sources. The exploitation technique mirrors aspects of ATT&CK T1078, Valid Accounts, as it involves using legitimate credentials or tokens with elevated privileges obtained through bypass rather than direct compromise of password hashes. Additionally, CWE-345, Insufficient Verification of Data Authenticity, applies due to the lack of integrity checks on the encrypted data structure.
Mitigation strategies must address both the immediate configuration issues and the underlying architectural weaknesses. The most effective remediation is to upgrade the plugin to a version where this vulnerability has been patched by the developers. If upgrading is not immediately possible, administrators should restrict access to the `/sgnix/` endpoint using web application firewall rules or server-level configurations to prevent unauthenticated or low-privileged users from interacting with it. It is also crucial to rotate all user passwords and revoke existing sessions across the WordPress installation to invalidate any potentially compromised tokens. Long-term fixes require replacing the weak key derivation mechanism with a standard password-based key derivation function such as PBKDF2, scrypt, or Argon2, ensuring that cryptographic keys are generated from high-entropy sources rather than predictable timestamps and small random ranges. Implementing authenticated encryption modes like AES-GCM would also prevent token forgery by verifying data integrity before acceptance.