Bump path-to-regexp on 1.x branch to resolve CVE-2024-45296

[pepijnve]

Would it be possible to bump path-to-regexp to a more recent version that contains the fixes for CVE-2024-45296. The current dependency on 2.4.0 is causing our application to be flagged by our customer's security scanning tools.

See https://github.com/pillarjs/path-to-regexp/security/advisories/GHSA-9wv6-86v2-598j for details.

[Legioth]

The new version is not 100% backwards compatible in some edge cases and we have evaluated that the impact of the vulnerability is quite small due to the way we're not using that library on the server.

For this reason, we're planning to create a new 2.0 branch and take that into use starting from the upcoming Vaadin 24.5 release while keeping the current version for older Vaadin versions to preserve backwards compatibility.

[EinfachHans]

Would like to see this as well, as for our company provisions we have to fix the CVE

[quincarter]

Also same here. We use Vaadin router in a few applications in our company and it is causing us to be noncompliant

[ZheSun88]

Thanks for all your feedbacks. we are aiming to get the vaadin-router 2.0.0.rc1 out this week.

[niallriddell]

Hi - we also have to remediate this issue. It would be great to get the rc out. Is there anything we can do to help?

[ZheSun88]

Hi all, Thanks for your patience. the @vaadin/router 2.0.0-rc1 has been released finally. the final version is planned next week, 🙏

[EinfachHans]

@ZheSun88 awesome, is there an changelog anywhere available?

[fabian-nowak-axa]

@ZheSun88 are there any plans to go, to a not releaseCandidate version soon?

[StefanPenndorf]

@Legioth

The new version is not 100% backwards compatible in some edge cases and we have evaluated that the impact of the vulnerability is quite small due to the way we're not using that library on the server.

For this reason, we're planning to create a new 2.0 branch and take that into use starting from the upcoming Vaadin 24.5 release while keeping the current version for older Vaadin versions to preserve backwards compatibility.

The Security Advisory (https://github.com/pillarjs/path-to-regexp/security/advisories/GHSA-9wv6-86v2-598j) suggests upgrading to 3.3.0 to fix the issue. Which version did you test? Is it a possibility to upgrade to 3.3.0 for Vaadin Plattform 23.5.x ?

[StefanPenndorf]

Just for the records: Vaadin Router 2.0.0 with the upgrade to path-to-regexp 6.3.0 has been integrated into Vaadin Plattform 24.5.0 onwards.

As minor versions are supported only 3 months after the next minor has been released (source) the support for Vaadin 24.4.x and lower has ended already. For Vaadin 24 the issue has been resolved for all versions that are still supported.

We are still working with Vaadin 23 (at least until the end of the year), so I would be grateful for a fix for Vaadin 23 as well. Nevertheless if this is hard or impossible a risk assessment would be helpful that I can share with my customers.

[Legioth]

The primary security concern for a vulnerability like this is in cases where the issue can be triggered in code that runs on the server since that can make it possible to take down the whole server with a relatively low effort in sending specially crafted requests to the server. Vaadin Router is designed to be used only in the browser where the same issue can also occur but the impact is much smaller since it only affects a single browser tab for a user that has been tricked by an attacker to open a specially crafted URL.

Under those conditions, the CVSS v3 score is reduced to something like 3.1 (AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L) which is classified as low severity compared to the medium severity of the original 5.3 score. The reduced severity comes from a higher attack complexity (the attacker must trick the user into opening an URL) and the need for user interaction. The impact of the attack is also reduced since only a single users's machine is affected rather than impacting all users of a server but that doesn't affect the score since the original score also only had a low availability impact.

I'm still keeping this issue open for the time being as an invitation for someone to present an attack vector which would justify a higher severity assessment. If a more severe attack vector is found, then we should reconsider the case.