طريقتان للخروج من بيئة OpenAI Codex المعزولة: Heapjack وOverpatch

في 15 سبتمبر 2026، نشر أورين يومتوف، كبير باحثي الأمن في Accomplish AI، سردًا تقنيًا لطريقتين منفصلتين للخروج من بيئة العزل التي تحيط بوكيل البرمجة Codex التابع لـ OpenAI. وقد أُبلغت OpenAI بكلتيهما في 12 أغسطس 2026، وتم إصلاحهما خلال ثمانية أيام وفقًا لما كتبه: Heapjack في Codex Desktop build 26.818.21641 وOverpatch في Codex CLI 0.149.0. وHeapjack أخطر الاثنين. فهو لا يتطلب من الشخص المستهدف سوى فتح مستودع في Codex وطرح سؤال عن الشيفرة، ويعمل في وضع القراءة فقط، وهو أشد الأوضاع صرامة الذي يقدمه المنتج، دون طلب موافقة ودون عرض أي شيء على الشاشة. ولم يُخصص أي CVE لأي من العيبين ولم تُنشر إرشادات مستقلة من OpenAI، وفقًا لـ Cloud Security Alliance، ولم يُبلَّغ عن أي أذى لحق بأحد بسببهما. وهو مُدرج إلى جانب مدخلات أخرى للتحكم بالوكلاء هذا العام في أرشيف حوادث الذكاء الاصطناعي، حيث يتضمن كل سجل وثائقه المصدرية ودرجة الثقة وعلامة النزاع.

Heapjack: ظلّ الرمز في كومة ذاكرة كان بإمكان الجانب غير الموثوق قراءتها

لا يسأل Codex Desktop قبل تثبيت المكوّن الذي هاجمه Yomtov. فعند التثبيت يكتب كتلة node_repl في ملف التهيئة العام على المسار ~/.codex/config.toml، ويُبلِغ Yomtov أنه لا يوجد أي اشتراك اختياري ولا أي إعداد يُعطِّله. ولأن هذا الإدخال يقيم في التهيئة المشتركة بدلًا من أن يكون خيارًا خاصًّا بكل مستخدم، فإن مستخدم Codex CLI العادي يرث الأداة نفسها دون أن يُسأل قط.

أداة node_repl هي نفسها برنامج أصلي يعمل خارج بيئة العزل. يمكنها فتح التطبيقات، والاتصال بمقابس Unix، وتحرير ملف التكوين العام. وما تشغّله داخل بيئة العزل هو عملية Node.js واحدة، وتحتوي تلك العملية على سياقَي تنفيذ JavaScript: سياق موثوق يحتوي على شيفرة OpenAI الخاصة، وسياق غير موثوق يشغّل أي شيء يُطلب من الوكيل فعله.

السياق الموثوق يثبت أنه موثوق من خلال تقديم رمز عشوائي يُولَّد حديثًا في كل تشغيل. المفترض أن يكون ذلك هو الحدّ الفاصل بين السياقين. لكنه ليس كذلك، لأن كلا السياقين يعيشان داخل V8 isolate واحد يتشارك كومة ذاكرة واحدة، لذا فالرمز مجرد سلسلة موجودة في الذاكرة يستطيع الكود غير الموثوق قراءتها. وقد صاغ أحد المعلّقين الذي تفاعل مع الإفصاح على X النقطة بصراحة أكبر، في عبارة اقتبسها BleepingComputer: "تعزل سياقات V8 المتغيرات العامة، لا الذاكرة، لذا كانت العزلة في الحقيقة وعدًا لم توافق عليه كومة الذاكرة قط." هذا توصيف، وليس دليلًا؛ الدليل هو إثبات المفهوم.

إن استغلال Yomtov يفعل بالضبط ما يوضحه ذلك الوصف. تستدعي JavaScript غير الموثوقة ‎v8.getHeapSnapshot()‎، وتمسح اللقطة الناتجة بحثًا عن سلاسل نصية على شكل UUID، وتختبر كل مرشح. يعود التخمين الخاطئ برسالة «غير مصرح به». أما الرمز الصحيح المقترن بوسيط غير صالح فيعيد خطأ تحقق حقيقيًا بدلًا من ذلك. الفرق بين رسالتي الخطأ هو الأوراكل الذي يحدد القيمة الصحيحة.

