Qexo vulnerability allows unauthenticated users to reset blog configuration and expose credentials
A critical flaw in Qexo versions prior to 4.2.0 enables attackers to bypass authentication and potentially steal stored service credentials via the setup API.
Key points
- CVE-2026-44828 is rated CVSS 9.3 Critical by the National Vulnerability Database.
- The flaw affects Qexo from version 4.0.0 up to, but not including, version 4.2.0.
- Attackers can reset the initialization state and expose provider configuration data.
An unauthenticated configuration reset risk exists in Qexo, an open-source online editor for static blogs. The National Vulnerability Database has assigned CVE-2026-44828 to this issue, rating it with a CVSS score of 9.3, which classifies the severity as Critical.
At a glance
- CVE
- CVE-2026-44828
- Product
- Qexo
- CVSS
- 9.3 Critical
- Weakness
- CWE-538
- Exploited
- No known exploitation
The vulnerability stems from the application exposing the /api/init_step/ endpoint through the init_step_api component. This exposure occurs without any requirement for authentication, authorization, or a check to verify if the initial setup process has already been completed successfully.
Context and Background
An attacker who possesses a valid Cross-Site Request Forgery (CSRF) token, which can be obtained from any public page on the site, can exploit this gap. By submitting the first initialization step, the requester can force the instance to reset its INIT setting.
This action causes the blog instance to re-enter the initial setup flow. According to the NVD record, this behavior effectively bypasses the intended security controls designed to prevent repeated initialization after the system is configured.
The consequences of this reset include the potential exposure of sensitive data. The setup response and the /init/ page may reveal stored PROVIDER configuration details. This information can include service credentials embedded in frontend content, giving attackers access to backend services linked to the blog.
Who Is Affected
The National Vulnerability Database states that Qexo versions starting from 4.0.0 are vulnerable. The issue persists in all releases up to, but not including, version 4.2.0. Any instance running within this version range is susceptible to the described attack vector.
The weakness is categorized under CWE-538, which relates to the inclusion of functional requirements in software design. Specifically, it highlights the failure to implement necessary security controls for critical initialization functions.
What should you do?
Administrators managing Qexo instances should immediately verify their current software version. If the system is running version 4.0.0 or any release prior to 4.2.0, it is considered at risk.
Users should check for and apply version 4.2.0, as the source material confirms that this specific update resolves the issue. The fix addresses the lack of authentication and authorization on the initialization API endpoint.
What to do and how to stay safe: Qexo
- Identify all Qexo installations and verify their version numbers to determine if they fall within the affected range of 4.0.0 up to but not including 4.2.0.
- Apply the vendor-provided update to version 4.2.0 as soon as possible to patch the unauthenticated initialization flaw.
- Review server logs for unusual activity on the /api/init_step/ endpoint, particularly requests that may indicate an attempt to reset the setup state.
- Ensure that CSRF tokens are not easily predictable or accessible from public pages in a way that facilitates automated abuse.
Step-by-step guide: Risk Based Vulnerability Management: Prioritize Fixes by Actual Threat
General security guidance from the Threat Times newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
What is the CVSS score for CVE-2026-44828?
The National Vulnerability Database assigns a CVSS score of 9.3 to this vulnerability, classifying it as Critical.
Which versions of Qexo are affected by this security flaw?
Versions from 4.0.0 up to, but not including, 4.2.0 are affected. The issue is resolved in version 4.2.0.
Can an attacker exploit this without logging in?
Yes, an unauthenticated requester can exploit this flaw using a valid CSRF token obtained from a public page.
