jq on Mac: macOS Ships 1.7.1, 20 CVEs Behind Upstream

Yes, macOS ships jq. On the Mac mini M4 that runs this blog, macOS 26.4.1 has it at /usr/bin/jq, and jq --version prints jq-1.7.1-apple. I ran 23 checks against Apple's binary and the upstream jq 1.7.1 release, and they behaved identically on all 23. jq 1.7.1 came out in December 2023. Since then the 1.8.0, 1.8.1 and 1.8.2 releases have listed 20 CVE IDs between them, and none of the four security fixes I tested is in Apple's copy. Two one-line programs crash it with a segfault. A third makes it take 6.0 GB of RAM in 2.6 seconds on a 16 GB machine.

I didn't come out of this clean either. The Homebrew jq on the same machine was 1.8.1, one patch behind, and it crashed on the same two one-liners. Below is which jq your shell and your scheduled jobs actually run, what the built-in one is missing, and how to get a current jq on a Mac with or without Homebrew.

Is jq installed on Mac by default?

It is on macOS 15 Sequoia and later. Before that you had to install it yourself. When Sequoia came out in September 2024, users posted the version string on Hacker News: jq-1.6-159-apple-gcff5336-dirty, which is a development snapshot from between 1.6 and 1.7. By macOS 26.4.1 the version is 1.7.1. I only have this one machine, so I can't tell you which point release made the switch. Here's what the binary looks like on 26.4.1:

$ /usr/bin/jq --version
jq-1.7.1-apple
$ file /usr/bin/jq
/usr/bin/jq: Mach-O universal binary with 2 architectures: [x86_64] [arm64e]
$ otool -L /usr/bin/jq
/usr/bin/jq:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)
$ codesign -dv /usr/bin/jq 2>&1 | grep -E 'Identifier|Platform'
Identifier=com.apple.jq
Platform identifier=26

It's 1,492,208 bytes and links only libSystem, because the regex library (oniguruma) is compiled in. Homebrew's build loads libjq and libonig as separate dylibs. The file sits on the sealed system volume, so you can't delete or replace it. The only thing you control is which jq runs first.

Which jq runs: Terminal versus scheduled jobs

In an interactive shell with Homebrew set up, /opt/homebrew/bin comes before /usr/bin, so jq means Homebrew's copy. Outside that shell, it usually doesn't:

$ which -a jq
/opt/homebrew/bin/jq
/usr/bin/jq
$ env -i /bin/sh -c 'command -v jq'
/usr/bin/jq
$ launchctl print gui/$(id -u)/com.mmm.daily-content | grep -A2 'default environment'
	default environment = {
		PATH => /usr/bin:/bin:/usr/sbin:/sbin
	}

A LaunchAgent with no PATH in its plist gets /usr/bin:/bin:/usr/sbin:/sbin, so a bare jq in that job runs Apple's 1.7.1. The script that publishes this blog prepends Homebrew's directory on line 8. I measured why that line is there in launchd plist environment variables. If your script works in Terminal and fails under launchd or cron with jq: error: trim/0 is not defined, this is the reason. It's the same kind of mismatch as macOS rsync, where the system binary is a different program from the one most guides describe.

What /usr/bin/jq can't do

I wrote 23 one-line checks covering the builtins and behavior changes in the jq 1.8.0 release notes, plus a few controls that should be the same everywhere. I ran them against four binaries: Apple's, the upstream 1.7.1 macOS release, Homebrew's 1.8.1 and the upstream 1.8.2 release. Apple's binary matched upstream 1.7.1 exactly, including the error text, so the -apple suffix changes nothing I could observe. One check, toarray, failed on all four, so it doesn't count. Of the other 22, Apple's jq differs from 1.8.2 on 14:

