On Tue, May 12, 2026 at 2:13 PM Sebastian Pipping <sebastian () pipping org> wrote: From my perspective CVE-2026-44927 is a low-severity security issue that would be hard to exploit in reality since it requires an actual 2gb+ input to even trigger. For example, in the context of PHP (which uses the lib) you'd hit the memory limit long before this even triggers. Therefore, this is "Low" severity from my perspective. Given the input size, it definitely doesn't have a remote vector. I have no problem with this being considering "low severity" based on the payload size needed, but this /does/ have a remote vector that is independent of size constraints, as far as I am concerned. I just checked the definition of a remote attack vector a la CVSS [3][4] and it's not "adjacent", not "local", and not "physical": I see nothing stopping applications from parsing URI strings read "from the wire", directly or indirectly, the same way that XMPP parses XML from the wire. Am I missing something here? That's a fair point, I'd still lean toward "low", perhaps low-medium in light of your comment.
Parsing streaming URI strings from a wire without any cap is a bit unusual, but stranger things have happened. As you pointed out from cvvs guide, it doesn't care about that.
-- Ilia Alshanetsky Technologist, CTO, Entrepreneur E: ilia () ilia ws T: @iliaa B: http://ilia.ws
Hello Team,
An update request for CVE-2026-44927 with an impact report was submitted on Sun, May 10, 9:04 AM to MITRE.
This request appears to have been processed today.
Best regards, Joshua W. Windle
On Tue, May 12, 2026 at 3:19 PM Sebastian Pipping <sebastian () pipping org> wrote: Hi Alexander,
On 5/10/26 09:47, Solar Designer wrote: On Sat, May 09, 2026 at 08:18:49PM +0200, Sebastian Pipping wrote: just a quick note that uriparser 1.0.2 released today is fixing vulnerabilities CVE-2026-44927 and CVE-2026-44928. Thanks, but let's please be including vulnerability descriptions right in the postings. Also, when it's one vulnerability, its title should be in the Subject line. When it's more than one, then if there's a way to group them e.g. by category or severity, that could go into the Subject. Some key links are:
- The change log of release 1.0.2 https://github.com/uriparser/uriparser/blob/uriparser-1.0.2/ChangeLog This says: SECURITY
Fixed: [CVE-2026-44927] Stop truncating ptrdifft to int Thanks for the report to Ilia Alshanetsky and Joshua W. Windle! (GitHub #304) Fixed: [CVE-2026-44928] Fix EqualsUri with regard to .absolutePath Thanks for the report to Ilia Alshanetsky! (GitHub #305) SECURITY
Fixed: Fix OOM related memory leak in CopyUriMm Thanks for the report to Ilia Alshanetsky! (GitHub #306) - The fixing pull requests - https://github.com/uriparser/uriparser/pull/304 - https://github.com/uriparser/uriparser/pull/305
- The official CVE metadata - https://nvd.nist.gov/vuln/detail/CVE-2026-44927 - https://nvd.nist.gov/vuln/detail/CVE-2026-44928 These only say a little:
CVE-2026-44927: In uriparser before 1.0.2, there is pointer difference truncation to int in various places.
CVE-2026-44928: In uriparser before 1.0.2, the function family EqualsUri can misclassify two unequal URIs as equal.
For CVE-2026-44927, it could help to clarify actual security exposure and impact. I understand.
My understanding of the impact of the ptrdifft truncation (CVE-2026-44927) was "DoS or more", and I focussed on fixing this in the about 15 places rather than analyzing the impact in more detail.
Ilia and Joshua considered impact more than me, and I'm BCC'ing them so they can reply to this mail directly if they like, please do not feel pushed.
Let me add that the public CVSS score input for CVE-2026-44927 is (again) mistaken; none of these are correct:
- Attack vector: Local - Attack complexity: High - Availability: None
(Seen at https://github.com/advisories/ghsa-gmxg-5w57-j63q just now.)
Best
Sebastian
Ilia, thanks for jumping in!
On 5/12/26 19:44, Ilia wrote: CVE-2026-44927: In uriparser before 1.0.2, there is pointer difference > truncation to int in various places. I have no problem with this being considering "low severity" based on the payload size needed, but this /does/ have a remote vector that is it's not "adjacent", not "local", and not "physical": I see nothing stopping applications from parsing URI strings read "from the wire", directly or indirectly, the same way that XMPP parses XML from the wire. Am I missing something here?
Best
Sebastian
CVE-2026-44927: In uriparser before 1.0.2, there is pointer difference truncation to int in various places. From my perspective CVE-2026-44927 is a low-severity security issue that would be hard to exploit in reality since it requires an actual 2gb+ input to even trigger. For example, in the context of PHP (which uses the lib) you'd hit the memory limit long before this even triggers. Therefore, this is "Low" severity from my perspective. Given the input size, it definitely doesn't have a remote vector. CVE-2026-44928: In uriparser before 1.0.2, the function family EqualsUri can misclassify two unequal URIs as equal. I'd say this is more nuanced: Low-Medium since this could theoretically be abused to bypass certain restrictions that rely on URI comparison. It would really depend on the consumer; in most cases I think something like this:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N - AV:N - exploitable via any URI that flows into the consumer; remote attacker control of the compared string is the common shape. - AC:L - trivial; PoC is sub-16-byte ASCII (file:/etc/passwd vs file:etc/passwd). - PR:N / UI:N - anonymous, no user interaction. - C:N / I:L / A:N - integrity-only impact at the library layer; equality returns wrong answer. No direct C or A.
However, it could go higher depending on use-case, for example, C:L when the consumer uses uriEqualsUriA for cache-key dedup or signature replay protection, equality bypass can leak data scoped to the wrong key.
In some extreme (unlikely cases) it could even push to C:H/I:H when the consumer uses uriEqualsUriA to gate access to file: / data: URIs (allowlist check, sandbox boundary). file:/etc/passwd vs file:etc/passwd resolve to different files, but compare equally; this suggests an arbitrary-file-read bypass.
But that's a stretch, and I wouldn't classify it as such, though it has chaining potential.
Bottom line, I think somewhere in the 3.1 to 5 range seems reasonable.
-- Ilia Alshanetsky Technologist, CTO, Entrepreneur E: ilia () ilia ws T: @iliaa B: http://ilia.ws
Hi Alexander,
On 5/10/26 09:47, Solar Designer wrote: On Sat, May 09, 2026 at 08:18:49PM +0200, Sebastian Pipping wrote: just a quick note that uriparser 1.0.2 released today is fixing vulnerabilities CVE-2026-44927 and CVE-2026-44928. Thanks, but let's please be including vulnerability descriptions right in the postings. Also, when it's one vulnerability, its title should be in the Subject line. When it's more than one, then if there's a way to group them e.g. by category or severity, that could go into the Subject. Some key links are:
- The change log of release 1.0.2 https://github.com/uriparser/uriparser/blob/uriparser-1.0.2/ChangeLog This says: SECURITY >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fixed: [CVE-2026-44927] Stop truncating ptrdifft to int Thanks for the report to Ilia Alshanetsky and Joshua W. Windle! (GitHub #304) Fixed: [CVE-2026-44928] Fix EqualsUri with regard to .absolutePath Thanks for the report to Ilia Alshanetsky! (GitHub #305) SECURITY >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fixed: Fix OOM related memory leak in CopyUriMm Thanks for the report to Ilia Alshanetsky! (GitHub #306) - The fixing pull requests - https://github.com/uriparser/uriparser/pull/304 - https://github.com/uriparser/uriparser/pull/305
- The official CVE metadata - https://nvd.nist.gov/vuln/detail/CVE-2026-44927 - https://nvd.nist.gov/vuln/detail/CVE-2026-44928 These only say a little:
CVE-2026-44927: In uriparser before 1.0.2, there is pointer difference truncation to int in various places.
CVE-2026-44928: In uriparser before 1.0.2, the function family EqualsUri can misclassify two unequal URIs as equal.
For CVE-2026-44927, it could help to clarify actual security exposure and impact. I understand.
My understanding of the impact of the ptrdifft truncation (CVE-2026-44927) was "DoS or more", and I focussed on fixing this in the about 15 places rather than analyzing the impact in more detail.
Ilia and Joshua considered impact more than me, and I'm BCC'ing them so they can reply to this mail directly if they like, please do not feel pushed. - Attack vector: Local - Attack complexity: High - Availability: None
(Seen at https://github.com/advisories/ghsa-gmxg-5w57-j63q just now.)
Best
Sebastian
On Sat, May 09, 2026 at 08:18:49PM +0200, Sebastian Pipping wrote: just a quick note that uriparser 1.0.2 released today is fixing vulnerabilities CVE-2026-44927 and CVE-2026-44928. Thanks, but let's please be including vulnerability descriptions right in the postings. Also, when it's one vulnerability, its title should be in the Subject line. When it's more than one, then if there's a way to group them e.g. by category or severity, that could go into the Subject. Some key links are:
- The change log of release 1.0.2 https://github.com/uriparser/uriparser/blob/uriparser-1.0.2/ChangeLog This says: SECURITY >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fixed: [CVE-2026-44927] Stop truncating ptrdifft to int Thanks for the report to Ilia Alshanetsky and Joshua W. Windle! (GitHub #304) Fixed: [CVE-2026-44928] Fix EqualsUri with regard to .absolutePath Thanks for the report to Ilia Alshanetsky! (GitHub #305) SECURITY >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fixed: Fix OOM related memory leak in CopyUriMm Thanks for the report to Ilia Alshanetsky! (GitHub #306) - The fixing pull requests - https://github.com/uriparser/uriparser/pull/304 - https://github.com/uriparser/uriparser/pull/305
- The official CVE metadata - https://nvd.nist.gov/vuln/detail/CVE-2026-44927 - https://nvd.nist.gov/vuln/detail/CVE-2026-44928 These only say a little:
CVE-2026-44927: In uriparser before 1.0.2, there is pointer difference truncation to int in various places.
CVE-2026-44928: In uriparser before 1.0.2, the function family EqualsUri can misclassify two unequal URIs as equal.
For CVE-2026-44927, it could help to clarify actual security exposure and impact.
Alexander
Hello oss-security,
just a quick note that uriparser 1.0.2 released today is fixing vulnerabilities CVE-2026-44927 and CVE-2026-44928.
Some key links are:
- The change log of release 1.0.2 https://github.com/uriparser/uriparser/blob/uriparser-1.0.2/ChangeLog
- The fixing pull requests - https://github.com/uriparser/uriparser/pull/304 - https://github.com/uriparser/uriparser/pull/305
- The official CVE metadata - https://nvd.nist.gov/vuln/detail/CVE-2026-44927 - https://nvd.nist.gov/vuln/detail/CVE-2026-44928
Best
Sebastian
Fixed CVE-2026-44928 (In uriparser before 1.0.2, the function family EqualsUri can misclassify two unequal URIs as equal). (CVE-2026-44928)
Fixed CVE-2026-44927 (In uriparser before 1.0.2, there is pointer difference truncation to int in various places). (CVE-2026-44927)
Hello oss-security,
just a quick note that uriparser 1.0.1 released today is fixing CVE-2026-42371: integer overflow in text range comparison.
Some key links are:
- The change log of release 1.0.1 https://github.com/uriparser/uriparser/blob/uriparser-1.0.1/ChangeLog
- The fixing pull request https://github.com/uriparser/uriparser/pull/298
- The official CVE metadata https://nvd.nist.gov/vuln/detail/CVE-2026-42371
Best
Sebastian
Fixed CVE-2026-42371 (uriparser before 1.0.1 has numeric truncation in text range comparison). (CVE-2026-42371)