そんな恐怖の壇上体験を実際に経験したのは、セキュリティ研究者のユヴァル・ハノク・ヒルシェンバイン・サデ氏だ。オンラインでは「jachashx」のハンドルネームで活動している。jachashx氏は、2026年8月6～9日にかけてラスベガスで開催された、世界最大級のハッカーカンファレンス「DEF CON 34」に登壇した。

　jachashx氏は、そのいきさつを2026年9月5日に、「How can you not be romantic about UNIX domain sockets？」（UNIXドメインソケットにロマンを感じないわけがないだろう？）という記事にまとめ、自身のWebサイトで公開した。この体験談は、「Lobsters」といった技術者コミュニティーでも話題になった。

　jachashx氏の記事によると、同氏はDEF CON 34で「Rage Against the Sandbox」と題した講演を行った。プレゼンでは、iOSアプリの中に仮想マシンとSSHサーバを構築するデモを披露した。iOSでは、アプリが自由に子プロセスを作成できない仕様となっている。そこでこの仮想マシンでは、同じアプリ内に複数のスレッドを作り、メモリや各種リソースを複製することで、あたかも複数のプロセスが存在するかのような環境を構築し、仮想的なマルチプロセスを実現していた。そしてデモでは、この環境上でマルチプロセスを必要とするSSH接続を介し、iOSのセキュリティを突破してエクスプロイト（攻撃コード）を実行することになっていた。

　ところが、jachashx氏がデモを始めるやいなや、アプリがいきなりクラッシュしてしまった。もう一度起動するとアプリは正常に動き、デモ自体は無事に成功したという。プレゼンが終わって一安心、と思いきや、jachashx氏はクラッシュの原因を究明することにした。

　帰宅後に調査すると、クラッシュには奇妙な規則性があることが分かった。iPhoneを起動した直後にアプリを実行すると必ずクラッシュするが、アプリを再度起動すると問題なく動作する。端末を再起動すると、再び最初の1回だけクラッシュするという。

　毎回同じ条件で発生していることから、ランダムな要因ではないとjachashx氏は判断した。そこで、アプリがどの処理で停止していたのかを調べたところ、行き着いたのが、アプリが仮想端末「TTY」を構成するために利用していたUNIXドメインソケットだった。UNIXドメインソケットとは、同じコンピュータ上で動作するプログラム同士がデータをやりとりするための仕組みだ。

　今回の仮想マシンでは、互いにつながった一対のソケットを作成し、SSHで動作するプログラムと仮想端末の間を橋渡ししていた。その際、ソケットの作成時に記録した「inode」番号と、ファイルやソケットの情報を取得する「fstat()」で改めて取得したinode番号を比較していた。inode番号とは、UNIX系OSがファイルやソケットなどを識別するために使う番号だ。同じソケットを参照しているのであれば、当然、同じ番号が返されるはずだった。

　ところが、iPhoneの起動後、最初にfstat()で情報を取得したソケットでは、2回の確認で異なる番号が返っていた。仮想マシンはこれを異常と判断し、自ら動作を停止していたのだ。

　jachashx氏は、iOSで使われている「XNU」カーネルのコードを追跡した。すると、UNIXドメインソケットの情報を返す「uipc_sense()」という処理に、問題の原因があることが分かった。

　XNUでは、ソケットのinode番号が必要になった際、まだ番号が設定されていなければ（=0）、グローバルカウンター「unp_ino」の値をinode番号として割り当て、その後に「unp_ino++」でカウンターを1つ進める。いわゆる後置インクリメントの処理だ。

　カウンターはシステム起動時に0から始まるため、最初にfstat()で情報を取得したソケットには、inode番号として0が割り当てられる。ところがXNUのコードでは、inode番号が0の場合、「まだ番号が割り当てられていない」と判断してしまう。

　そのため、同じソケットに対して再びfstat()を実行すると、その時点のカウンターの値を使って別のinode番号が割り当てられる。こうして、同じソケットを確認しているにもかかわらず、最初とは異なる番号が返されることになる。

　この問題は、カウンターを先に増やしてから値を使う「前置インクリメント」（「++unp_ino」と記述）にすれば回避できる。つまり、原因はカーネル内に残されていた、単純な処理上のミスだった。

　jachashx氏はさらに、GitHubでXNUの過去のコミットをたどり、このインクリメント処理がいつから存在していたのかを調べた。すると、2001年3月に「Mac OS X 10.0」とともにリリースされたXNU 123.5にも、同じバグが存在していた。Mac OS Xの登場当初から残されていた、25年前のコードだった。

　さらにjachashx氏は、XNUが「Rhapsody」カーネルの後継であることに着目した。Rhapsodyのカーネルは「Mach 2.5」と「4.4BSD」をベースとしており、Appleが1997年に買収したNeXT社のOS「NeXTSTEP」カーネルを改良したものでもある。一方、そのNeXTSTEPはMachと「4.3BSD」をベースとしていた。

　そこでjachashx氏は、さらに時代をさかのぼり、当時のBSDのコードを調べることにした。

　調査対象となったのは、1988年6月に公開された「4.3BSD-Tahoe」だ。すると、そこにも同じバグが存在していた。

　さらにBSDのコードをたどっていくと、コードの歴史を保存した「unix-history-repo」のコミット「18a9fea」から、問題のコードが最後に変更されたのは1985年12月20日だったことが分かった。

　それ以前のコードでは、fstat()を実行するたびに異なるinode番号が返されていた。つまり、この変更によって同じソケットに同じ番号を保持させるようになった一方、最初に割り当てられる0を「未設定」と判断してしまう不具合が残った。

　まさに「ソフトウェア考古学」と言えそうだ。そして、こんな話を聞けば、jachashx氏が今回の記事に付けたタイトル通り、UNIXドメインソケットにロマンを感じずにはいられないではないか。

上司X：　DEF CONの壇上で起きたアプリのクラッシュを調べたら、最新のiPhoneの中に残っていた約40年前のバグへたどり着いた、という話だよ。

ブラックピット：　40年前というと、iPhoneどころかスマートフォン自体が影も形もない時代ですよね。

上司X：　実質的にはiPhoneが直接関係あるわけじゃないからな。iOSのカーネルに残っていたバグだ。

ブラックピット：　分かってますって。それにしても、そんな昔のバグが、よく今まで残っていましたねえ。

上司X：　「端末の起動後、1回目のUNIXドメインソケットのinode割り当て」という、限定的な条件でしか表面化しなかったからだろうな。

ブラックピット：　誰も通らない路地に、40年間ずっと落とし穴があったようなものですか。

上司X：　ビミョーな例えだな（笑）。ただ、このコードが単純に40年間ずっと問題を起こし続けていたというより、jachashx氏のちょっと特殊なアプリによって、初めて見える形になったと考えるべきだろう。

ブラックピット：　なるほど。僕のコードにも、未来のエンジニアが発掘してくれるようなものが眠っているかもしれませんね！

上司X：　バグを歴史遺産みたいに言うんじゃないよ（笑）。未来まで残したいのはよい仕事の方だ。でも、最新のiPhoneから1985年のコードへたどり着くなんて、確かにロマンのある話ではあるよなあ。俺もそんなロマンな出来事に巡り会ってみたいものだよ。