-
-
Notifications
You must be signed in to change notification settings - Fork 185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CVE-2022-37601]/Prototype pollution found in parseQuery.js #212
Comments
Please migrate to |
From the error report The issue is here: Because of the following Per the reporting tool this was reported to you in: #212 |
@JSMike Thank you, published https://github.com/webpack/loader-utils/releases/tag/v2.0.3 |
@JSMike Is this issue resolved in the new version or I have to overwrite pareQuery.js ? |
@w3bdesign if Dependabot is still showing the vulnerability as open in your codebase but giving that message, then its because you've got multiple versions of @alexander-akait I'm sorry I have to ask, but any chance of getting this backported to 1.x? As always I'm happy to do anything I can to make it less work for you 🙂 Turns out However |
@alexander-akait this also affects us, the dependency tree is
There's no branch for 1.x else I'd have submitted a PR 😅 Hopefully the upstream issue vuejs/vue-cli#7323 is actioned soon 🤞 |
Thanks for the quick release of 1.4.1, @alexander-akait 🎉 |
🎉 |
Is there a working PoC for this issue? This same pattern of If there is a way to exploit this I'd love to know, but I feel that this is very likely a false positive. |
I also agree that this is most likely a false positive. I went into a little more details on a comment in the "fix" they did for this. The only thing I can come up that could lead to security issues is how the object created will be handled, but that is up to the apps/packages using this as a dependency to figure it out in their specific use case. Also I checked the person who reported this and they are pretty much spamming a bunch of projects alleging these types of vulnerabilities but providing no context and wasting everybody's time. In this issue this person alleges he is using a static code analyzer to find this "vulnerabilities" from a research paper. I just reported this person for spam. |
I agree, databases pay such people money not for quality but for quantity, but it has no value. I think that databases should be more stringent in exploit reporting. This is not the first time I've encountered this and I have to fix nothing a lot of time just to avoid "vulnerabilities messages". |
A minimally reproducible example should be provided, firstly internally to fix a problem, then publicly |
I actually just watched the presentation for the research paper on this and the presenter specially noted that their tool/analyzer does NOT take into account context, which that is the MAIN point of doing proper security research/disclosure. This is just so bad/annoying because you are getting reports of a CRITICAL in your apps, especially for such widely used dependencies, which you are forced to check. Oh well, time to move on. |
After some research over the last few months I have found that the original research is correct in finding that const src = JSON.parse('{"__proto__": {"polluted": true}}');
const dest = {};
Object.keys(src).forEach((key) => {dest[key] = src[key]})
window.polluted; // undefined
dest.polluted; // true This can allow an attacker to bypass filters in some cases by adding hidden keys to the I am not sure what the original vulnerability was in this case, but I found that someone mentioned the the exploit code would be a query like I looked into it and found that Whether or not the vulnerability was actually impactful given the context is another question. |
I think we agree this "prototype poisoning" is not the same as prototype pollution. It requires the code using parseQuery.js to check iterable own keys on |
Prototype pollution vulnerability in function parseQuery in parseQuery.js in webpack loader-utils 2.0.0 via the name variable in parseQuery.js.
The prototype pollution vulnerability can be mitigated with several best practices described here: https://learn.snyk.io/lessons/prototype-pollution/javascript/
The text was updated successfully, but these errors were encountered: