reduxjs / redux

A JS library for predictable global state management

Home Page:https://redux.js.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Vulnerable dependencies (indirect security issues)

davidz1337 opened this issue · comments

Dear Maintainers,

I hope this message finds you well. I wish to bring to your attention a potential security issue that I've discovered in our recently installed package. Upon conducting a vulnerability scan with Vulert on the lock file, it has come to my attention that there are more than 2 vulnerable dependencies.

Understanding the significant security risk these vulnerabilities could pose to our entire project, I am unsure about the proper procedure for reporting under responsible disclosure. Although some of these dependencies are development-only, they exist within the lock file and might surface in the vendor folder. Hence, it's crucial to consider their management.

For a comprehensive understanding, you can access the report of the scanned package-lock file at the following link: https://vulert.com/vuln-scan/list/36544372-a25d-44ef-a44f-40fede1ad000

I urge us to take swift action to rectify these vulnerabilities to safeguard the security of our project. If further information or elaboration is needed, do not hesitate to contact me.

Additionally, the lock file I scanned can be found here: https://github.com/reduxjs/redux/blob/master/yarn.lock

I eagerly await your prompt response.

Best regards.

Thank you, but these vulnerabilities do not apply to how we use these packages.
These vulnerabilities might make some sense in very edge-case scenarios where those libraries run on a server and handle user-provided data.
But given that they are devDependencies and will only ever be called with code that we write on our own, those vulnerabilities would essentially require that we attack ourselves with our own code on our development machines.

Also, they are of the RegexDos type, which means that all an attacker could do would be to slow down our computers on a single core.

=> This is very low risk. Otherwise, we would already have updated those. Again, thank you, but I think this is not an issue for us.