Several AV Engines are hating on /usr/bin/jq from jq (1.6-1) - false positive IMO

Few days ago I noticed I could not use jq in my Ubuntu 20.04 in WSL2.
-bash: /usr/bin/jq: cannot execute binary file: Exec format error

Realized that Windows Defender 1.321.1943.0 had quarantined jq as Trojan:Win32/Casdet!rfn.

I did some testing and checked the sha256sum of jq. I also spun up a brand new focal install on Digital Ocean and installed jq from the official, signed repo. sha256sum matched.

sha256sum /usr/bin/jq
bcfa215dec8fe15d4265c508c39c1ebafb7370acc95721e4e7d610b0459eb8dd  /usr/bin/jq

I submitted it as a false positive to Microsoft and the next day got a reply that my submission has been verified and it will be resolved. Yay!

2 days later they pushed new definitions and we are now on 1.321.2133.0.

Start up Ubuntu 20.04, try to use jq that I had reinstalled and it gets quarantined again. This time as Trojan:Linux/CoinMiner.N!MTB.

I see in that several engines do see jq as malware.

I resubmit it to Microsoft referring to the provenance of the binary and the previous submission. Got a response the next day saying

We have determined that the files meet our criteria for detection. At this time detection will remain in place.


How can we stop this madness? This version of jq (1.6-1) has been in the signed focal repo for months. I am fairly certain it is a false positive.

This is probably better discussed upstream, providing the false positives (or true positives) can also be reproduced with upstream code.

1 Like

Thanks @vanvugt

Upstream says they are not the ones who compile the binary we all get from the Ubuntu repo but that github issue you linked seems like a good place to figure this out.

Please also open an Ubuntu bug:

ubuntu-bug jq

and mention in it. That Ubuntu bug should replace this discussion topic.