{"answers":{"affected":"3 open source packages ship an affected version, including irrd. It affects 1 product.","exploited":"There is no known exploitation of CVE-2022-24798 in the wild and no public exploit code.","fix":"Upgrade irrd to 4.2.3 or later.","what":"CVE-2022-24798 is a high-severity vulnerability in irrdnet irrd, published on 31 Mar 2022. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2022-24798 and fix it if it is affected.\n\nWhat it is: CVE-2022-24798 is a high-severity vulnerability in irrdnet irrd, published on 31 Mar 2022. An attacker can exploit it over the internet without logging in, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2022-24798 in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- irrd (PyPI): affected from 4.2.0; fixed in 4.2.3\n- irrd (PyPI): affected from 4.2.0; fixed in 4.2.3\n- irrd (PyPI): affected from 4.2.0; fixed in 4.2.3\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/CVE-2022-24798/ (Markdown: https://insights.sbomify.com/CVE-2022-24798/index.md)","id":"CVE-2022-24798","markdown":"https://insights.sbomify.com/CVE-2022-24798/index.md","name":"CVE-2022-24798","record":{"aliases":["GHSA-cqxx-66wh-8pjw","PYSEC-2022-178"],"analysis":{"component_type":"server_software","fix_type":"upgrade","impacts":["data_read","data_modify"],"network_reachable":"yes","non_default_config":true,"product_category":"Internet Routing Registry daemon","requires_auth":"none","summary":"Attackers can retrieve password hashes from authoritative IRRd instances, potentially leading to unauthorized modification of routing registry objects.","user_interaction":"not_required","vuln_class":"information_disclosure"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"GitHub_M","cpe":[{"product":"internet_routing_registry_daemon","vendor":"internet_routing_registry_daemon_project"}],"cvss":{"score":7.5,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N","version":"3.1"},"cwes":[{"id":"CWE-212","name":"Improper Removal of Sensitive Information Before Storage or Transfer"}],"description":"Internet Routing Registry daemon version 4 is an IRR database server, processing IRR objects in the RPSL format. IRRd did not always filter password hashes in query responses relating to `mntner` objects and database exports. This may have allowed adversaries to retrieve some of these hashes, perform a brute-force search for the clear-text passphrase, and use these to make unauthorised changes to affected IRR objects. This issue only affected instances that process password hashes, which means it is limited to IRRd instances that serve authoritative databases. IRRd instances operating solely as mirrors of other IRR databases are not affected. This has been fixed in IRRd 4.2.3 and the main branch. Versions in the 4.1.x series never were affected. Users of the 4.2.x series are strongly recommended to upgrade. There are no known workarounds for this issue.","ecosystems":["PyPI"],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"Insufficient password hash filtering in some IRRd queries and exports","id":"CVE-2022-24798","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":"PyPI","product":null,"products":[],"type":"information_disclosure","year":"2022"},"n_packages":3,"n_references":3,"next":{"headline":"Cross Site Scripting in Wire Webapp","id":"CVE-2022-24799"},"packages":[{"ecosystem":"PyPI","fixed":["4.2.3"],"introduced":["4.2.0"],"last_affected":[],"package":"irrd","purl":null,"source":"GHSA-cqxx-66wh-8pjw"},{"ecosystem":"PyPI","fixed":["4.2.3"],"introduced":["4.2.0"],"last_affected":[],"package":"irrd","purl":"pkg:pypi/irrd","source":"GHSA-cqxx-66wh-8pjw"},{"ecosystem":"PyPI","fixed":["4.2.3"],"introduced":["4.2.0"],"last_affected":[],"package":"irrd","purl":"pkg:pypi/irrd","source":"PYSEC-2022-178"}],"prev":{"headline":"Exposure of Sensitive Information in Pomerium","id":"CVE-2022-24797"},"products":["irrd"],"published":"2022-03-31","related":[{"cvss_score":8.1,"headline":"IRRd: web UI host header injection allows password reset poisoning via attacker-controlled email links","id":"CVE-2026-28681","kev_date_added":null,"published":"2026-03-06"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"},{"class":"attribution","licence":"CC BY 4.0","name":"PyPA Advisory Database","prefix":"PYSEC"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"yes","exploitation":"none","technical_impact":"partial"},"state":"PUBLISHED","updated":"2025-04-23","vendors":["irrdnet"]},"summary":"Attackers can retrieve password hashes from authoritative IRRd instances, potentially leading to unauthorized modification of routing registry objects.","url":"https://insights.sbomify.com/CVE-2022-24798/"}