Program	/usr/bin/jq (1.7.1-apple)	jq 1.8.2
" hi " | trim (also ltrim, rtrim)	compile error, exit 3	"hi"
"xax" | trimstr("x")	compile error, exit 3	"a"
"true" | toboolean	compile error, exit 3	true
add(1,2,3)	compile error, exit 3	6
[skip(2; 1,2,3,4)]	compile error, exit 3	[3,4]
"a%20b" | @urid	"urid is not a valid format", exit 5	"a b"
have_decnum, have_literal_numbers	compile error, exit 3	true
"éa" | indices("a")	[2] (byte offset)	[1] (code point)
[last(empty)]	[null]	[]
" 1 " | tonumber	1	error, exit 5
[limit(-1; 1,2)]	[1,2]	error, exit 5
123 | ltrimstr("1")	123	error, exit 5
input NaN123	null	parse error, exit 5

The first group is missing functions, and those fail loudly at compile time with exit code 3. The bottom five are worse for scripts because both versions exit 0 on some of them and just return different answers. indices on non-ASCII text returns byte offsets in 1.7.1 and character offsets in 1.8, so a script that slices strings by those offsets gets different results depending on which jq ran it. 1.7.1 also caps JSON nesting at 256 levels. A 300-deep array fails on Apple's jq with "Exceeds depth limit for parsing", and 1.8.x reads anything up to 10,000.

The security fixes Apple's jq doesn't have

The release notes for 1.8.0 list 3 CVEs, 1.8.1 lists 1 CVE and 1 GitHub advisory, and 1.8.2, from June 20, 2026, lists 16 CVEs and 2 advisories. Most are memory bugs that need a crafted input to show up. I tested three of those CVEs that have a simple trigger, plus one crash fix from 1.8.2 that has no CVE number:

The memory one is the easiest to hit. jq -n '[1] | .[536870912] = 1 | length' makes jq build an array with 536,870,913 elements. On Apple's jq that took 2.56 seconds and a maximum resident set of 6,025,773,056 bytes, measured with /usr/bin/time -l, and then it printed the length. That's CVE-2024-23337, and since 1.8.0 jq refuses with "Array index too large" in under 10 ms. Any script that builds an index from input it doesn't control can be pushed into this.

Both crashes are one-liners. jq -n 'reduce range(1000000) as $i (null; [.]) | 1' nests a value a million levels deep and segfaults. The 1.8.2 notes list a fix for stack overflow when freeing deeply nested values, without a CVE number. jq -n 'null | setpath([range(1000000)|0]; 1)' segfaults too. Both exit with 139 on Apple's jq, upstream 1.7.1 and Homebrew 1.8.1. jq 1.8.2 finishes the first and rejects the second with "Path too deep", which is the fix for CVE-2026-33947. In a pipeline the 139 is easy to miss, as I found with bash pipe exit codes, because the shell reports the status of the last command.

Speed is not the reason to switch

I also expected the system build to be slower. It isn't, by any margin that matters. I generated a 92.6 MB JSON array of 600,000 objects and the same rows as NDJSON, then ran each program three times per binary and took the median:

Task	Apple 1.7.1	upstream 1.7.1	brew 1.8.1
length on the array	0.82 s	0.78 s	0.85 s
map(select(.active)) | length	1.03 s	0.94 s	1.02 s
NDJSON select(.score>500) | .id	1.04 s	0.95 s	1.04 s
NDJSON regex test()	1.69 s	1.59 s	1.69 s
-S . (sort keys, pretty print)	3.39 s	3.28 s	3.47 s

All three are within 10% of each other on every task. Peak memory was the same too: about 1.10 GB to load the 92.6 MB array and under 3.2 MB to stream the NDJSON. I didn't benchmark 1.8.2. The reason to switch is the missing builtins and the unfixed bugs, not speed.

How to install a current jq on Mac

With Homebrew it's brew install jq. If you already have it, look at the version, because mine was stale: the installed jq was 1.8.1 while the formula was at 1.8.2. brew update only refreshes the formula list, as I measured in brew update vs brew upgrade. You need brew upgrade jq to replace the binary.

Without Homebrew, the jq project publishes a standalone macOS binary on the release page:

