Memory leak detected about inflight

[milotoor]

Considering the issue has been open 6 years and the inflight.js file has not been edited in 7 years, I think it's likely this isn't going to be addressed here. If your situation is like mine, you are here because Snyk started complaining about this yesterday (why only yesterday? Who knows...) and a package you depend on depends on this package or, more likely, a package you depend on depends on glob which at one point in time depended on inflight. The actively-maintained glob package no longer depends on inflight, so your best bet is to (a) pin your glob version to something greater than v9, (b) to (respectfully) bug package maintainers to upgrade their glob dependency version string, or (c) to ignore the issue because it's probably not doing you real harm anyway. For myself, it's option (c).

[tysoncadenhead]

Can this issue be closed if it's been merged? I'd love to get the warning out of our security scanner

[ak-seek]

We are getting Snyk high issues reported due to this memory leak: https://security.snyk.io/vuln/SNYK-JS-INFLIGHT-6095116

[skruzlik]

Any chance to have this fixed? This package is used all over the place, so it is getting highlighted as a vulnerability almost constantly.

[Good-man]

Is this still an issue? I see that a fix was merged but the issue is still open.

[JasoonX]

In our project, we resolved this issue by introducing a pre-installation step that utilizes 'npm-force-resolutions'.
This approach was complemented by adding 'glob' to the 'resolutions' section within our 'package.json'.
This modification effectively enforces the use of a newer version of 'glob'.

package.json

{
  ...
  "scripts": {
    ...
    "preinstall": "npx npm-force-resolutions",
  },
  "resolutions": {
    "glob": "10.3.10"
  }
  ...
}

[IdanAdar]

Snyk at it again. 🙄

[rreeves8]

I've been following this issue, and I can see that it has been open for a considerable amount of time. I understand that addressing memory leak issues can be complex and time-consuming.

I was wondering if there has been any recent progress in resolving this problem. Is there any update or new information that can be shared? I'm interested in staying informed about the current status of the situation.

If there are specific steps to reproduce the problem or any additional information that could help, I'd appreciate the details.

From my understanding the biggest problem is glob version 4 uses this package. Which in turn effects a large number of packages. However glob version 10 no longer uses inflight. So it's just a matter of encouraging package maintainers to update there dependencies to resolve it.

[relaxnow]

As far as I can see this was not fixed.

Maybe @Good-man saw #5 (reference) and thought it meant a fix was applied?

[thetumper]

Issue and PR in help-me, which resolves transitive issue in pino-pretty:

mcollina/help-me#17
mcollina/help-me#18

Please give a thumbs up there, to help get some priority on it.

[adominguezepiuse]

I've been following this issue, and I can see that it has been open for a considerable amount of time. I understand that addressing memory leak issues can be complex and time-consuming.

I was wondering if there has been any recent progress in resolving this problem. Is there any update or new information that can be shared? I'm interested in staying informed about the current status of the situation.

If there are specific steps to reproduce the problem or any additional information that could help, I'd appreciate the details.

[ramdaniAli]

using npm-force-resolutions doesn't fundamentally resolve the issue since running npm ls glob may still show that the old, vulnerable version of the glob package is present in your dependency tree. A more robust solution is to leverage the overrides feature in your package.json. By explicitly specifying an override for glob, like this:

{
  ...
  "overrides": {
    "glob": "10.3.10"
  },
  ...
}

You ensure that the specified version of glob is applied throughout your project. However, for this approach to take effect, you will need to perform a fresh installation, you should delete the node_modules folder and the package-lock.json file, and then run npm install. This process forces npm to reinstall all dependencies, taking into account the override you've specified for glob. After doing this, Snyk should no longer report any warnings related to glob, confirming that the chosen version is now in use without any remnants of the old version.

[rreeves8]

using npm-force-resolutions doesn't fundamentally resolve the issue since running npm ls glob may still show that the old, vulnerable version of the glob package is present in your dependency tree. A more robust solution is to leverage the overrides feature in your package.json. By explicitly specifying an override for glob, like this:

{

  ...

  "overrides": {

    "glob": "10.3.10"

  },

  ...

}

You ensure that the specified version of glob is applied throughout your project. However, for this approach to take effect, you will need to perform a fresh installation, you should delete the node_modules folder and the package-lock.json file, and then run npm install. This process forces npm to reinstall all dependencies, taking into account the override you've specified for glob. After doing this, Snyk should no longer report any warnings related to glob, confirming that the chosen version is now in use without any remnants of the old version.

This isn't a robust solution either. Overriding dependency versions can create instability. Each package version is not exactly the same and changing it for every use case will most likely break stuff.

[ramdaniAli]

Certainly, overriding a sub dependency versions carries inherent risks, such as the introduction of unpredictable behavior or a destabilization of system components. Despite these concerns, in my specific situation where glob functions solely as a dependent of argon2, the associated risks are somewhat contained and manageable. At present, our most prudent course of action would be to remain vigilant for updates issued by the argon2 maintainers, in the hope that they will provide a comprehensive solution to the dependency concern.