CVE-2026-112025: CAPTCHA Validation Bypass in light0011 cms UserController

Overview

A high-severity access-control flaw has been disclosed in light0011 cms, a small open-source PHP content management system built on the ThinkPHP framework (per the project's own description: a news CMS with login, registration, article publishing, commenting, and voting). Tracked as CVE-2026-112025 with a CVSS v3.1 score of 7.3 (High), the flaw sits in the Captcha Validation logic of App/Home/Controller/UserController.class.php — the controller that handles user registration and login.

The CMS displays and validates a CAPTCHA in the browser, but a GitHub issue filed against the project (light0011/cms issue #13) reports that the server-side controller never re-checks it. A request that skips the CAPTCHA parameter entirely but is sent as an AJAX call still succeeds, which means the CAPTCHA provides no real protection against scripted abuse of the registration and login endpoints.

Technical Details

How It Works

According to the GitHub issue that documents this behavior, the registration and login forms render a CAPTCHA in the page, but the underlying controller accepts the request regardless of whether a CAPTCHA value was ever submitted or solved. The reported proof-of-concept sends a registration request with a spoofed X-Requested-With: XMLHttpRequest header and the registration fields, omitting any CAPTCHA parameter — the server creates the account anyway and returns a new user ID. The same issue states that the admin login endpoint has the identical gap, with no server-side CAPTCHA check and no rate limiting, which would allow automated username enumeration and password-guessing attempts.

Because the check that exists is purely client-side, any direct API or scripted request bypasses it — this is the classic "security control enforced only in the browser" pattern that CWE-284 (Improper Access Control) describes: the server does not independently verify that an action it should gate is actually permitted.

Impact Assessment

Who Is At Risk

light0011/cms is a small, unmaintained hobbyist project (last updated in 2015, ~30 GitHub stars at time of writing). Exposure is limited to the relatively small number of deployments still running this codebase or a fork of it. For any instance reachable on the network:

• Automated account registration can be scripted at volume, since the CAPTCHA intended to throttle it is not enforced server-side
• The login endpoint's lack of CAPTCHA enforcement and rate limiting makes credential-stuffing and password-guessing against existing accounts easier to automate
• CWE-266/284 classification reflects that this is fundamentally a missing server-side control rather than a memory-safety or injection bug — confidentiality, integrity, and availability impacts are all rated Low in the CVSS vector, consistent with abuse-of-functionality rather than direct data exposure or code execution

What We Could Not Verify

NVD's record for this CVE is sourced from VulDB and is marked "Deferred" (not yet independently analyzed by NVD). We found no vendor advisory, no named discoverer, and no evidence of in-the-wild exploitation — only the GitHub issue and VulDB's own listing. This CVE is not present in the CISA Known Exploited Vulnerabilities (KEV) catalog as of publication. We have not independently reproduced the proof-of-concept described in the GitHub issue.

Mitigation

No official patch exists, and the upstream project shows no sign of active maintenance.

Immediate Actions

• If you are running light0011/cms or a fork of it, add server-side CAPTCHA verification inside UserController.class.php (or an upstream filter/middleware in front of it) rather than relying on the client-rendered widget
• Add rate limiting on the registration and login endpoints at the web server or reverse-proxy layer (e.g., per-IP request throttling) as a stopgap that does not depend on patching application code
• Monitor for abnormal volumes of account-creation or login requests, particularly those missing a Referer header or arriving with scripted/non-browser user agents

Longer Term

• Given the lack of maintainer response and the project's dormant state, treat this as a candidate for migration to an actively maintained CMS if it is handling anything beyond a low-value test deployment
• If forking and self-patching, keep the server-side CAPTCHA check independent of any client-supplied "I solved it" flag — validate the CAPTCHA token against what the server itself issued

Discovery & Disclosure

The issue was reported via a GitHub issue (light0011/cms#13) against the project repository rather than through a formal CVE disclosure process; VulDB subsequently assigned CVE-2026-112025 based on that report. The NVD entry states the project "was informed of the problem early through an issue report but has not responded yet." No discoverer name is listed in the sources we reviewed, and we are not naming one.

References

• NVD — CVE-2026-112025
• GitHub — light0011/cms
• GitHub Issue — light0011/cms#13
• VulDB — VDB-421673