ช่องโหว่ Gemini Live API: แค่ฟิลด์ที่หายไปตัวเดียว เปิดทางให้แฮกเกอร์ไฮแจ็กเซสชันเสียง AI

ในช่วงปลายเดือนมิถุนายนปี 2026 นักวิจัยความปลอดภัย Alvin Ferdiansyah ได้เปิดเผยรายละเอียดของสิ่งที่เขาระบุว่าเป็นข้อผิดพลาดในการตั้งค่าระบบโทเค็นชั่วคราว (ephemeral token) ของ Gemini Live API ของ Google ซึ่งเป็นช่องโหว่ร้ายแรง โดยช่องโหว่นี้ หากได้รับการยืนยัน จะทำให้ผู้โจมตีที่ได้รับโทเค็นเว็บซ็อกเก็ตอายุสั้นสามารถไฮแจ็กเซสชันเสียง AI บนเว็บเบราว์เซอร์ได้ โดยสามารถควบคุมโมเดลที่ใช้งาน, คำแนะนำระบบ (system prompt) และแม้แต่เครื่องมือที่เซสชันนั้นสามารถรันได้

หัวใจของช่องโหว่นี้คือการขาดฟิลด์รักษาความปลอดภัยในระหว่างการสร้างโทเค็น เรามาดูรายละเอียดที่ทราบ สิ่งที่ยังไม่ได้รับการยืนยัน และวิธีที่นักพัฒนาสามารถป้องกันการใช้งานของตนได้ในตอนนี้

ระบบโทเค็นชั่วคราวของ Gemini Live API ทำงานอย่างไร

Gemini Live API รองรับการเชื่อมต่อ WebSocket แบบเบราว์เซอร์ไปยังเซิร์ฟเวอร์โดยใช้ โทเค็นชั่วคราว (ephemeral tokens) ซึ่งเป็นโทเค็นยืนยันตัวตนอายุสั้นที่หมดอายุอย่างรวดเร็วและสามารถจำกัดการใช้งานเฉพาะได้ โทเค็นเหล่านี้ถูกสร้างขึ้นโดยเซิร์ฟเวอร์แบ็กเอนด์และส่งต่อไปยังไคลเอนต์ ซึ่งจะใช้โทเค็นเหล่านี้เพื่อเชื่อมต่อไปยัง Gemini API โดยตรงโดยไม่ต้องเปิดเผยคีย์ API หลัก

เอกสารของ Google อธิบายว่าโทเค็นชั่วคราวถูกออกแบบมาสำหรับการใช้งานแบบไคลเอนต์ไปยังเซิร์ฟเวอร์ที่คำนึงถึงความปลอดภัย เพราะแม้จะถูกดึงออกมาจากเบราว์เซอร์ อายุที่สั้นของโทเค็นก็ช่วยจำกัดความเสียหายได้ ปลายทาง (endpoint) สำหรับการเชื่อมต่อแบบมีข้อจำกัดนี้คือ BidiGenerateContentConstrained ซึ่งรับโทเค็นชั่วคราวเป็นพารามิเตอร์ access_token ใน Query

ฟิลด์ live_connect_constraints ที่หายไป

ตามรายงานของ Ferdiansyah โค้ดอ้างอิงสำหรับการสร้างโทเค็น ได้ละเว้นฟิลด์ live_connect_constraints ฟิลด์นี้ควรจะมีออบเจ็กต์ bidi_generate_content_setup ที่ผูกโทเค็นเข้ากับโมเดล, คำแนะนำระบบ และชุดเครื่องมือเฉพาะ

เมื่อ live_connect_constraints ถูกปล่อยว่างหรือไม่มีอยู่ จะไม่มีข้อจำกัดใดๆ ถูกบังคับใช้ ผู้โจมตีที่ได้โทเค็นชั่วคราวมาสามารถส่ง เฟรมการตั้งค่าที่ควบคุมโดยไคลเอนต์ ซึ่งระบุโมเดล, พร้อมต์ระบบ และเครื่องมือใดก็ได้ที่พวกเขาเลือก เซิร์ฟเวอร์ซึ่งไม่มีค่าที่ผูกกับโทเค็นไว้ตรวจสอบ ก็จะยอมรับการกำหนดค่าของผู้โจมตี

