ApostropheCMS CVE-2026-113710

The attacker must already hold a valid authenticated ApostropheCMS session of any privilege level (the advisory used a disposable guest session), and the target is specifically the self-service endpoint PATCH /api/v1/@apostrophecms/settings/password, which routes through handlePasswordProtectedSubform → verifyPassword without the login module's checkLoginAttempts/addLoginAttempt controls. No special non-default configuration is required - the missing throttle is present in all versions below 4.33.0. Limiting factors: exploitation is impossible without a pre-existing session (no pre-auth vector), and ultimate success still depends on the entropy of the victim's password, since the flaw removes only rate-limiting, not the password check itself.

This is a genuine but moderate-priority weakness (CWE-307, improper restriction of excessive authentication attempts), not a drop-everything issue. The supplied CVSS of 5.9 (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N) captures the key constraints: exploitation is network-reachable but gated behind an existing authenticated session and yields success only probabilistically against the target password. No EPSS score was provided and the CVE is NOT in CISA KEV, so there is no evidence of active exploitation; the only exploitation signal is a working local PoC published in the GHSA advisory (curl loop showing five unthrottled 403 responses), i.e. publicly available exploit code exists but not confirmed active exploitation - these are distinct signals and should not be conflated. I partly disagree with the input vector's PR:H: the advisory explicitly used a 'disposable authenticated guest session,' meaning any low-privilege authenticated user suffices, which argues for PR:L rather than PR:H. The C:H/I:H rating reflects that unlimited guessing can eventually disclose the current password and thereby allow a full account takeover. Net: real and worth patching (upgrade to 4.33.0), but its danger is bounded by the need for a pre-existing session and by target password entropy, so it ranks below internet-facing pre-auth flaws.

An attacker who has obtained a valid ApostropheCMS session (for example a stolen/hijacked session cookie, a shared workstation, or a low-privilege guest account) repeatedly calls the PATCH /api/v1/@apostrophecms/settings/password endpoint, submitting different passwordCurrent guesses. Because this endpoint verifies the password but never consults the login module's failed-attempt counter, throttle, delay, or lockout, the attacker can brute-force the account's current password at full speed and then reset it for durable takeover. A working local PoC demonstrating the missing lockout is published in the GHSA advisory.