وبحوزة الرمز المميز، تكتب العملية المعزولة طلب JSON الخاص بها على واصف الملف 1 — وهو أنبوب stdout نفسه الذي يستخدمه السياق الموثوق للوصول إلى العملية الأب الأصلية. تتحقق العملية الأب من الرمز المميز، فتجد رمزًا صالحًا، وتنفّذ المهمة. في إثبات المفهوم، كانت تلك المهمة هي أمر الفتح system open، الذي يسلّم الطلب إلى launchd ويطلق التطبيق خارج شجرة عمليات Codex بالكامل. ويسمح الرمز المميز نفسه بالاتصال بأي مقابس Unix، ومن بينها مقبس Docker daemon، ويصل إلى أداة لتحرير ملف التكوين العام.

كل ذلك يعمل في وضع القراءة فقط، وهو الوضع الذي يختاره المستخدم الحذر تحديدًا لأن المستودع الموجود أمامه غير موثوق. لم تظهر أي مطالبة موافقة في أي مرحلة. السيناريو العملي قصير: افتح مستودعًا مستنسخًا في Codex، في وضع القراءة فقط، واسأل سؤالًا عن الشيفرة. من كتب ذلك المستودع يحصل على تنفيذ أوامر دون عزل على الجهاز، ولا شيء على الشاشة يقول ذلك.

Overpatch: أداة ترقيع كانت تمنح الأصل لكل ما تلمسته

يكمن العيب الثاني في Codex CLI، وكيل سطر الأوامر مفتوح المصدر، وهو خلل في الأذونات لا في الذاكرة. في وضع workspace-write، يجوز للوكيل الكتابة داخل مجلد المشروع ولا مكان آخر؛ فأي أمر shell موجّه إلى الدليل الرئيسي يُرفض. كان من المفترض أن تحافظ أداة apply_patch على هذا الحد. غير أنها استمدت أذوناتها من المسارات المذكورة في الرقعة التي كانت تطبّقها، ومنحت حق الكتابة إلى الدليل الأب لكل منها.

اذكر مسارًا تحت /tmp في رقعة ما، فيتّسع المنح إلى جذر القرص، لأن أصل /tmp هو /. هذه هي الحيلة بأكملها.

يستخدم الاستغلال العامل مُدخلين في رقعة واحدة. الأول يسمّي /tmp ولا يفعل شيئًا مفيدًا — إذ يفشل، لأن الملف لا يمكنه الكتابة فوق دليل — وموجود فقط لتوسيع المنحة. الثاني يضيف سطرًا إلى .zshrc عبر رابط رمزي إلى الدليل الرئيسي. أزل المُدخل الأول وتُرفض الكتابة. أبقِه، وسيشغّل الطرفية التالية التي يفتحها المطوّر سطر المهاجم خارج العزل، مع خروج العزل من المعادلة تمامًا.

وهذا يجعل Overpatch علة استمرارية (persistence bug) وليس هجومًا لمرة واحدة. فملف بدء التشغيل المسموم يُنفَّذ مجددًا في كل صدفة (shell) يفتحها المطوّر، إلى أن يقرأ أحدهم ‎.zshrc‎ ويلاحظ السطر المضاف — ولهذا فإن إرشادات Cloud Security Alliance هي البحث عن إحداها بدلًا من انتظار ظهور عَرَض.

كلا الخطأين يضعان آلية الإنفاذ داخل الشيء الذي يجري إنفاذه.

إن صياغة Yomtov نفسها هي الجزء الذي يمتد إلى ما هو أبعد من Codex. فقد حسب apply_patch أذوناته الخاصة من مدخلات قدّمها مهاجم. وأبقى node_repl السرّ الذي يفصل الشيفرة الموثوقة عن الشيفرة غير الموثوقة في ذاكرة كان في مقدور الشيفرة غير الموثوقة قراءتها. وفي كل حالة، قيل للصندوق الرملي، من الداخل، أن يسمح بمرور شيء ما.

