From 26c3c4fb41914d7891e8b3538896bbf0baa71fac Mon Sep 17 00:00:00 2001 From: "advisory-database[bot]" <45398580+advisory-database[bot]@users.noreply.github.com> Date: Fri, 30 May 2025 15:03:03 +0000 Subject: [PATCH] Publish GHSA-h97m-ww89-6jmq --- .../12/GHSA-h97m-ww89-6jmq/GHSA-h97m-ww89-6jmq.json | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/advisories/github-reviewed/2024/12/GHSA-h97m-ww89-6jmq/GHSA-h97m-ww89-6jmq.json b/advisories/github-reviewed/2024/12/GHSA-h97m-ww89-6jmq/GHSA-h97m-ww89-6jmq.json index 24de8c18cac..ac5d7dbc1ab 100644 --- a/advisories/github-reviewed/2024/12/GHSA-h97m-ww89-6jmq/GHSA-h97m-ww89-6jmq.json +++ b/advisories/github-reviewed/2024/12/GHSA-h97m-ww89-6jmq/GHSA-h97m-ww89-6jmq.json @@ -1,13 +1,13 @@ { "schema_version": "1.4.0", "id": "GHSA-h97m-ww89-6jmq", - "modified": "2024-12-09T20:41:10Z", + "modified": "2025-05-30T15:01:30Z", "published": "2024-12-09T20:41:10Z", "aliases": [ "CVE-2024-12224" ], "summary": "`idna` accepts Punycode labels that do not produce any non-ASCII when decoded", - "details": "`idna` 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with `idna` 0.5.0 or earlier.\n\nConcretely, `example.org` and `xn--example-.org` become equal after processing by `idna` 0.5.0 or earlier. Also, `example.org.xn--` and `example.org.` become equal after processing by `idna` 0.5.0 or earlier.\n\nIn applications using `idna` (but not in `idna` itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an `xn--`-masked name that turns into the name of the target when processed by `idna` 0.5.0 or earlier.\n\n## Remedy\n\nUpgrade to `idna` 1.0.3 or later, if depending on `idna` directly, or to `url` 2.5.4 or later, if depending on `idna` via `url`. (This issue was fixed in `idna` 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.)\n\nWhen upgrading, please take a moment to read about [alternative Unicode back ends for `idna`](https://docs.rs/crate/idna_adapter/latest).\n\nIf you are using Rust earlier than 1.81 in combination with SQLx 0.8.2 or earlier, please also read an [issue](https://github.com/servo/rust-url/issues/992) about combining them with `url` 2.5.4 and `idna` 1.0.3.\n\n## Additional information\n\nThis issue resulted from `idna` 0.5.0 and earlier implementing the UTS 46 specification literally on this point and the specification having this bug. The specification bug has been fixed in [revision 33 of UTS 46](https://www.unicode.org/reports/tr46/tr46-33.html#Modifications).\n\n## Acknowledgements\n\nThanks to kageshiron for recognizing the security implications of this behavior.\n", + "details": "`idna` 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with `idna` 0.5.0 or earlier.\n\nConcretely, `example.org` and `xn--example-.org` become equal after processing by `idna` 0.5.0 or earlier. Also, `example.org.xn--` and `example.org.` become equal after processing by `idna` 0.5.0 or earlier.\n\nIn applications using `idna` (but not in `idna` itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an `xn--`-masked name that turns into the name of the target when processed by `idna` 0.5.0 or earlier.\n\n## Remedy\n\nUpgrade to `idna` 1.0.3 or later, if depending on `idna` directly, or to `url` 2.5.4 or later, if depending on `idna` via `url`. (This issue was fixed in `idna` 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.)\n\nWhen upgrading, please take a moment to read about [alternative Unicode back ends for `idna`](https://docs.rs/crate/idna_adapter/latest).\n\nIf you are using Rust earlier than 1.81 in combination with SQLx 0.8.2 or earlier, please also read an [issue](https://github.com/servo/rust-url/issues/992) about combining them with `url` 2.5.4 and `idna` 1.0.3.\n\n## Additional information\n\nThis issue resulted from `idna` 0.5.0 and earlier implementing the UTS 46 specification literally on this point and the specification having this bug. The specification bug has been fixed in [revision 33 of UTS 46](https://www.unicode.org/reports/tr46/tr46-33.html#Modifications).\n\n## Acknowledgements\n\nThanks to kageshiron for recognizing the security implications of this behavior.", "severity": [ { "type": "CVSS_V4", @@ -36,6 +36,10 @@ } ], "references": [ + { + "type": "ADVISORY", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12224" + }, { "type": "WEB", "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1887898" @@ -51,11 +55,12 @@ ], "database_specific": { "cwe_ids": [ + "CWE-1289", "CWE-697" ], "severity": "MODERATE", "github_reviewed": true, "github_reviewed_at": "2024-12-09T20:41:10Z", - "nvd_published_at": null + "nvd_published_at": "2025-05-30T02:15:19Z" } } \ No newline at end of file