The argument list is where the bug lived. A DNS change on macOS is privileged, so the app requests authorisation and then invokes `networksetup` on the far side of the prompt [3]. The remedy tells you what the break looked like: the developer's second rule is to pass arguments as an array, so there is no shell to interpret them and no quoting to get right [8]. Format that same string into a command line instead, and a semicolon in the resolver box is a second command inheriting the privileges of the first.
He names the mental model that produced it: it is my own app, and the field is for an IP address, so it will contain an IP address [5]. Both halves are wrong, he writes, and the second half is the one that generalises, because the reason to ask macOS for authorisation at all is that the code after the prompt has more power than the code before it [5].
The consent argument goes the same way. According to the post, the prompt authorises the operation the app described, not whatever ends up in the argument list, and a user who agreed to change DNS servers agreed to that and nothing else the string can be made to mean [7].
The objection worth taking seriously is the self-harm one. His answer is that the value need not be typed by the person at the keyboard: a paste from a webpage, a support article that says paste this into the custom DNS box, an accessibility-driven automation [6]. By that point the app has trained the user to expect an admin prompt at exactly that step [6]. That is what makes it someone else's bug and not just the owner's.
The fix order does not transfer everywhere, and here is the condition that decides it. Parsing works here because the target grammar is closed: a DNS server is an IPv4 or IPv6 address, so you parse the string into an address type and refuse anything that does not parse, rather than stripping characters you dislike [9]. Blocklists are a bet that you enumerated the shell, and the shell has more free time than you do [11]. Where the accepted value has no closed grammar the recipe stops carrying, which the post's own next item shows: Sonar exports the network map, and a device name is set by whoever is on your network [14]. The array-argument rule still applies there, but there is no address type to parse a device name into.
On the evidence: this is a developer's account of his own code. The post cites no CVE, no advisory and no outside reproduction, and it does not say whether the injection ever reached a released build [16]. None of that is needed for the mechanism, which is checkable in your own helper this afternoon, but it does mean the scope claim rests on one person's audit.
That audit produced twenty-six fixes, of which four are described [12], leaving twenty-two uncharacterised [15]. The two visible beyond the injection are the same category in different clothes: NextDNS and Pi-hole API tokens sitting in a preferences file that any process running as you can read and that gets swept into backups and sync [13], and the CSV export whose description runs out mid-sentence [14].
What survives the specifics is a rule about types. The value crossing an authorisation prompt should arrive as an address type, already validated before it ever reaches the privileged code.