ข้อควรระวังสำคัญ: แหล่งข้อมูลที่มีอยู่ไม่รวมถึงเอกสารอย่างเป็นทางการของ Google สำหรับ live_connect_constraints, CVE หรือประกาศด้านความปลอดภัยจาก Google ที่ยืนยันพฤติกรรมนี้ ข้อมูลอ้างอิงนี้มาจากโพสต์ Medium ของ Ferdiansyah และควรถือว่ายังไม่ได้รับการยืนยัน แต่มีแนวโน้มว่าจะเป็นจริง

ผลกระทบ: ผู้โจมตีสามารถทำอะไรได้บ้างกับโทเค็นที่ไร้ข้อจำกัด

หากช่องโหว่นี้มีจริง ผลกระทบจะรุนแรงสำหรับแอปพลิเคชันใดๆ ที่ใช้ Gemini Live API ในบริบทของเบราว์เซอร์:

• การรันโค้ดใน Sandbox ผ่านเครื่องมือ — ตัวอย่างของ Gemini Live API รวมถึงการรองรับการเพิ่มเครื่องมือที่กำหนดเองจากฝั่งไคลเอนต์ ผู้โจมตีที่สามารถแทรกคำจำกัดความของเครื่องมือที่เป็นอันตรายอาจรันโค้ดภายใน Sandbox ของแอปพลิเคชันได้
• การใช้ทรัพยากรคอมพิวเตอร์โดยมิชอบ — เซสชันที่ถูกไฮแจ็กจะใช้โควตาและค่าใช้จ่ายของแอปพลิเคชันเหยื่อ เนื่องจากโทเค็นชั่วคราวถูกออกแบบมาสำหรับการเชื่อมต่อครั้งเดียว ผู้โจมตียังสามารถขอโทเค็นใหม่ซ้ำๆ ผ่าน endpoint การสร้างของแบ็กเอนด์ ซึ่งอาจทำให้ค่าใช้จ่ายเพิ่มสูงขึ้นได้
• การดัดแปลงพร้อมต์ — การควบคุมเฟรมการตั้งค่าหมายถึงการควบคุมคำแนะนำระบบ ผู้โจมตีสามารถเปลี่ยนวัตถุประสงค์ของเซสชันเพื่อดึงข้อมูลที่ละเอียดอ่อน สร้างเนื้อหาที่เป็นอันตราย หรือแอบอ้างเป็นเอเจนต์ที่เชื่อถือได้
• การละเมิดเซสชันซ้ำๆ — การเชื่อมต่อ Live API มีขีดจำกัดที่ประมาณ 10 นาที ผู้โจมตีจะต้องเชื่อมต่อใหม่ แต่ด้วยการใช้โฟลว์โทเค็นไร้ข้อจำกัดเดียวกัน พวกเขาก็สามารถไฮแจ็กเซสชันซ้ำได้เรื่อยๆ

นักพัฒนาในฟอรัม Google AI ได้รายงานปัญหาเกี่ยวกับโทเค็นชั่วคราวที่ละเว้นคำแนะนำระบบและทำงานไม่ได้ตามที่คาดหวังกับ endpoint แบบมีข้อจำกัด ซึ่งบ่งชี้ว่าระบบนิเวศโดยรวมยังอยู่ในช่วงพัฒนา

วิธีแก้ไข: แค่เพิ่มฟิลด์เดียว

วิธีแก้ไขที่ Ferdiansyah อธิบายนั้นตรงไปตรงมา: เพิ่มฟิลด์

live_connect_constraints.bidi_generate_content_setup

1. model — โมเดล Gemini ที่แน่นอนที่ต้องการใช้ (เช่น models/gemini-2.5-flash-native-audio-latest)
2. system_instruction — พร้อมต์ระบบที่ต้องการ ซึ่งมีโครงสร้างเป็น parts ที่ประกอบด้วย text
3. tools — อาร์เรย์ว่าง [] หรือเฉพาะเครื่องมือที่ได้รับอนุญาตเท่านั้น เพื่อป้องกันการแทรกจากฝั่งไคลเอนต์

นี่คือโค้ด Python ตัวอย่างจากโพสต์ของ Ferdiansyah :

