[ Security] [CVE-2023-0842] xml2js is vulnerable to prototype pollution

[lukewang2018]

[ Security] [CVE-2023-0842] xml2js is vulnerable to prototype pollution

Can someone help fix this security issue? Thanks.

Refer to GHSA-776f-qx25-q3cc

Affected versions
<= 0.4.23

Description
xml2js version 0.4.23 allows an external attacker to edit or add new properties to an object. This is possible because the application does not properly validate incoming JSON keys, thus allowing the proto property to be edited.
References

https://nvd.nist.gov/vuln/detail/CVE-2023-0842
https://fluidattacks.com/advisories/myers/
https://github.com/Leonidas-from-XIV/node-xml2js/

[Mikhail Chuduk]

@lukewang2018 Upgrade xml2js version to latest 0.5.0.

[lukewang2018]

@MChuduk Thanks a lot for your quick fixing!

[Marek Kubica]

@lukewang2018 You're welcome.

[Sheldon]

Due to the tags in GitHub, npm/yarn/GitHub might be confused as to what the latest non-beta release is.
Manually setting the version to 0.5.0 does resolve the security issue.
Please update the Tags in GitHub?

[sachindkagrawal18]

I tried to use version 0.5.0 in package.json and installed but still observing the security vulnerability
CVE-2023-0842. Is anyone else facing the same vulnerability issue in 0.5.0

@Leonidas-from-XIV Can you please advise

[pake-perez]

Hi @sachindkagrawal18 I had the same problem, as of NPM cli 8.3 there is a new property called overrides that can do the trick while the new version is properly released.
Just add this snippet on your package.json

"overrides": {
  "officeparser": {
    "xml2js": "0.5.0"
  }
}

That worked for me :D

[Alvin Cheng]

Bro dependabot was annoying me this whole time just because of this! haha

[Simen Bekkhus]

@Leonidas-from-XIV any chance of backporting the fix to 0.4? xml2js is pulled in from a deep transitive dependency, and getting every dependency to upgrade isn't gonna be quick.

I know I can force a newer version, but it's hard to say if that's safe without a changelog of some sorts. And regardless, forcing every consumer (14M weekly downloads) to do so seems a bit much.

[Marek Kubica]

@SimenB I don't think it's possible, as the fix is a backwards-incompatible change (#603), at least depending on how you use the object that gets returned (if you just use it as a data object . I first thought it could be mitigated in an easier way to stay in the 0.4 series, but this looks like a game of whack-a-mole.

If you have a PR that would fix the issue in a compatible way, I am perfectly happy to add another release to the 0.4 series.

But you can use overrides to force dependencies to use newer versions, maybe that helps?