lexfiend

Possibly because:

The machine I am using is MacBook Pro, 2019 (2.4 GHz Quad Core i5, 8GB, 256GB SSD, Big Sur 11.1)

Given the target schema, 100M rows with only 8GB RAM risks hitting swap hard.

25 years ago, junior sysadmin me had to restore our server's drives from tape. To my horror, all the backup tapes were corrupted. It took a while to figure out what happened; my 2am cron job script basically did this:

  run_backup & eject_tape

I also changed the script to:

  run_backup && test_backup && eject_tape

The simplest mitigation probably bears mentioning: Prepend all wildcarded relative paths with `./`, because `rm ./*` does what you'd expect.

This "vulnerability" doesn't even need to involve a shell at all - any exec*() with the same arguments will have the same result.

Wildcard expansions are done by shells, so no, exec() wouldn't trigger this "vulnerability".

Unless you're talking about a specific language's exec() that either does its own wildcard expansion, or actually runs its arguments in a shell.