token = gemini_client.auth_tokens.create({
    "uses": 1,
    "expire_time": now + timedelta(seconds=60),
    "new_session_expire_time": now + timedelta(seconds=60),
    "live_connect_constraints": {
        "bidi_generate_content_setup": {
            "model": "models/gemini-2.5-flash-native-audio-latest",
            "system_instruction": {
                "parts": [{"text": "คุณคือผู้ช่วยฝ่ายบริการลูกค้า..."}]
            },
            "tools": []
        }
    }
})

หมายเหตุ: เนื่องจาก live_connect_constraints ยังไม่มีในเอกสารอ้างอิง API อย่างเป็นทางการของ Google ในแหล่งข้อมูลนี้ ตัวอย่างนี้จึงอ้างอิงจากคำอธิบายของ Ferdiansyah และควรทดสอบกับ API จริงก่อนนำไปใช้จริง

สิ่งที่ยังไม่ได้รับการยืนยัน

ประเด็นสำคัญต่อไปนี้ยังไม่ได้รับการยืนยันจากแหล่งข้อมูลที่มี:

• ไม่มีเอกสารอย่างเป็นทางการของ Google ที่ยืนยันการมีอยู่หรือโครงสร้างของ live_connect_constraints
• ไม่มี CVE หรือประกาศด้านความปลอดภัย ที่ได้รับการเผยแพร่
• ไม่มีการจำลองช่องโหว่โดยอิสระ ในแหล่งข้อมูลที่มี
• พฤติกรรมที่แน่นอนของ endpoint BidiGenerateContentConstrained เมื่อได้รับโทเค็นที่ไร้ข้อจำกัดนั้นยังไม่มีในเอกสารอ้างอิงอย่างเป็นทางการ

นักพัฒนาควรทำอย่างไรตอนนี้

จนกว่า Google จะเผยแพร่ประกาศอย่างเป็นทางการ วิธีที่ปลอดภัยที่สุดคือถือว่าช่องโหว่นี้มีโอกาสเกิดขึ้นจริงและใช้มาตรการป้องกันล่วงหน้า:

1. ตรวจสอบโค้ดสร้างโทเค็นชั่วคราวของคุณ — ตรวจสอบว่าแบ็กเอนด์ของคุณมีการเพิ่มฟิลด์ live_connect_constraints หรือฟิลด์ที่เทียบเท่าหรือไม่
2. ไม่เปิดเผยคีย์ API ดิบ — ใช้โทเค็นชั่วคราวสำหรับการเชื่อมต่อที่เปิดเผยต่อเบราว์เซอร์เสมอ
3. ตั้งค่าอายุโทเค็นให้สั้น — Google แนะนำให้ตั้ง newSessionExpireTime ประมาณ 60 วินาทีเพื่อจำกัดระยะเวลาที่โทเค็นจะถูกขโมยได้
4. ตรวจสอบเฟรมการตั้งค่าจากฝั่งเซิร์ฟเวอร์ — แม้ว่าไคลเอนต์จะส่งการกำหนดค่าของตัวเอง แบ็กเอนด์ของคุณควรบังคับใช้โมเดล พร้อมต์ และเครื่องมือที่ตั้งใจไว้
5. ติดตามสัญญาณการละเมิด — จับตาดูรูปแบบเซสชันที่ผิดปกติ โดยเฉพาะการเชื่อมต่อซ้ำจากโทเค็นเดียวกันหรือการเรียกใช้เครื่องมือที่ไม่คาดคิด

Gemini Live API เป็นเครื่องมือที่ทรงพลังสำหรับการสร้างประสบการณ์เสียงและวิดีโอแบบเรียลไทม์ แต่การขาดฟิลด์เดียวในขั้นตอนการสร้างโทเค็นไม่ควรเป็นจุดอ่อนที่ทำให้ความสามารถนั้นลดลง นักพัฒนาจึงต้องแน่ใจว่าการนำไปใช้ของตนนั้นสมบูรณ์

บทความนี้ตรวจสอบข้อเท็จจริงจากแหล่งข้อมูล 21 แหล่ง รวมถึงเอกสารอย่างเป็นทางการของ Google การสนทนาในฟอรัมชุมชน และโพสต์ต้นฉบับของนักวิจัย ข้อกล่าวหาสำคัญจากนักวิจัยยังไม่สามารถยืนยันได้โดยอิสระจากแหล่งข้อมูลอย่างเป็นทางการในขณะที่ตีพิมพ์