هذا النمط ليس جديدًا. فموقع BleepingComputer، الذي أورد خبر الكشف في 20 سبتمبر 2026، يشير إلى أن باحثي Pillar Security أظهروا في يوليو 2026 الفكرة نفسها عبر Cursor وCodex وGemini CLI وAntigravity من Google، حيث يكتب وكيل يبقى داخل بيئته المعزولة ملفًا تنفّذه لاحقًا أداة موثوقة من خارج تلك البيئة. وما يميّز الثغرتين المرتبطتين بـCodex هو تجاوز القراءة فقط في Heapjack وغياب أي إعداد لتعطيل المكوّن الذي يحمله.

الإصلاحات، وما قالته OpenAI وما لم تقله.

أصلحت OpenAI عطل Heapjack في إصدار Codex Desktop 26.818.21641، وعطل Overpatch في Codex CLI 0.149.0، وفقًا لـ Accomplish. وقد وقع كلا الإصلاحين خلال ثمانية أيام من تقرير 12 أغسطس — أي بحلول 20 أغسطس، وفق قراءة مباشرة لذلك الجدول الزمني — وأعطى يومتوف الفضل إلى OpenAI في هذا التحول.

لم تنشر OpenAI أي تنبيه أمني مستقل بشأن أي من الثغرتين، ولم يُسنَد أي معرّف CVE؛ وقد سجّلت Cloud Security Alliance كلا الغيابين في مذكرة بحثية بتاريخ 22 سبتمبر 2026. وعند طلب التعليق، قال متحدث باسم OpenAI لـ BleepingComputer: "نشكر الباحثين على تواصلهم معنا ومشاركتهم نتائجهم. لقد عالجنا كلتا المشكلتين في أغسطس، لكننا نعزز بيئاتنا المعزولة (sandboxes) باستمرار، عبر تحديثات حديثة تشدد الضوابط على الأماكن التي يمكن للوكلاء كتابة الملفات فيها وتوسع اختبار تلك الحمايات عبر المنصات."

يؤكد ذلك البيان الإصلاحات ولا يقول شيئًا عن الآليات. وهو لا يوضح ما إذا كانت تغييرات أغسطس قد أزالت نمط التصميم أو أغلقت المسارين المحددين للخروج منه. ولم يصرّح بذلك أحد من خارج OpenAI أيضًا.

ما هو ثابت، وما هو قائم على باحث واحد

يُصنّف الأرشيف هذا المدخل على أنه نتيجة بحثية: درجة الخطورة عالية، والنطاق عالمي، ودرجة الثقة B — موثّقة، لكن من مصدر واحد أو مصدر ثانوي — وغير متنازع عليها، ولم يُسجَّل أي ضرر حقيقي. وهذه الدرجة هي العدسة المناسبة لقراءة بقية هذا المقال، لأن الانقسام بين ما تؤكده أطراف عدة وما لا يؤكده إلا المكتشِف يسري في القصة بأكملها.

مُثبَت، بمعنى أن أكثر من طرف يقول به:

• الإفصاح موجود ومؤرّخ. نُشر تقرير يومتوف في 15 سبتمبر 2026؛ وأُبلِغت OpenAI بالعيبين في 12 أغسطس 2026، وحسب روايته جرى إصلاحهما خلال ثمانية أيام.

• تؤكد OpenAI أنها اتخذت إجراءً في أغسطس. وقد أخبر متحدثها موقع BleepingComputer أن المشكلتين قد عولجتا، وهو ما يدعم الجدول الزمني للإبلاغ والإصلاح بشكل مستقل عن المكتشف، رغم أن الشركة لم تنشر أي تحذير أمني ولا أي بيان تقني من جانبها.

• تُذكر النسخ المُصلحة باتساق. فقد أوردت Accomplish البناء 26.818.21641 الخاص بـ Codex Desktop والإصدار 0.149.0 الخاص بـ Codex CLI، وأعادت BleepingComputer نشر ذلك، وجاء بهما نشرة استشارية مؤرخة في 22 سبتمبر 2026 صادرة عن فريق أوغندا الوطني للاستجابة للطوارئ الحاسوبية ومركز التنسيق، التي صنّفت الثنائي بأنه «أحمر».

• لا يوجد أي CVE، ولا أي إشعار من المورّد، ولا أي استغلال مُبلَّغ عنه. وتسجّل مذكرة Cloud Security Alliance المؤرخة في 22 سبتمبر 2026 غياب كلٍّ من CVE والإشعار المستقل من OpenAI، وتفيد بعدم وجود أي حالات مؤكدة اكتشفت فيها منظمةٌ آلية الاستمرارية الخاصة بـ Overpatch قائمةً في مكانها.