$ mkdir -p ~/.local/bin
$ curl -sSLo ~/.local/bin/jq https://github.com/jqlang/jq/releases/download/jq-1.8.2/jq-macos-arm64
$ shasum -a 256 ~/.local/bin/jq
2d75340ba57a4b4b4c8708a21c2dc8e958a48aaa8bba13b27f77f6e4c0eca07e  /Users/you/.local/bin/jq
$ chmod +x ~/.local/bin/jq
$ ~/.local/bin/jq --version
jq-1.8.2

Compare the hash with the sha256sum.txt on the release page. Intel Macs need jq-macos-amd64, and running the wrong one gives the error covered in zsh exec format error. A file downloaded with curl doesn't get the quarantine attribute (on this machine it carried only com.apple.provenance), so it runs without a Gatekeeper prompt even though spctl -a rejects it. A copy downloaded through a browser would be quarantined and checked. Put ~/.local/bin ahead of /usr/bin in PATH, both in your shell profile and in any launchd plist that calls jq.

For scripts that might run on someone else's Mac, check the version instead of guessing:

case "$(jq --version)" in
  jq-1.[0-7]*) echo "need jq 1.8+, found $(jq --version) at $(command -v jq)" >&2; exit 1 ;;
esac

On Apple's jq this prints need jq 1.8+, found jq-1.7.1-apple at /usr/bin/jq and exits. If you'd rather support both versions, skip the 1.8-only builtins. sub("^\\s+|\\s+$"; ""; "g") trims whitespace and returned "hi" on both Apple's jq and 1.8.2. That fixes the missing functions. It doesn't fix the crashes, which only a newer binary does.

FAQ

Is jq installed on Mac by default?

Yes, since macOS 15 Sequoia. It lives at /usr/bin/jq. Sequoia shipped a development snapshot that reports jq-1.6-159-apple, and macOS 26.4.1 ships jq-1.7.1-apple, which behaves the same as upstream jq 1.7.1 from December 2023. It lacks the jq 1.8 builtins such as trim, toboolean and skip, and the security fixes released in jq 1.8.0 through 1.8.2. macOS 14 and earlier don't include jq.

How do I install jq on Mac without Homebrew?

Download the standalone binary from the jq GitHub release page: jq-macos-arm64 for Apple silicon or jq-macos-amd64 for Intel. Check its SHA-256 against sha256sum.txt on the same page, run chmod +x on it, and put it in a directory such as ~/.local/bin that comes before /usr/bin in PATH. A file downloaded with curl isn't quarantined, so macOS runs it without a Gatekeeper prompt.

Why does my script use a different jq than Terminal?

Because the PATH is different. An interactive shell set up for Homebrew puts /opt/homebrew/bin before /usr/bin, so jq means the Homebrew build. launchd jobs without a PATH key get /usr/bin:/bin:/usr/sbin:/sbin, and env -i shells get a similar default, so the same jq command runs the built-in 1.7.1. Set PATH in the plist or the script, or call jq by its full path.

Update 2026-10-10: sqlite3 has the same problem. /usr/bin/sqlite3 on macOS 26.4.1 says 3.51.0, but its source is dated June 2025, before that release. It also accepts misspelled double-quoted column names and can't load extensions. Homebrew's copy is keg-only, so installing it doesn't change which sqlite3 runs. Details in sqlite3 on Mac.

Method: every result above was measured on a Mac mini M4 (Mac16,10, 16 GB) running macOS 26.4.1 (25E253) on October 10, 2026. I compared four binaries: /usr/bin/jq, the upstream jq 1.7.1 and 1.8.2 jq-macos-arm64 release downloads (SHA-256 0bbe619e… and 2d75340b…), and Homebrew's jq 1.8.1. I ran 23 one-line checks on each and recorded exit codes and output, ran the CVE probes with /usr/bin/time -l, and timed the benchmark three times per binary on generated data. The Sequoia version string comes from two Hacker News comments, and CVE counts come from the jq 1.8.0, 1.8.1 and 1.8.2 release notes. Not tested: Intel Macs, macOS versions other than 26.4.1, Apple's jq on Sequoia, and the 16 CVEs fixed in 1.8.2 that need a crafted input file. Apple might backport fixes to its jq in a later macOS update, and I'll recheck when this machine gets one.