Listen to this Post
How the mentioned CVE works:
The vulnerability exists in eduMFA’s `/validate/check` endpoint, which is used to validate tokens against a resolver. When a request includes the `resolver` parameter but specifies a username that does not exist in that resolver, the system incorrectly increments the failcounter for every token associated with that resolver. This occurs because the code fails to validate user existence before iterating through all tokens bound to the resolver. The endpoint is designed to be called by client applications (e.g., Shibboleth, FreeRADIUS) without full authentication, relying instead on network trust or API keys. However, no authentication is required by default, allowing an unauthenticated attacker to repeatedly send crafted requests to /validate/check?resolver=some_resolver&user=nonexistent. Each request increments the failcounter for all tokens in that resolver. After a few attempts, tokens cross their configured failcounter limit (typically 3-5 failures) and become locked, causing denial of service for legitimate users. The increment is unconditional and does not require valid credentials. The failcounter is stored persistently, so repeated attacks can lock tokens indefinitely until an administrator resets counters manually or via the admin UI. The issue affects all resolver-based tokens (e.g., LDAP, SQL, Active Directory) and does not require any prior access or privilege.
dailycve form:
Platform: eduMFA
Version: before 2.9.1
Vulnerability: Unauthenticated failcounter increment
Severity: Moderate
date: May 11,2026
Prediction: Patched in v2.9.1
What Undercode Say:
Check if /validate/check is exposed without auth
curl -k "https://target.edu/validate/check?resolver=ldap_resolver&user=doesnotexist"
Repeated attack to lock all resolver tokens
for i in {1..5}; do
curl -s "https://target.edu/validate/check?resolver=sql_resolver&user=invalid" > /dev/null
done
Monitor failcounter increments from logs
grep "failcounter increased" /var/log/edumfa/edumfa.log
Query token failcounters via admin API (requires auth)
edumfa-admin token list --resolver ldap_resolver --show-failcount
Exploit:
Send unauthenticated HTTP GET requests to `/validate/check` with a valid resolver name and a non-existent username. Repeat 3–5 times to exceed the failcounter limit of all tokens in that resolver, locking them. No valid token, password, or API key needed.
Protection from this CVE:
- Upgrade to eduMFA v2.9.1 or later.
- Limit access to `/validate/check` using an authorization policy with
api_key_required. - Use a reverse proxy (e.g., nginx, Apache) to restrict the endpoint to trusted IP addresses (client apps only).
- Monitor failcounter events and block suspicious source IPs.
Impact:
Denial of service for all users of the affected resolver. Tokens become unusable until manually unlocked or reset. Attackers can disrupt two-factor authentication, RADIUS authentication, and any service relying on eduMFA token validation. No privilege escalation or data breach, but availability is completely compromised.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
