Vulnerability in the dependency tree

[denis-sokolov]

With the latest versions of @wdio/visual-service and @wdio/image-comparison-core, a published vulnerability CVE-2026-31808 is included deeper in the dependency tree because of an old version of file-type.

The root cause is the seemingly unmaintained dependency jimp (issue in their tracker).

@wdio/visual-service@9.2.0
└─┬ @wdio/image-comparison-core@1.2.0
  └─┬ jimp@1.6.0
    └─┬ @jimp/core@1.6.0
      └── file-type@16.5.4

Although not the fault of the @wdio, consumers of @wdio packages can’t trivially avoid including this vulnerability. Tools such as npmx report a vulnerability as present in @wdio:

The workaround might be to migrate away from jimp, or switch to a fork of it.

[wswebcreation]

Thanks @denis-sokolov

I'll check it our and try to find a solution for it

[wswebcreation]

@denis-sokolov
I've looked into this, and I have a challenge here. First of all, Jimp is not well-maintained, but it does what it needs for this project (no extra system deps, no binaries, just a simple JS lib). Replacing JIMP with a new module has some impact and will cost me a lot of time. I also need to do some good research and see which lib might be the best to use (Sharp is mentioned a few times, but also uses precompiled binaries, which I already had issues with in the past when using node-canvas).

From what I can see now is this. IMHO the attack surface here is limited. file-type is used by @jimp/core only to detect image MIME types when reading a buffer. In @wdio/image-comparison-core, every image passed to jimp comes from:

• WebDriver screenshots (browser-controlled base64 data)
• Local files on disk written by the framework itself

There's no path where untrusted external input is fed directly into jimp. This "reduces" actual exploitability compared to, say, a web server processing user-uploaded images.

The real and immediate risk is reputational/compliance

• Tools like npmx publicly flag @wdio/visual-service as vulnerable
• Enterprise users running internal security scans will get audit failures
• Some orgs have policies that block packages with known CVEs from being installed at all, this can block adoption
• there's an impact on trust even if the vulnerability is unexploitable in practice

I "want to wait" what will happen to the PR and will watch it. In the meantime I'll also look for a replacement

[denis-sokolov]

This all seems like the right overview. I didn't mean to cause you any inconvenience, I only meant to shine light on an existing issue.

One option you don't mention is switching to a fork. It's only a little bit of effort compared to switching away from jimp altogether. The fork that has the PR that updates the file type dependency is one place to consider.