Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact In eduMFA < 2.9.1 userless Passkey/WebAuthn challenges might be replayed and do not expire Patches Fixed in eduMFA = 2.9.1 by adding validity information to the userless challenges. Workarounds No known workarounds besides disabling userless login altogether.
Recommended action: Upgrade to 2.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact For deployments using MySQL or MariaDB < 11.6.2 (or newer with innodbsnapshotisolation=off) reusage of token values might be possible due to faulty transaction isolation inside the database. Exploiting this requires racing this transaction. Affected are all tokentypes whose values are only supposed to be used once, for example TOTP, HOTP and likely also WebAuthN. Affected Combinations: - MySQL (any version) - MariaDB with innodbsnapshotisolation=OFF - innodbsnapshotisolation was introduced in: MariaDB 10.6.18, MariaDB 10.11.8, MariaDB 11.0.6, MariaDB 11.1.5, MariaDB 11.2.4, MariaDB 11.4.2 with default OFF, can be turned ON as a workaround - for MariaDB = 11.6.2 the default is ON, which is not affected - Same rules applies for Galera with underlying MariaDB Patches Fixed in version 2.9.1 by locking rows prior to write with SELECT FOR UPDATE. Workarounds Set innodbsnapshotisolation to ON (default in MariaDB = 11.6.2, e.g packaged in Debian 13). Resources…
Recommended action: Upgrade to 2.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact If the resolver parameter is passed, but the user does not exist, all failcounters of tokens in that resolver will be increased. Patches This, along with other issues, was fixed in eduMFA v2.9.1. Workarounds Limiting access to /validate/check to client applications (i.e. Shibboleth/FreeRADIUS) using an authorization policy with apikeyrequired or using e.g. the reverse proxy.
Recommended action: Upgrade to 2.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
BlastRADIUS (see blastradius.fail for details) also affects eduMFA prior version 2.2.0, because the Message-Authenticator attributes were not checked. Details Website with the vulnerability information blastradius.fail The original vulnerability has been assigned CVE-2024-3596 Case in vince: https://kb.cert.org/vuls/id/456537 PoC There is no known proof-of-concept except for the attack shown in the paper from the researchers Impact An attacker can trigger an authentication flow with a RADIUS-backed token, intercept the RADIUS packet sent by eduMFA and modify the RADIUS server's answer, which would lead eduMFA to believe that the token is valid, even though the RADIUS servers answer was a reject.
Recommended action: Upgrade to 2.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.