Live › vulnerability › CVE-2026-111874
Go to dashboardOpenCATS 0.10.0's Career Portal login function processLogin in modules/careers/CareersUI.php does not restrict excessive authentication attempts, so an attacker can try many logins against candidate accounts. The sources describe a published exploit, a difficult attack, and a patch that moves candidate sessions server-side and adds a CAPTCHA to the login flow.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Teams running OpenCATS 0.10.0 with the Career Portal exposed to the internet are affected, because candidate logins can be attacked remotely. Installations that keep the Career Portal off the public network, or that already apply proxy-level throttling, face much less exposure. Teams on other OpenCATS versions should confirm against the patch commit.
No product ranges from the sources yet.
0.10.0 is the affected release.applyToJobSubAction parameter handling in modules/careers/CareersUI.php on the Career Portal.1cf4fa3ee9054314b023be79d404078645c22ade, which requires CAPTCHA and server-side candidate sessions on every Career Portal access.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
A flaw has been found in OpenCATS 0.10.0. Affected is the function processLogin of the file modules/careers/CareersUI.php of the component Career Portal. This manipulation of the argument applyToJobSubAction causes improper restriction of excessive authentication attempts. Remote exploitation of the attack is possible. A high degree of complexity is needed for the attack. The exploitability is told to be difficult. The exploit has been published and may be used. Patch name: 1cf4fa3ee9054314b023be79d404078645c22ade. It is suggested to install a patch to address this issue. The project maintainer explains: "Candidates will now need to authenticate each time they access the Career Portal and successfully complete the CAPTCHA as part of that authentication flow. The authenticated candidate identity is now maintained server-side rather than relying on the previous persistent client-side cats…cw cookie mechanism. Application-level rate limiting is deliberately not in scope for this change. In my view, request throttling and brute-force protection of that kind are better applied at the network, reverse-proxy or web-server layer, where they can be configured appropriately for each deployment without OpenCATS having to implement and maintain its own rate-limiting framework. I'll update the online documentation to that effect."
This page as .md · .json · in your agent: get_signal("CVE-2026-111874")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.