{"answers":{"affected":"2 open source packages ship an affected version, including edumfa.","exploited":"There is no known exploitation of GHSA-qq2p-4282-cfc5 in the wild and no public exploit code.","fix":"Upgrade edumfa to 2.9.1 or later.","what":"GHSA-qq2p-4282-cfc5 is a vulnerability in edumfa, published on 18 May 2026. Any signed-in user can exploit it over the network, with no action from the victim."},"fix_prompt":"Check this codebase for GHSA-qq2p-4282-cfc5 and fix it if it is affected.\n\nWhat it is: GHSA-qq2p-4282-cfc5 is a vulnerability in edumfa, published on 18 May 2026. Any signed-in user can exploit it over the network, with no action from the victim.\nExploitation: There is no known exploitation of GHSA-qq2p-4282-cfc5 in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- edumfa (PyPI): affected all versions; fixed in 2.9.1\n- edumfa (PyPI): affected all versions; fixed in 2.9.1\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/GHSA-qq2p-4282-cfc5/ (Markdown: https://insights.sbomify.com/GHSA-qq2p-4282-cfc5/index.md)","id":"GHSA-qq2p-4282-cfc5","markdown":"https://insights.sbomify.com/GHSA-qq2p-4282-cfc5/index.md","name":"GHSA-qq2p-4282-cfc5","record":{"aliases":[],"analysis":{"component_type":"server_software","fix_type":"upgrade","impacts":["security_bypass"],"network_reachable":"yes","non_default_config":true,"product_category":"eduMFA authentication server","requires_auth":"low_privilege","summary":"Attackers can reuse one-time tokens in eduMFA due to database race conditions, bypassing authentication if specific database isolation settings are used.","user_interaction":"not_required","vuln_class":"race_condition"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"### Impact\n\nFor deployments using MySQL or MariaDB \u003c 11.6.2 (or newer with innodb_snapshot_isolation=off) reusage of token values might be possible due to faulty transaction isolation inside the database. Exploiting this requires racing this transaction.\nAffected are all tokentypes whose values are only supposed to be used once, for example TOTP, HOTP and likely also WebAuthN.\n\n#### Affected Combinations:\n\n- MySQL (any version)\n- MariaDB with innodb_snapshot_isolation=OFF\n  - innodb_snapshot_isolation 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\n    with default OFF, can be turned ON as a workaround\n  - for MariaDB \u003e= 11.6.2 the default is ON, which is not affected\n- Same rules applies for Galera with underlying MariaDB\n\n### Patches\nFixed in version 2.9.1 by locking rows prior to write with SELECT FOR UPDATE.\n\n### Workarounds\nSet innodb_snapshot_isolation to ON (default in MariaDB \u003e= 11.6.2, e.g packaged in Debian 13).\n\n### Resources\nhttps://mariadb.com/resources/blog/isolation-level-violation-testing-and-debugging-in-mariadb/","ecosystems":["PyPI"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"eduMFA: Incorrect InnoDB snapshot isolation possibly allows token reusage","id":"GHSA-qq2p-4282-cfc5","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"PyPI","product":null,"products":[],"type":"race_condition","year":"2026"},"n_packages":2,"n_references":null,"packages":[{"ecosystem":"PyPI","fixed":["2.9.1"],"introduced":["0"],"last_affected":[],"package":"edumfa","purl":null,"source":"GHSA-qq2p-4282-cfc5"},{"ecosystem":"PyPI","fixed":["2.9.1"],"introduced":["0"],"last_affected":[],"package":"edumfa","purl":"pkg:pypi/edumfa","source":"GHSA-qq2p-4282-cfc5"}],"products":null,"published":"2026-05-18","related":[],"sources":[{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"Attackers can reuse one-time tokens in eduMFA due to database race conditions, bypassing authentication if specific database isolation settings are used.","url":"https://insights.sbomify.com/GHSA-qq2p-4282-cfc5/"}