• لا ينازع الأرشيف في أي من ذلك. السجل موسوم بأنه غير متنازع عليه، ودرجة الثقة فيه تعكس نمط المصادر لا أي خلاف حول الوقائع.

غير ثابت، أو لم يُثبته أحد سوى من وجده:

• تفاصيل الآلية تعود إلى يومتوف. فأوراكل لقطة الكومة، وواصف الملف المشترك، ومنح الدليل الأب — كل ذلك مستمد من تقريره وإثبات المفهوم الخاص به. أما Cloud Security Alliance، التي تُعد مذكرتها أكثر ملخصات الأطراف الثالثة تفصيلاً المتداولة، فتصف أنها جمعت بين روايته وتقرير BleepingComputer، ولا تذكر أنها أعادت إنتاج أي من الاستغلالين أو اختبرت أيًا من الإصلاحين. كما تجمع تنبيه CERT.UG المواد نفسها.

• لم تُنشر نطاقات الإصدارات المعرّضة للخطر قط. لا تُذكر سوى إصدارات الإصلاح، لذا لا توجد قائمة تحدد أي من البنيات السابقة كانت تتضمن كل عيب.

• لم يُذكر ما إذا كان التثبيت المُرقّع آمنًا من فئة العلة هذه، لا من هاتين الحالتين فحسب. إن عبارة OpenAI «التحسين المستمر لبيئاتنا الرملية» التزام عام، وليست ادعاءً بشأن آلية محددة.

• لم يُبلَّغ عن أي شخص يستغل أيًا من الثغرتين. هذا غيابٌ للإبلاغ، وليس إثباتًا لغياب الاستغلال، ويُظهر النموذج الأولي أن مسار Heapjack لا يترك شيئًا على الشاشة يمكن للمستخدم ملاحظته.

ما يمكن للمستخدم اتخاذ إجراء بشأنه

أي شخص يستخدم إصدار Codex Desktop أقدم من 26.818.21641، أو إصدار Codex CLI أقدم من 0.149.0، يقع في الجانب المعرّض للخطر من الحد الذي يرسمه Accomplish، والتحديث هو العلاج الوحيد الذي يقدّمه الإفصاح. إلى جانب ذلك، توصي Cloud Security Alliance بتدقيق جلسات Codex Desktop السابقة التي شملت مستودعات غير موثوقة بحثًا عن نشاط launchd أو open وعن اتصالات مقبس Docker، وقراءة ملفات بدء تشغيل shell — .zshrc و.bashrc وما شابههما — بحثًا عن أوامر أُضيفت بدلًا من أن يكتبها المستخدم.

تنصح المذكرة نفسها بعدم اعتبار وضع القراءة فقط حمايةً عندما يكون المستودع غير موثوق، وهو الاستنتاج الذي يفرضه Heapjack على نفسه. وتذهب توصياتها البنيوية إلى أبعد من ذلك: عزل العمليات والذاكرة ماديًا بدلًا من الأسرار المشتركة والاصطلاحات، وإبقاء بيانات الاعتماد خارج متناول الوكيل، والتعامل مع الرقع التي تشير إلى مسارات خارج المشروع باعتبارها مشبوهة بمجرد رؤيتها. تلك مقترحات من طرف ثالث. وليس معلومًا علنًا ما إذا كانت OpenAI قد تبنّت أيًا منها بما يتجاوز ترقيتَي الإصدار.

ثمة أمران يجدر إبقاؤهما منفصلين في الختام. الأول زوج من العلل في وكيل برمجة واسع الاستخدام، أُبلِغ عنه في 12 أغسطس 2026، وأُصلح خلال ثمانية أيام، وأُغلق برقمَي إصدار. والآخر هو سؤال التصميم الذي يسمّيه يومتوف — أي是否可以 فرض بيئة عزل بالشيفرة التي يُفترض أنها تحتويها — وهذا سؤال لا يجيب عنه رقم إصدار. ولم تقل Accomplish ولا OpenAI إن تغييرات أغسطس قد حسمته.