<div class="key-takeaways"><ul><li>AI Agent ที่มีสิทธิ์กว้างขวางเสี่ยงตัดสินใจผิดพลาดและสร้างความเสียหาย</li><li>ความปลอดภัยแบบเดิมผูกติดกับโค้ด แต่ AI Agent ผูกติดกับการตัดสินใจที่ไม่แน่นอน</li><li>แนวทางแก้คือเลิกใช้กุญแจถาวร จำกัดสิทธิ์รายเครื่องมือ และจำกัดอายุโทเค็น</li><li>ต้องมีมนุษย์กดยืนยันเสมอสำหรับคำสั่งที่ไม่สามารถกู้คืนได้</li></ul></div><p>ในปัจจุบัน AI Agent มักถือ API Key ถาวรที่มีสิทธิ์เข้าถึงระบบสูงกว่าพนักงานฝึกงาน โดยสามารถอ่านที่เก็บโค้ด ส่งอีเมล เรียก API เสียเงิน หรือแม้กระทั่งพุชโค้ดได้ด้วยตนเอง การทำงานเหล่านี้เกิดขึ้นจากการคาดเดาของโมเดลว่าผู้ใช้ต้องการอะไร แทนที่จะเป็นการคลิกยืนยันด้วยมือมนุษย์</p><p>แม้เวิร์กโฟลว์แบบ AI จะกลายเป็นเครื่องมือประจำวัน แต่โมเดลความปลอดภัยยังล้าหลัง โดยทั่วไปมักใช้วิธีคัดลอกกุญแจอายุยาวลงในตัวแปรสภาพแวดล้อม ให้สิทธิ์ AI กว้างๆ และภาวนาให้พรอมต์ดีพอ ซึ่งมักใช้ได้ผลจนกระทั่งเกิดความผิดพลาดขึ้นมา</p><p>ซอฟต์แวร์แบบดั้งเดิมมีความแน่นอนเพราะมนุษย์เป็นคนเขียนโค้ดและรู้ว่าเส้นทางไหนเรียกใช้งานอะไร แต่วิธีคิดนี้ใช้กับ AI ไม่ได้อีกต่อไป เพราะเรากำลังให้สิทธิ์อำนาจในการตัดสินใจ แทนที่จะเป็นชุดคำสั่งที่ตายตัว AI จะอ่านพรอมต์ ตีความ และหยิบเครื่องมือมาใช้เพื่อให้บรรลุเป้าหมาย ซึ่งบางครั้งการตีความก็กว้างเกินไปจนเกิดความเสียหาย เช่น บิล API 400 ดอลลาร์ หรือฐานข้อมูลถูกลบ</p><p>ตัวอย่างเช่น เมื่อสั่งให้ AI "ลบข้อมูลทดสอบเก่าก่อนเดโม" โดยที่ระบบมีสิทธิ์เข้าถึงฐานข้อมูลครบถ้วน AI อาจตีความคำว่าเก่ากว้างเกินไปและลบข้อมูลจริง ทำให้ต้องกู้คืนระบบก่อนเวลาเดโมเพียงหนึ่งชั่วโมง ระบบไม่ได้เขียนโค้ดผิดพลาดและไม่มีใครอนุมัติการลบนั้นโดยเฉพาะ แต่มันทำตามขอบเขตสิทธิ์ที่ได้รับ</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/ai_agent_mu6ukjwf_inline_1_91619362d9.jpg" alt="cybersecurity data network visualization screen" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div><div class="ai-insight"><p>การเปลี่ยนผ่านจากซอฟต์แวร์ดั้งเดิมสู่ AI Agent ถือเป็นจุดเปลี่ยนสำคัญด้านความปลอดภัย สิทธิ์ในซอฟต์แวร์ปกติจะผูกติดกับตรรกะที่แน่นอน แต่สิทธิ์ของ AI ผูกติดกับวิจารณญาณ ซึ่งไม่มีทางให้ผลลัพธ์เดิมซ้ำๆ การออกแบบระบบความปลอดภัยจึงต้องปรับตามพฤติกรรมการตัดสินใจที่ไม่สามารถคาดเดาได้เหล่านี้</p></div><p>แนวทางแก้ไขไม่ใช่การตัดสิทธิ์ AI จนทำงานไม่ได้ แต่เป็นการจำกัดความเสียหายให้น้อยที่สุดเมื่อ AI ตัดสินใจผิดพลาด โดยมีแนวทางปฏิบัติที่สำคัญดังนี้:</p><ul><li>เลิกแจกจ่ายกุญแจถาวรที่ตั้งค่าทิ้งไว้ในตัวแปรสภาพแวดล้อมโดยไม่มีการตรวจสอบ</li><li>จำกัดขอบเขตสิทธิ์ตามเครื่องมือแต่ละตัว เช่น AI ที่อ่านประวัติคำสั่งซื้อไม่จำเป็นต้องมีสิทธิ์เขียนทับทั้งสคีมา</li><li>กำหนดให้มนุษย์ต้องกดยืนยันทุกครั้งสำหรับงานที่ไม่สามารถย้อนกลับได้ เช่น การลบข้อมูล การทำธุรกรรมทางการเงิน หรือการส่งอีเมลจริง</li><li>บันทึกการเรียกใช้เครื่องมือทุกครั้งเพื่อให้มีเส้นทางการตรวจสอบ (Audit Trail) ที่ชัดเจนเมื่อเกิดข้อผิดพลาด</li></ul><p>จากตัวอย่างโค้ดเปรียบเทียบ การตั้งค่าแบบเดิมจะใส่กุญแจมาสเตอร์ที่มีสิทธิ์อ่านเขียนฐานข้อมูล ส่งอีเมล และชำระเงินค้างไว้ตลอดกาล ในขณะที่แนวทางที่ปลอดภัยกว่าคือการออกโทเค็นชั่วคราวที่มีอายุจำกัดเพียง 15 นาที และจำกัดสิทธิ์เฉพาะตารางที่ต้องใช้งานเท่านั้น พร้อมบังคับให้ต้องขออนุมัติก่อนส่งอีเมลและตัดเครื่องมือชำระเงินออกไปหากไม่จำเป็น</p><p class="source-attribution">ที่มา: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/mikachu/your-ai-agent-has-too-many-permissions-a-practical-guide-to-not-getting-burned-2nin" target="blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>AI agents with broad permissions risk making flawed decisions and causing serious damage.</li><li>Traditional security binds code, but AI agents bind unpredictable judgment.</li><li>Solutions include dropping standing keys, scoping per tool, and setting short token lifespans.</li><li>Human-in-the-loop approvals are mandatory for any irreversible actions.</li></ul></div><p>Somewhere right now, an AI agent holds a standing API key with more access than an untrusted intern. It can read repositories, send emails, hit paid APIs, and push code based entirely on a model's best guess of your intent, rather than a human clicking confirm.</p><p>As agentic workflows move from novelty to daily tools, security models have lagged behind. The common practice involves copying a long-lived key into an environment variable, granting broad tool access, and hoping the prompt keeps the agent in line until something fails.</p><p>Traditional applications offer predictable logic because engineers write the exact code paths. AI agents break this assumption by authorizing decision-makers instead of fixed actions. The agent interprets prompts and grabs available tools, leading to unintended consequences like deleted repositories or surprise API bills.</p><p>For instance, asking an agent to clean up old test data before a demo with full database access might lead it to interpret the word old too aggressively, wiping production data an hour before showtime. No one wrote a bug or approved the deletion; the system simply chained together unverified decisions.</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/ai_agent_mu6ukjwf_inline_1_91619362d9.jpg" alt="cybersecurity data network visualization screen" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div><div class="ai-insight"><p>The shift from traditional software to AI agents represents a fundamental change in security dynamics. Software permissions bind deterministic code, whereas agent permissions bind subjective judgment, which never yields the exact same output twice. Security models must adapt to these unpredictable improvisational workflows.</p><p>The fix is not stripping all access, but shrinking the blast radius so failures remain small and reversible. Key mitigation steps include:</p></div><ul><li>Stop issuing static API keys sitting indefinitely in environment variables without monitoring.</li><li>Scope access per tool rather than granting blanket permissions across the entire schema.</li><li>Require human approval for all irreversible actions such as data deletions, financial transactions, and outbound customer emails.</li><li>Log every tool call thoroughly to maintain an audit trail for debugging black-box behavior.</li></ul><p>Comparing initial setups reveals the danger of permanent master keys with unlimited scope versus secure configurations using time-boxed tokens scoped strictly to single tables, lasting only fifteen minutes, and requiring explicit approval for sensitive actions.</p><p class="source-attribution">Source: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/mikachu/your-ai-agent-has-too-many-permissions-a-practical-guide-to-not-getting-burned-2nin" target="blank" rel="noopener noreferrer">Dev.to</a></p>

medium_อันตรายจาก-ai-agent-ที่มีสิทธิ์มากเกินไปและแนวทางป้องกัน-mu6ukjwf.jpg

small_อันตรายจาก-ai-agent-ที่มีสิทธิ์มากเกินไปและแนวทางป้องกัน-mu6ukjwf.jpg

thumbnail_อันตรายจาก-ai-agent-ที่มีสิทธิ์มากเกินไปและแนวทางป้องกัน-mu6ukjwf.jpg

อันตรายจาก-ai-agent-ที่มีสิทธิ์มากเกินไปและแนวทางป้องกัน-mu6ukjwf.jpg

เตือนภัย AI Agent ใช้ API Key ถาวรและสิทธิ์กว้างเกินไป เสี่ยงทำข้อมูลหายหรือยอดเงินรั่วไหล พร้อมแนะวิธีจำกัดขอบเขตและใส่ระบบยืนยันตัวตน

Warning over AI agents using standing API keys and broad access that risk data loss and massive bills, plus scoping and approval guides.

อันตรายจาก AI Agent ที่มีสิทธิ์มากเกินไปและแนวทางป้องกัน

Your AI Agent Has Too Many Permissions and Risks

<div class="key-takeaways"><ul><li>งานวิจัยเดือนเมษายน 2026 ตรวจสอบ LLM API Router 428 ตัว พบ 9 ตัวฉีดโค้ดอันตราย</li><li>สถาปัตยกรรมตัวกลางตัดการเชื่อมต่อเข้ารหัส เปิดอ่านข้อมูลและคีย์ API ได้ทั้งหมด</li><li>พบตัวกลางใช้เทคนิคหลบเลี่ยง ปรับตัวยิงโค้ดอันตรายหลังผ่านไป 50 คำขอ</li><li>การป้องกันปัจจุบันยังมีข้อจำกัดเรื่องการยืนยันที่มา ต้องรอผู้ให้โมเดลลงลายเซ็นดิจิทัล</li></ul></div><p>เมื่อผู้พัฒนาใช้งาน AI Agent ผ่านเครื่องมือตัวกลางหรือ LLM API Router เพื่อความสะดวกและประหยัดค่าใช้จ่ายในการเข้าถึงโมเดลหลายค่าย สิ่งที่มักมองข้ามคือสถาปัตยกรรมของตัวกลางที่ตั้งค่าเป็นปลายทาง ทำให้การเชื่อมต่อถูกถอดรหัสและเปิดอ่านข้อมูลได้ในระดับแอปพลิเคชัน ไม่ว่าจะเป็นคำสั่งที่ผู้ใช้พิมพ์ คีย์ API หรือรายการเครื่องมือที่ AI ขอเรียกใช้โดยไม่ต้องอาศัยการดักฟังที่ซับซ้อน</p><p>งานวิจัยที่ตีพิมพ์ในเดือนเมษายน 2026 ซึ่งตรวจสอบตัวกลางจำนวน 428 ตัว แบ่งเป็นตัวที่ซื้อจากตลาดในจีนและ Shopify จำนวน 28 ตัว และตัวฟรีจากชุมชนสาธารณะ 400 ตัว พบว่ามีตัวกลางที่จ่ายเงิน 1 ตัว และตัวฟรี 8 ตัว กำลังฉีดโค้ดอันตรายเข้าไปในคำสั่งที่ส่งกลับมา โดยในบางกรณีมีการเปลี่ยนชื่อแพ็กเกจ เช่น จาก requests เป็น reqeusts เพื่อให้ผ่านด่านตรวจชื่อโดเมนเดิมที่เชื่อถือได้แต่ติดตั้งแพ็กเกจปลอมของผู้โจมตีแทน</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/llm_api_router_9_428_agent_mty9zuwv_inline_1_e1e3e70765.jpg" alt="server room data center office meeting no logo" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div><div class="stat-row"><div class="stat-item"><span class="stat-number">428</span><span class="stat-label">จำนวนตัวกลางที่ถูกตรวจสอบ</span></div><div class="stat-item"><span class="stat-number">9</span><span class="stat-label">ตัวกลางที่ฉีดโค้ดอันตราย</span></div><div class="stat-item"><span class="stat-number">100M</span><span class="stat-label">โทเคนที่ถูกสร้างจากคีย์รั่ว</span></div></div><p>นอกจากนี้ยังมีตัวกลางที่ใช้เทคนิคหลบแบบปรับตัว โดยจะเริ่มยิงโค้ดอันตรายเฉพาะหลังจากผ่านไป 50 คำขอ หรือทำงานเฉพาะในเซสชันที่ตั้งค่าให้ทำทุกอย่างอัตโนมัติโดยไม่ต้องยืนยัน ทำให้การทดสอบระยะสั้นไม่พบความผิดปกติ นอกจากนี้ยังพบตัวกลาง 17 ตัวที่เข้าถึงข้อมูลรับรองทดสอบ และ 1 ตัวที่ดูดเงินออกจากกุญแจส่วนตัวคริปโต</p><blockquote class="pull-quote"><p>"ด่านนี้จะยืนได้ก็ต่อเมื่อมันอยู่ในตัวรันของ agent ไม่ใช่ในตัวกลาง"</p><cite>@bygregorr</cite></blockquote><div class="ai-insight"><p>การที่ LLM API Router สามารถอ่านและแก้ไขข้อมูลได้ทั้งหมดเกิดจากความไว้วางใจในสถาปัตยกรรมแบบรวมศูนย์ การป้องกันปัญหานี้จึงไม่ใช่แค่การตรวจจับเนื้อหา แต่เป็นการสร้างกลไกยืนยันที่มาที่ชัดเจน เช่น การที่ผู้ให้โมเดลลงลายเซ็นดิจิทัลกำกับคำตอบ เพื่อให้ฝั่งลูกค้าตรวจสอบได้ว่าคำสั่งไม่ได้ถูกแก้ไขระหว่างทาง</p></div><p>งานวิจัยยังได้ทดลองด่านฝั่งลูกค้า 3 แบบ ได้แก่ ด่านตรวจคำสั่งที่มีความเสี่ยงสูงซึ่งบล็อกได้ทั้งหมดที่อัตราเตือนผิด 1.0 เปอร์เซ็นต์, การคัดกรองความผิดปกติฝั่งคำตอบที่ตรวจจับได้ 89.0 เปอร์เซ็นต์แต่อัตราเตือนผิด 6.7 เปอร์เซ็นต์ และบันทึกตรวจสอบแบบเขียนต่อท้ายขนาด 1.26 ไบต์ต่อรายการที่ไม่ป้องกันแต่มีประโยชน์ในการสืบสวนย้อนหลัง</p><p class="source-attribution">ที่มา: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/sarantoon/9-cchaak-428-router-chiidokhdais-agent-thamaimdaanpngkanyangaimph-3cop" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>An April 2026 study examined 428 LLM API routers and found 9 injecting malicious code.</li><li>Proxy architecture terminates encrypted connections, exposing all prompts and API keys.</li><li>Some proxies use adaptive evasion, triggering malicious payloads after 50 requests.</li><li>Current defense mechanisms lack origin verification, requiring model providers to sign responses.</li></ul></div><p>When developers route AI agent traffic through third-party intermediaries or LLM API routers for convenience and cost-efficiency, they often overlook a critical architectural flaw. Because clients intentionally configure the proxy as an endpoint, the intermediary terminates the encrypted connection and reads all plain-text data passing through, including user prompts, API keys, and tool execution requests without needing complex interception techniques.</p><p>An April 2026 research study analyzed 428 routers, comprising 28 paid services purchased from Chinese markets and Shopify shops, alongside 400 free routers from public communities. The findings revealed that one paid router and eight free routers actively injected malicious code into tool instructions. In one instance, package names were altered from requests to reqeusts, bypassing domain name checks while executing malicious packages stored on the local machine.</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/llm_api_router_9_428_agent_mty9zuwv_inline_1_e1e3e70765.jpg" alt="server room data center office meeting no logo" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div><div class="stat-row"><div class="stat-item"><span class="stat-number">428</span><span class="stat-label">Routers inspected in study</span></div><div class="stat-item"><span class="stat-number">9</span><span class="stat-label">Routers injecting malicious code</span></div><div class="stat-item"><span class="stat-number">100M</span><span class="stat-label">Tokens generated from leaked keys</span></div></div><p>Furthermore, researchers discovered that two routers employed adaptive evasion techniques, deploying malicious code only after 50 requests or within sessions configured for fully autonomous execution without confirmation. This makes short-term testing appear normal. Additionally, 17 routers touched test credentials, and one drained funds from a honeypot cryptocurrency private key.</p><blockquote class="pull-quote"><p>"ด่านนี้จะยืนได้ก็ต่อเมื่อมันอยู่ในตัวรันของ agent ไม่ใช่ในตัวกลาง"</p><cite>@bygregorr</cite></blockquote><div class="ai-insight"><p>The vulnerability stems from inherent trust in centralized routing architectures. Securing this pipeline requires moving beyond simple content inspection toward cryptographic origin verification, such as model providers applying digital signatures to responses so clients can verify instructions haven't been tampered with in transit.</p></div><p>The study tested three client-side defense mechanisms: a high-risk command filter blocking direct injections with a 1.0 percent false-alarm rate, an anomaly detection filter catching 89.0 percent of direct injections with a 6.7 percent false-alarm rate, and an append-only audit log consuming 1.26 kilobytes per entry for post-incident investigations.</p><p class="source-attribution">Source: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/sarantoon/9-cchaak-428-router-chiidokhdais-agent-thamaimdaanpngkanyangaimph-3cop" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

medium_llm-api-router-9-จาก-428-ตัวกลางแอบฉีดโค้ดใส่-agent-mty9zuwv.jpg

small_llm-api-router-9-จาก-428-ตัวกลางแอบฉีดโค้ดใส่-agent-mty9zuwv.jpg

thumbnail_llm-api-router-9-จาก-428-ตัวกลางแอบฉีดโค้ดใส่-agent-mty9zuwv.jpg

llm-api-router-9-จาก-428-ตัวกลางแอบฉีดโค้ดใส่-agent-mty9zuwv.jpg

งานวิจัยเดือนเมษายน 2026 เผย LLM API Router หลายแห่งแอบเปลี่ยนคำสั่งและขโมยข้อมูล พร้อมแนะทางแก้ที่ต้องรอให้ผู้ให้โมเดลลงลายเซ็นดิจิทัล

An April 2026 study reveals LLM API routers injecting malicious payloads and stealing credentials, highlighting the need for digital signatures.

LLM API Router: 9 จาก 428 ตัวกลางแอบฉีดโค้ดใส่ Agent

LLM API Router: 9 of 428 Proxies Inject Code into Agents

<div class="key-takeaways"><ul><li>ฟีเจอร์ Deep Analysis บนเว็บไซต์ APEX Versus เกิดข้อผิดพลาดร้ายแรงสองจุดพร้อมกัน</li><li>ฝั่งเซิร์ฟเวอร์ไม่ได้ตรวจสอบการจ่ายเงิน ทำให้ผู้ใช้ทั่วไปเรียก API ได้ฟรีไม่มีอั้น</li><li>ลูกค้าแพ็กเกจ Pro ที่เสียเงินจริงกลับมองไม่เห็นปุ่มใช้งานเนื่องจากโค้ด UI ถูกซ่อนไว้</li><li>นักพัฒนาต้องแก้ไขระบบตรวจสอบสิทธิ์ฝั่งเซิร์ฟเวอร์และปรับปรุงการหักเครดิตให้ทำงานจริง</li></ul></div><p> Param Jaisinghani ผู้พัฒนาเว็บไซต์เปรียบเทียบ AI อย่าง "APEX Versus" ได้ออกมาบอกเล่าประสบการณ์สุดช็อกหลังตรวจโค้ดครั้งใหญ่ เมื่อพบว่าฟีเจอร์วิเคราะห์เชิงลึกที่เรียกว่า "Deep Analysis" และ "Advanced Analysis" ซึ่งเป็นบริการแบบเสียเงิน กลับมีข้อผิดพลาดซ่อนอยู่ถึงสองจุดในเวลาเดียวกัน และความผิดพลาดทั้งสองฝั่งดันหักล้างกันเองจนระบบดูเหมือนปกติในตอนแรก</p><p> ปัญหาแรกคือระบบกำแพง paywall ไม่มีอยู่จริงบนฝั่งเซิร์ฟเวอร์ โดยหน้าเว็บไซต์ฝั่ง frontend มีการตรวจสอบเครดิตก่อนเรียกใช้งาน API ก็จริง แต่ตัว API หลักอย่าง <code>POST /api/compare</code> กลับไม่มีการตรวจสอบอะไรเลย ใครก็ตามที่ส่งคำขอพร้อมโหมด advanced ไปยังเซิร์ฟเวอร์โดยไม่ต้องมี auth header จะสามารถใช้งานโมเดล Gemini และรับผลลัพธ์กลับมาได้ทันที โดยไม่ต้องเข้าสู่ระบบ ไม่ต้องมีเครดิต และไม่มีการจำกัดโควต้าประจำวัน</p><p> ปัญหาที่สองกลับตรงกันข้ามอย่างสิ้นเชิง เพราะฟีเจอร์นี้ดันถูกซ่อนจากผู้ใช้งานที่ยอมควักกระเป๋าจ่ายเงินจริง โดยโค้ดแสดงผลระบุเงื่อนไขซ่อนการ์ดฟีเจอร์ดังกล่าวเมื่อผู้ใช้อยู่ในแพ็กเกจที่ต้องจ่ายเงิน ทำให้ปุ่ม "Advanced Analysis" ของสมาชิก Pro กลายเป็นโค้ดตายที่ไม่มีฟังก์ชันไหนเรียกใช้งานเลยตั้งแต่วันแรกที่เขียนขึ้นมา</p><div class="ai-insight"><p>เหตุการณ์นี้นับเป็นกรณีศึกษาชั้นดีในหมู่นักพัฒนาซอฟต์แวร์เกี่ยวกับความปลอดภัยของระบบ API และ Paywall โดยทั่วไป หากนักพัฒนาพึ่งพาการตรวจสอบสิทธิ์เพียงแค่ฝั่งไคลเอนต์ (Client-side) เช่น การซ่อนปุ่มหรือเช็กสถานะบนหน้าจอ ระบบจะมีความเปราะบางสูงมาก เพราะแฮกเกอร์หรือผู้ใช้ทั่วไปสามารถข้ามหน้า UI ไปยิง API ตรงๆ ได้เสมอ การตรวจสอบที่แท้จริงจึงต้องเกิดขึ้นที่ฝั่งเซิร์ฟเวอร์ (Server-side) เท่านั้น</p></div><p> สาเหตุรากเหง้าของเรื่องนี้มาจากการที่ผู้พัฒนาได้อัปเดตกฎความปลอดภัยของ Firestore ให้เครดิตสามารถถูกเขียนได้เฉพาะฝั่งเซิร์ฟเวอร์ผ่าน admin SDK เพื่อป้องกันการแฮกเครดิต แต่ลืมอัปเดตโค้ดเก่าที่พยายามเขียนเครดิตจากเบราว์เซอร์ ทำให้โค้ดพยายามทำงานอยู่เรื่อยๆ แต่ล้มเหลวแบบเงียบๆ ทุกครั้ง ส่งผลให้ระบบล่มแบบไม่แสดง Error ออกมาให้เห็น</p><p> <div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/ai_apex_versus_mtmuhl1p_inline_1_63b184d408.jpg" alt="software code editor screen programming dark mode" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div></p><p> หลังจากค้นพบสาเหตุ การแก้ไขจึงทำได้โดยการเขียนโค้ดตรวจสอบสิทธิ์และระบบตัดเครดิตใหม่บนเซิร์ฟเวอร์ จากนั้นทดสอบจริงด้วยบัญชี Pro พบว่ายอดเครดิตลดลงไป 2 แต้มทันทีแบบอัตโนมัติ ซึ่งถือเป็นครั้งแรกในประวัติศาสตร์ของฟีเจอร์นี้ที่การหักเครดิตเกิดขึ้นจริงหลังใช้งาน</p><blockquote class="pull-quote"><p>"การตรวจสอบฝั่งไคลเอนต์และฝั่งเซิร์ฟเวอร์ไม่ใช่ฟีเจอร์เดียวกัน เพียงเพราะมันมองหาตัวแปรตัวเดียวกัน อันหนึ่งเป็นแค่คำแนะนำ แต่อีกอันคือสิ่งเดียวที่ใช้งานได้จริง"</p><cite>Param Jaisinghani</cite></blockquote><p> สุดท้ายนี้ ผู้พัฒนาได้ฝากข้อคิดเตือนใจสำหรับใครก็ตามที่กำลังทำระบบเครดิตหรือ Paywall ว่าควรตรวจสอบโค้ดทุกจุดที่มีการเช็กยอดคงเหลือ และลองจินตนาการดูว่าระบบนั้นจะรอดพ้นหรือไม่หากมีคนจงใจข้ามหน้าเว็บไปยิง API ตรงๆ หากคำตอบต้องขึ้นต้นด้วยคำว่า "ควรจะ" แปลว่าระบบนั้นยังไม่ได้ถูกบังคับใช้อย่างแท้จริง</p><p class="source-attribution">ที่มา: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/param_jaisinghani_b7c9705/my-paid-ai-feature-was-simultaneously-free-for-anyone-to-abuse-and-broken-for-the-people-actually-53e2" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>APEX Versus AI comparison site suffered from two simultaneous bugs in its Deep Analysis feature.</li><li>Server-side validation was missing, allowing anyone to call the advanced API for free without limits.</li><li>Pro paying users could not see the feature button due to a hidden UI bug in the frontend code.</li><li>The developer fixed the issue by enforcing server-side credit deduction and proper authorization.</li></ul></div><p> Param Jaisinghani, the developer behind the AI comparison platform "APEX Versus," shared a sobering post-mortem after running a comprehensive debug pass on his codebase. He discovered that a newly shipped feature had two distinct bugs running simultaneously, and their failure modes ironically masked each other.</p><p> The first issue was a completely absent server-side paywall. While the frontend checked user credits before triggering any API calls, the actual API endpoint <code>POST /api/compare</code> performed zero validation. Anyone sending a request with mode set to "advanced" and omitting authentication headers could successfully invoke a Gemini model call and receive full content without logging in, spending credits, or hitting daily limits.</p><p> The second bug was the exact opposite: the feature was entirely invisible to customers who actually paid for it. Due to a conditional rendering error in the frontend code, the card containing Deep Analysis was hidden whenever a user was on a paid plan, rendering the "Advanced Analysis" button completely dead code since day one.</p><div class="ai-insight"><p>This incident highlights a classic architectural pitfall in web development regarding authorization and paywalls. Relying solely on client-side checks—such as hiding buttons or checking local states—provides zero real security because users can easily bypass the UI and hit backend APIs directly. Robust enforcement must always happen at the server level, treating the client interface merely as a convenience rather than a security boundary.</p></div><p> The root cause stemmed from a past update to Firestore security rules meant to prevent client-side credit exploits by restricting writes to the admin SDK. The legacy browser-side credit-writing code was left intact, resulting in silent failures every time a user attempted an action, leaving errors entirely concealed behind empty catches.</p><p> <div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/ai_apex_versus_mtmuhl1p_inline_1_63b184d408.jpg" alt="software code editor screen programming dark mode" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div></p><p> Once the bug was diagnosed, the fix involved rebuilding proper backend authorization and credit checks. Testing on a live paid account finally confirmed atomic credit deductions, dropping the balance by exactly two credits for the first time in the feature's operational history.</p><blockquote class="pull-quote"><p>"A client-side check and a server-side check are not the same feature just because they look at the same variable. One is a suggestion. The other is the only one that counts."</p><cite>Param Jaisinghani</cite></blockquote><p> The developer concluded with advice for anyone managing credit or paywall systems: audit the codebase to see if balance checks would survive someone bypassing the user interface entirely. If the answer relies on the word "should," the rule is not actually enforced.</p><p class="source-attribution">Source: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/param_jaisinghani_b7c9705/my-paid-ai-feature-was-simultaneously-free-for-anyone-to-abuse-and-broken-for-the-people-actually-53e2" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

medium_บั๊กคู่แฝดพังระบบจ่ายเงิน-ai-บน-apex-versus-mtmuhl1p.jpg

small_บั๊กคู่แฝดพังระบบจ่ายเงิน-ai-บน-apex-versus-mtmuhl1p.jpg

thumbnail_บั๊กคู่แฝดพังระบบจ่ายเงิน-ai-บน-apex-versus-mtmuhl1p.jpg

บั๊กคู่แฝดพังระบบจ่ายเงิน-ai-บน-apex-versus-mtmuhl1p.jpg

ผู้พัฒนา APEX Versus เผยฟีเจอร์วิเคราะห์ AI พังสองเด้ง ผู้ใช้ฟรีเรียกใช้ได้ฟรีโดยไม่ต้องจ่ายเงิน ขณะที่ลูกค้า Pro กลับมองไม่เห็นปุ่มใช้งาน

APEX Versus developer reveals a critical payment flaw where unpaid users bypassed paywalls while paying Pro users couldn't access the feature.

บั๊กคู่แฝดพังระบบจ่ายเงิน AI บน APEX Versus

Double Bug Left Paid AI Feature Free and Broken

<div class="key-takeaways"><ul><li>การบล็อกคำสั่งอันตราย เช่น git push ได้ผลเพราะอันตรายอยู่ที่ตัวคำสั่ง</li><li>คำสั่งเรียก API ด้านการเงินมีความเสี่ยงขึ้นอยู่กับสถานะบัญชีฝั่งปลายทาง</li><li>การสร้างระบบตรวจเช็กยอดเงินใน Agent Host กลายเป็นการจำลองระบบอนุมัติซ้ำซ้อน</li><li>การบังคับใช้ความปลอดภัยที่แท้จริงต้องทำบน Server-side ฝั่งที่มีข้อมูลครบถ้วน</li></ul></div><p>การเขียนโปรแกรมควบคุมพฤติกรรมของ AI Agent หรือที่เรียกว่า Guardrails กำลังได้รับความสนใจอย่างมากในช่วงนี้ โดยมีตัวอย่างคลาสสิกอย่างการที่ Agent พยายามจะสั่ง force-push ไปยัง Branch หลัก ซึ่งเหตุผลเบื้องหลังการกระทำนั้นสมเหตุสมผลในแง่เทคนิคเพื่อแก้ปัญหา Rebase ที่ติดขัด แต่มีความเสี่ยงสูงในแง่ผลกระทบที่ไม่ท้องถิ่น</p><p>ความน่าสนใจของตัวอย่างนี้คือคำสั่งดังกล่าวพกพาความเสี่ยงติดตัวมาด้วย นักพัฒนาสามารถจับคู่อินสแตนซ์ของแพตเทิร์นและขึ้นบัญชีดำไว้ได้ เนื่องจากคำสั่งอย่าง git push --force origin main มีอันตรายอยู่ในตัวมันเองแทบทุกบริบท ทำให้กฎเกณฑ์การบล็อกสามารถทำงานได้อย่างมีประสิทธิภาพโดยอาศัยการอ่านสตริงของคำสั่งเท่านั้น</p><p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/guardrails_ai_agent_mt2uazwk_inline_1_8554ac8626.jpg" alt="computer terminal command line screen" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div></p><p>อย่างไรก็ตาม ปัญหาการทำธุรกรรมทางการเงินไม่ได้ทำงานในลักษณะนั้น จำนวนเงิน 40,000 อาจเป็นการคืนเงินที่ถูกต้องตามใบแจ้งหนี้ที่สมบูรณ์ หรืออาจเป็นยอดคืนเงินซ้ำซ้อนจากรายการที่เพิ่งคืนเงินไปเมื่อชั่วโมงก่อน ซึ่งอย่างหลังคือความหายนะที่แท้จริง คุณไม่สามารถแยกแยะความแตกต่างเหล่านี้ได้เพียงแค่การมองดูที่ตัวคำสั่ง เพราะสิ่งที่ทำให้มันกลายเป็นความผิดพลาดไม่ได้ซ่อนอยู่ในการเรียกใช้งาน API นั้น</p><div class="ai-insight"><p>ในมุมมองด้านสถาปัตยกรรมซอฟต์แวร์ ปัญหาความปลอดภัยของ AI Agent สะท้อนให้เห็นว่าระบบอัตโนมัติไม่สามารถตัดสินใจเรื่องความเสี่ยงทางการเงินด้วยข้อมูลที่จำกัดได้ การพยายามสร้างระบบกรองคำสั่งฝั่งไคลเอนต์จึงเป็นเพียงการแก้ปัญหาที่ปลายเหตุและอาจสร้างความซับซ้อนให้ระบบมากขึ้นโดยไม่จำเป็น</p></div><p>ทางออกที่หลายคนมักนึกถึงคือการให้ Guard ของ Agent เรียก API ไปดึงข้อมูลการชำระเงิน ตรวจสอบยอดคงเหลือ แล้วค่อยตัดสินใจดำเนินการ แต่เมื่อลงมือสร้างจริง นักพัฒนาจะพบกับปัญหาใหญ่หลายประการ:</p><ul><li>ระบบ Hook ต้องถือสิทธิ์เข้าถึงบัญชีแยกประเภท (Ledger) เพื่อปกป้องคุณจากตัวโฮสต์ของ Agent เอง</li><li>กฎเกณฑ์การคืนเงินและการระงับข้อพิพาทต้องถูกเขียนซ้ำในสอง codebase ที่ต้องซิงก์กันตลอดเวลา</li><li>ช่องว่างของเวลาระหว่างการตรวจสอบและการสั่งงานจริง ซึ่งยอดเงินอาจเปลี่ยนแปลงไปแล้วในจังหวะเวลานั้น</li></ul><p>ท้ายที่สุด การสร้างระบบลักษณะนี้ไม่ได้เรียกว่า Guardrail แต่เป็นการสร้างบริการอนุมัติชุดที่สองที่แย่กว่าเดิม รันอยู่บนกระบวนการที่เชื่อถือได้น้อยที่สุด และพึ่งพาแคชในการทำงาน</p><p>แนวทางที่รอดพ้นจากปัญหาเหล่านี้คือการนำระบบตรวจสอบไปไว้ที่จุดควบคุมหลัก (Rail) ณ จุดที่มีการอนุมัติจริง เพราะเป็นจุดเดียวที่รับรู้สถานะทั้งหมดว่าตัวละครนี้สามารถโยกย้ายเงินได้เท่าไร ย้ายไปแล้วเท่าไร และเป้าหมายในขณะนั้นมีหน้าตาเป็นอย่างไร การเชื่อมต่อ AI Agent เข้ากับระบบที่มีอยู่วิ่งผ่านขั้นตอนการตรวจสอบที่มีบันทึกการตรวจสอบ (Audit record) ครบถ้วน จึงเป็นแนวทางที่ปลอดภัยกว่าการสร้างระบบดักหน้าแล้วเรียกว่าความปลอดภัย</p><p class="source-attribution">ที่มา: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/mickyarun/your-agents-guardrails-cant-see-the-money-35f" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>Command-level guards like git push work because danger lives directly in the verb.</li><li>Amount-bearing API calls depend entirely on remote server state, not intent.</li><li>Building state-checking hooks in agent host creates a flawed, redundant service.</li><li>Real enforcement must happen server-side where complete audit records live.</li></ul></div><p>Discussions around AI agent guardrails frequently highlight scenarios where an agent attempts a force-push to main. The reasoning behind the action is often locally sound to resolve a stuck rebase, yet non-locally expensive if executed blindly without context.</p><p>What makes that command teachable is that the danger is embedded right inside the syntax. You can easily pattern-match git push --force origin main and place it on a blocklist because the risk profile remains consistent across nearly every context, allowing a simple string-matching hook to catch it.</p><p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/guardrails_ai_agent_mt2uazwk_inline_1_8554ac8626.jpg" alt="computer terminal command line screen" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div></p><p>However, the risks involving money operate entirely differently. Forty thousand dollars might represent a legitimate refund against a valid invoice, or it could duplicate a refund processed an hour earlier. You cannot differentiate between the two simply by inspecting the API call arguments, as the contextual state that defines the mistake is completely absent from the payload.</p><div class="ai-insight"><p>From a software architecture perspective, this architectural flaw demonstrates why automation frameworks cannot independently own financial safety. Relying on client-side prompt or command filtering for money-moving operations creates a false sense of security while ignoring critical server-side state variables.</p></div><p>A seemingly logical workaround is allowing the agent guard to call an external API, fetch payment data, check balances, and then make a decision. Implementing this approach, however, introduces severe engineering complexities:</p><ul><li>The hook requires credential access to ledger states, meaning the agent host holds read permissions to protect you from itself.</li><li>Refund rules and dispute semantics must be maintained across two separate codebases that must stay synchronized indefinitely.</li><li>A race condition window exists between the preflight check and the actual execution where account balances can shift.</li></ul><p>Ultimately, this approach constructs a secondary, less reliable authorization service running within an untrusted process rather than a genuine guardrail.</p><p class="source-attribution">Source: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/mickyarun/your-agents-guardrails-cant-see-the-money-35f" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

medium_article-3643.jpg

small_article-3643.jpg

thumbnail_article-3643.jpg

article-3643.jpg

เจาะลึกข้อจำกัดของ AI Agent Guardrails เมื่อต้องจัดการธุรกรรมการเงิน ทำไมการตรวจคำสั่งทางเทคนิคจึงใช้ไม่ได้กับยอดเงิน

Exploring the limitations of AI agent guardrails in financial transactions and why technical hooks fail to secure money movements.

ทำไม Guardrails ของ AI Agent ถึงคุมเรื่องเงินไม่ได้

Why Your Agent's Guardrails Can't See the Money

<div class="key-takeaways"><ul><li>Metabase ยืนยันพบการโจมตีจริงโดยแฮกเกอร์ช่องโหว่ SQL Injection</li><li>ระบบ Metabase Cloud ได้รับการแพทช์แล้ว แต่เซิร์ฟเวอร์โฮสต์เองต้องอัปเดตมือ</li><li>คนร้ายโจมตีผ่าน public password reset API เพื่อขโมยสิทธิ์แอดมิน</li></ul></div><p>ระบบวิเคราะห์ข้อมูลยอดนิยม Metabase ออกมายืนยันว่ากำลังเผชิญกับการโจมตีในโลกความเป็นจริง โดยมีรายงานจาก Framework และ Tally ระบุถึงการเข้าถึงระบบโดยไม่ได้รับอนุญาตและการรั่วไหลของข้อมูลตั้งแต่วันที่ 3 สิงหาคมเป็นต้นมา แม้ว่าผู้ใช้งานบนระบบ Metabase Cloud จะได้รับการแก้ไขช่องโหว่เรียบร้อยแล้ว แต่สำหรับองค์กรที่ติดตั้งใช้งานบนเซิร์ฟเวอร์ของตนเอง (Self-hosted) จำเป็นต้องเร่งดำเนินการอัปเดตด้วยตนเองทันที</p><p>รูปแบบการโจมตีนี้อาศัยช่องโหว่ที่แฮกเกอร์สามารถฉีดคำสั่ง SQL เข้ามาได้โดยไม่ต้องยืนยันตัวตน ผ่านทาง API สำหรับรีเซ็ตรหัสผ่านที่เป็นสาธารณะ เพื่อไต่ระดับสิทธิ์จนกลายเป็นผู้ดูแลระบบสูงสุดของ Metabase จากนั้นจึงทำการดึงข้อมูลและส่งออกข้อมูลรับรอง (Credentials) ของฐานข้อมูลที่เชื่อมต่ออยู่ รวมถึงข้อมูลภายในที่สามารถมองเห็นได้ทั้งหมด</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/metabase_sql_injection_msjumfiz_inline_1_1f6f5bec97.jpg" alt="database server network infrastructure" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div><p>ในมุมมองของผู้ใช้งานทั่วไป หน้าจอการทำงานจะยังคงแสดงผลเป็นหน้าจอวิเคราะห์ข้อมูลตามปกติและไม่ต้องดำเนินการใดๆ ในช่วงเวลาที่ถูกเจาะระบบ ส่วนในมุมมองของผู้ดูแลระบบ การโจมตีจะปรากฏในรูปแบบคำขอ HTTP 400 POST ไปยัง API รีเซ็ตรหัสผ่านซึ่งดูเหมือนจะล้มเหลว ตามมาด้วยคำขอ HTTP 200 ที่สำเร็จไปยังเส้นทาง /api/user/current ทันที นอกจากนี้ยังมีสัญญาณเตือนอื่นๆ เช่น การปรากฏตัวของแอดมินแปลกปลอมหรือคีย์ API ใหม่ การสืบค้นข้อมูลหรือการส่งออกที่ผิดปกติ รวมถึงการใช้งานฐานข้อมูลที่เชื่อมต่อในลักษณะผิดวิสัย</p><div class="ai-insight"><p>ช่องโหว่นี้มีความรุนแรงสูงมากเนื่องจากช่วยให้ผู้ไม่หวังดีสามารถข้ามผ่านด่านการพิสูจน์ตัวตนเข้ามาควบคุมระบบได้เบ็ดเสร็จ การที่แฮกเกอร์สามารถเข้าถึงฐานข้อมูลที่เชื่อมต่ออยู่ได้ไม่ได้หมายถึงแค่ข้อมูลใน Metabase เท่านั้น แต่ยังรวมถึงความเสี่ยงที่ฐานข้อมูลหลังบ้านจะถูกเจาะตรงหากข้อมูลรับรองรั่วไหล องค์กรจึงควรตรวจสอบการตั้งค่าเครือข่ายและการเข้าถึงอย่างเข้มงวด</p></div><p>ผลกระทบที่เกิดขึ้นทำให้สิทธิ์การเป็นแอดมิน การตั้งค่า คีย์ API และข้อมูลรับรองฐานข้อมูลของ Metabase ถูกบุกรุกทั้งหมด ผู้โจมตีสามารถรันคำสั่งค้นหาและส่งออกข้อมูลลูกค้าหรือข้อมูลธุรกิจที่เข้าถึงได้ผ่าน Metabase นอกจากนี้ หากพวกเขานำข้อมูลรับรองการเชื่อมต่อเหล่านั้นไปใช้ประโยชน์โดยตรง ก็สามารถเข้าถึงฐานข้อมูลจากภายนอกระบบ Metabase ได้อีกด้วย</p><p>ทาง Metabase ระบุชัดเจนว่าหากไฟล์บันทึกระบบ (Logs) มีรูปแบบการเรียกใช้งาน POST 400 ควบคู่กับ GET 200 ตามที่กล่าวมาข้างต้น มีความเป็นไปได้สูงมากที่ระบบจะถูกเจาะเรียบร้อยแล้ว</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/metabase_sql_injection_msjumfiz_inline_2_ae0e959a39.jpg" alt="hacker code computer screen security" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div><p>เนื่องจาก Metabase มักถูกติดตั้งใช้งานโดยแผนกต่างๆ หรือรันอยู่ในสภาพแวดล้อม Docker ขนาดเล็ก ทำให้เซิร์ฟเวอร์เหล่านี้มักรอดพ้นจากการตรวจสอบของทีมไอทีส่วนกลาง ทีมปฏิบัติการด้านความปลอดภัยจึงควรยกระดับการทำงานให้ก้าวมากกว่าการจัดการช่องโหวบทั่วไป โดยใช้เครื่องมือค้นหาทรัพย์สิน (Asset Discovery) เพื่อตรวจสอบว่ามีเซิร์ฟเวอร์ Metabase หรือจุดเชื่อมต่อใดที่เปิดexposed สู่สาธารณะหรือไม่ และหากพบร่องรอยการถูกเจาะ ขอบเขตการสืบสวนจะต้องขยายลึกไปถึงฐานข้อมูลที่เชื่อมต่ออยู่ พร้อมทั้งเตรียมรับมือกับกระบวนการจัดการการรั่วไหลของข้อมูลส่วนบุคคลหากมีข้อมูลของลูกค้าและพนักงานรวมอยู่ด้วย</p><p class="source-attribution">ที่มา: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/anoymask/metabase-unauthenticated-sql-injection-from-admin-privilege-heist-to-connected-db-data-theft-2akb" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>Metabase has confirmed active exploitation involving SQL injection vulnerabilities.</li><li>Metabase Cloud is already patched, but self-hosted environments require manual updates.</li><li>Threat actors inject SQL without authentication into public password reset APIs to steal admin rights.</li></ul></div><p>Data analytics platform Metabase has officially confirmed active exploitation in the wild, following reports from Framework and Tally regarding unauthorized access and data leakage starting August 3. While users on Metabase Cloud are already protected with patches, organizations running self-hosted environments must manually apply updates as soon as possible.</p><p>This ongoing attack allows threat actors to inject SQL statements without any authentication directly into the public password reset API. By doing so, they elevate their access to Metabase administrator privileges, allowing them to harvest and export connected database credentials alongside any viewable data within the platform.</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/metabase_sql_injection_msjumfiz_inline_1_1f6f5bec97.jpg" alt="database server network infrastructure" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div><p>For standard users, the service appears completely normal, displaying standard analytical interfaces with no required actions during a breach. For administrators, however, the attack manifests as an HTTP 400 POST request sent to the password reset API that seems to fail, immediately followed by a successful HTTP 200 response on /api/user/current. Additional indicators of compromise include unknown administrators or API keys, unusual database queries, and abnormal utilization of connected data sources.</p><div class="ai-insight"><p>This vulnerability is exceptionally critical because it bypasses standard authentication checks to grant full administrative control. Gaining access to database credentials inside Metabase doesn't just expose analytics data; it opens the door for direct backend database compromises if those credentials can be abused externally. Organizations must rigorously audit network exposure and permissions.</p></div><p>As a result of the compromise, Metabase administrator privileges, system settings, API keys, and connected database credentials are fully compromised. Attackers can query and export sensitive customer and business records visible inside Metabase. Furthermore, direct abuse of these database connection credentials allows unauthorized access to backend databases from outside the Metabase ecosystem entirely.</p><p>Metabase notes that if system logs contain the specific combination of a POST 400 request followed by a GET 200 request, a system compromise is extremely likely.</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/metabase_sql_injection_msjumfiz_inline_2_ae0e959a39.jpg" alt="hacker code computer screen security" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div><p>Because Metabase is frequently deployed independently by individual departments or run within small-scale Docker environments, public instances often remain hidden from central IT oversight. Security operations teams must push beyond basic vulnerability management by deploying asset discovery tools to verify whether any Metabase instances or target endpoints are publicly exposed. If indicators of compromise surface, the investigation scope must expand immediately to cover all connected databases, alongside preparing a parallel response for potential personal data breaches if consolidated customer or employee records are impacted.</p><p class="source-attribution">Source: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/anoymask/metabase-unauthenticated-sql-injection-from-admin-privilege-heist-to-connected-db-data-theft-2akb" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

medium_metabase-sql-injection-msjumfiz.jpg

small_metabase-sql-injection-msjumfiz.jpg

thumbnail_metabase-sql-injection-msjumfiz.jpg

metabase-sql-injection-msjumfiz.jpg

Metabase เผยกำลังถูกโจมตีช่องโหว่ Unauthenticated SQL Injection โดยแฮกเกอร์ใช้เจาะระบบผ่าน API รีเซ็ตรหัสผ่านเพื่อยึดสิทธิ์ผู้ดูแลระบบ

Metabase confirms active exploitation exploiting an unauthenticated SQL injection vulnerability via password reset APIs to hijack admin controls.

เจาะช่องโหว่ Metabase SQL Injection: ขโมยสิทธิ์แอดมินสู่ฐานข้อมูล

Metabase Unauthenticated SQL Injection: From Admin Privilege Heist to DB Theft

<div class="key-takeaways"><ul><li>ตรวจสอบลายเซ็นด้วย timingSafeEqual และเซ็นบน raw body เสมอ</li><li>เช็ก Timestamp เพื่อป้องกันการโจมตีแบบ Replay Attack</li><li>ออกแบบระบบให้เป็น Idempotent ป้องกันการทำงานซ้ำจาก Retry</li><li>ใช้ Precedence แทน Timestamp ในการจัดการข้อมูลที่มาผิดลำดับ</li></ul></div><p>การส่ง Webhook เป็นเรื่องง่าย แค่ทำ POST คำขอแบบ JSON ไปยัง URL แล้วก็จบ แต่ในทางกลับกัน ฝั่งผู้รับกลับเต็มไปด้วยความท้าทาย เนื่องจากปลายทางเป็น Public URL ที่ใครก็เรียกเข้ามาได้ แถมยังมีระบบ Retry ที่อาจทำให้คำขอถูกรันซ้ำสองรอบ ข้อมูลอาจมาถึงสลับลำดับกันจนสถานะdelivered มาถึงก่อนsent และยังอยู่บน Critical Path ของระบบอื่น หากฝั่งเราตอบสนองช้าจนหมดเวลา ผู้ส่งก็จะพยายามส่งซ้ำจนทำให้ระบบช้าลงไปอีก</p><p>ปัญหาเหล่านี้ไม่ใช่เรื่องยากหากคุณรู้ล่วงหน้า แต่ทั้งหมดนี้มักซ่อนตัวอยู่จนกระทั่งไปโผล่บน Production บทความนี้จึงรวบรวมสิ่งที่คุณต้องจัดการทั้งหมดเมื่อต้องสร้างตัวรับ Webhook โดยใช้ตัวอย่างเคสการส่งอีเมล (Bounces และ Complaints) ที่มีความยุ่งยากครบทุกรูปแบบ ทั้งเรื่องความปลอดภัย การส่งซ้ำ ลำดับที่ผิดเพี้ยน และการประมวลผลซ้ำที่จะทำลายข้อมูลจริง ซึ่งหลักการเหล่านี้สามารถนำไปใช้กับบริการอย่าง Stripe, GitHub หรือ Shopify ได้เช่นเดียวกัน</p><p>ด่านแรกคือความปลอดภัย เนื่องจาก Endpoint ของคุณเป็นสาธารณะ หากไม่มีการตรวจสอบ ผู้ไม่หวังดีอาจส่งเหตุการณ์ปลอม เช่น หลอกว่าอีเมลตีกลับเพื่อระงับบัญชีลูกค้า หรือหลอกว่าชำระเงินสำเร็จเพื่อเนียนใช้บริการฟรี ผู้ให้บริการจึงมักจะแนบ ลายเซ็น (Signature) มากับทุกคำขอด้วย Secret ร่วมกัน หน้าที่ของคุณคือคำนวณลายเซ็นใหม่แล้วนำมาเทียบกัน</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/webhook_production_ms3h9lo1_inline_1_7135cd8318.jpg" alt="network pipeline data flow" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div><p>ในจุดนี้มีข้อควรระวังสำคัญคือ ต้องใช้ฟังก์ชัน <code>timingSafeEqual</code> แทนการใช้เครื่องหมายเทียบเท่าธรรมดา <code>===</code> เพราะการเปรียบเทียบสตริงปกติจะหยุดทำงานทันทีที่พบไบต์ที่ต่างกัน ทำให้ผู้โจมตีสามารถคาดเดาไบต์ที่ถูกต้องได้จากการวัดเวลาในการประมวลผล นอกจากนี้ ต้องเซ็นบนตัว Raw Body ไม่ใช่บน Parsed Object ซึ่งถือเป็นบั๊กยอดฮิตที่สร้างความปวดหัวให้กับนักพัฒนาจำนวนมาก</p><div class="ai-insight"><p>การใช้ timingSafeEqual เป็นแนวทางป้องกัน Timing Attack ซึ่งเป็นช่องโหว่ด้านความปลอดภัยที่มักถูกมองข้าม การที่ระบบคืนค่าช้าหรือเร็วต่างกันเพียงไม่กี่มิลลิวินาทีก็เพียงพอให้แฮกเกอร์ใช้เครื่องมือวิเคราะห์หาคีย์ลับได้ การใช้ฟังก์ชันเปรียบเทียบแบบ Constant-time จึงเป็นมาตรฐานสำคัญในการจัดการข้อมูลที่มีความละเอียดอ่อนสูง</p></div><p>ลายเซ็นที่ถูกต้องเป็นเครื่องยืนยันว่าข้อมูลมาจากผู้ให้บริการจริง แต่มันไม่ได้หมายความว่าเหตุการณ์นั้นเกิดขึ้นในตอนนี้ เพราะแฮกเกอร์ที่ดักจับคำขอไว้สามารถส่งมันกลับมาใหม่ในอีกหนึ่งเดือนข้างหน้าโดยที่ลายเซ็นยังคงใช้งานได้ ผู้ให้บริการจึงใส่ Timestamp มาใน Payload ที่เซ็นด้วย ซึ่งคุณจะต้องเขียนโค้ดตรวจสอบเงื่อนไขเวลานี้เสมอ</p><p>เรื่องต่อมาคือการบริหารจัดการ Timeout และ Status Code โดยปกติผู้ให้บริการจะให้เวลาตอบกลับสั้นๆ เพียง 5 ถึง 30 秒 หากเกินกำหนดพวกเขาจะบันทึกข้อผิดพลาดและส่งคำขอซ้ำ หาก Handler ของคุณทำงานช้าเพราะต้องส่งอีเมล อัปเดตตารางฐานข้อมูลสามแห่ง และเรียก API ภายนอก คุณก็จะเจอการส่งซ้ำในขณะที่คำขอแรกยังรันอยู่ ทำให้เกิดงานซ้ำซ้อน</p><div class="stat-row"><div class="stat-item"><span class="stat-number">5-30s</span><span class="stat-label">ช่วงเวลา Timeout ทั่วไปจากผู้ให้บริการ</span></div></div><p>การตอบกลับ Status Code ให้ถูกต้องจึงเป็นหัวใจสำคัญ โดย 200 หมายถึงได้รับแล้วหยุดส่งซ้ำ, 4xx หมายถึงคำขอนี้พัง ไม่ต้องส่งซ้ำ และ 5xx หมายถึงให้ลองส่งใหม่อีกครั้ง การเผลอคืนค่า 200 บนข้อผิดพลาดที่คุณควรจะกู้คืนได้จะทำให้เหตุการณ์นั้นหายไปจากระบบอย่างถาวร นอกจากนี้ ระบบ Retry ไม่ใช่เรื่องบังเอิญแต่มันเกิดขึ้นได้จาก Timeout การ Deploy หรือปัญหาระบบเครือข่าย คุณจึงต้องออกแบบให้ระบบเป็น Idempotent เพื่อให้มั่นใจว่าต่อให้เหตุการณ์เดิมรันสองครั้ง งานก็จะไม่ถูกทำซ้ำซ้อน</p><p>ทางออกที่ดีที่สุดคือปล่อยให้ฐานข้อมูลเป็นผู้ตัดสินใจจัดการความซ้ำซ้อนผ่าน UNIQUE constraint แทนการเช็คโค้ดในแอปพลิเคชันธรรมดา เนื่องจากสองคำขอที่เข้ามาพร้อมกันอาจอ่านค่าได้ว่ายังไม่เคยเห็นทั้งคู่ หากผู้ให้บริการไม่ได้ส่ง Stable Event ID มาให้ คุณต้องสร้างมันขึ้นมาจากฟิลด์ที่บ่งชี้เหตุการณ์นั้นๆ เช่น รหัสข้อความรวมกับประเภทเหตุการณ์และเวลา ห้ามแฮช Payload ทั้งหมดเพราะผู้ให้บริการมักจะเพิ่มฟิลด์ใหม่ๆ เข้ามาตามกาลเวลา</p><p>ปัญหาเรื่องลำดับการส่งก็เป็นอีกเรื่องที่ต้องระวัง เนื่องจากไม่มีการรับประกันลำดับการมาถึง ข้อมูลการส่งที่ถูกลองส่งใหม่อาจมาถึงช้ากว่าสถานะการส่งสำเร็จที่เกิดขึ้นทีหลัง การแก้ปัญหาทำได้โดยใช้ Precedence แทน Timestamp โดยกำหนดให้สถานะบางอย่างมีความสำคัญสูงสุดและบล็อกการมาถึงที่ล่าช้าออกไป สำหรับเหตุการณ์ที่คุณปฏิเสธการรับ ควรมีการจัดเก็บข้อมูลเหล่านั้นไว้ตรวจสอบภายหลังก่อนที่ผู้ให้บริการจะยกเลิกการส่งซ้ำ</p><p class="source-attribution">ที่มา: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/devopsdaily/receiving-webhooks-without-getting-burned-5dih" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>Always verify signatures using timingSafeEqual on the raw body</li><li>Check timestamps to prevent replay attacks</li><li>Design your handler to be idempotent to handle retries safely</li><li>Use precedence rules instead of timestamps for out-of-order events</li></ul></div><p>Sending a webhook is trivial. You just POST some JSON to a URL and move on. Receiving one, however, is where the hidden pitfalls lie. The endpoint is public, meaning anyone can call it. It gets retried, so it will run twice. It arrives out-of-order, meaning a 'delivered' status can land before 'sent'. And it sits directly on the critical path of someone else's system, so if you are slow, they time out and retry, making you even slower.</p><p>None of this is difficult once you know it, but all of it remains invisible until you hit production. This article covers the complete set of challenges a webhook receiver must handle and the specific failures each one prevents. We use email delivery webhooks (bounces and complaints) as our running example because they pack every awkward property into one: they are security-sensitive, they retry, they arrive out of order, and processing them twice corrupts actual state. These principles apply equally to Stripe, GitHub, Shopify, or any other webhook provider.</p><p>Your endpoint is a public URL, which means without verification, anyone who discovers it can post a fake 'hard bounced' event to suppress a customer, or a fake 'payment succeeded' event to grant a free subscription. Providers sign each request with a shared secret, and your job is to recompute the signature and compare it.</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/webhook_production_ms3h9lo1_inline_1_7135cd8318.jpg" alt="network pipeline data flow" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div><p>You must use <code>timingSafeEqual</code> rather than a standard <code>===</code> string comparison. A normal string comparison returns as soon as it finds a mismatching byte. An attacker who measures that timing can recover a valid signature byte by byte. It is a real, exploitable attack, but easily avoided with a single function call. Furthermore, always sign the raw body rather than the parsed object—this is the single most common webhook bug and notoriously frustrating to debug.</p><div class="ai-insight"><p>Timing attacks exploit the microscopic differences in execution time when a computer compares strings character by character. By using a constant-time comparison function like timingSafeEqual, you neutralize this vector entirely, ensuring that verification takes the exact same amount of time regardless of how many bytes match.</p><p>A valid signature only proves the payload came from your provider; it does not prove it is happening right now. An attacker who captures a legitimate request can replay it a month later with the signature fully intact. This is why providers include a timestamp in the signed payload, which your handler must actively inspect and validate.</p><p>Providers also enforce strict timeouts, frequently ranging between 5 and 30 seconds. Exceeding this window causes them to record a failure and trigger a retry. If your handler is sluggish because it dispatches emails, updates three database tables, and calls a downstream API, you will get retried while the first attempt is still executing, instantly doubling your workload.</p><div class="stat-row"><div class="stat-item"><span class="stat-number">5-30s</span><span class="stat-label">Typical webhook provider timeout window</span></div></div><p>Returning the correct HTTP status code is vital. A 200 response means 'I have it, stop retrying.' A 4xx response means 'this request is broken, do not bother retrying.' A 5xx response means 'try me again later.' Returning a 200 status on an error you could have recovered from will permanently discard the event. Retries are standard operations caused by timeouts, deployments, or network blips, so your handler must be built to process the same event twice without duplicating work.</p><p>Avoid solving this with a simple application-level 'have I seen this?' check. Two concurrent retries will both read 'no' before either can write. Instead, let the database enforce uniqueness. If the provider does not supply a stable event ID, synthesize one from fields identifying the unique occurrence—such as message ID combined with event type and timestamp. Never hash the entire payload, as providers add fields over time, which would invalidate your fingerprint for identical events.</p><p>Ordering guarantees do not exist. A retry sent three minutes ago can easily arrive after the delivery event that followed it. Handle this with state precedence rather than raw timestamps, ensuring terminal states outrank late arrivals. For events you must reject, store them safely before the provider gives up on retries and data vanishes into the void.</p><p class="source-attribution">Source: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/devopsdaily/receiving-webhooks-without-getting-burned-5dih" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

medium_webhook-production-ms3h9lo1.jpg

small_webhook-production-ms3h9lo1.jpg

thumbnail_webhook-production-ms3h9lo1.jpg

webhook-production-ms3h9lo1.jpg

คู่มือปฏิบัติการรับ Webhook แบบละเอียดยิบ รับมือปัญหารั่วไหล ข้อมูลซ้ำ และลำดับเพี้ยน เพื่อระบบหลังบ้านที่เสถียร

An in-depth operational guide to safely receiving webhooks, handling retries, race conditions, and out-of-order events.

เจาะลึกวิธีรับ Webhook ให้ปลอดภัย ไม่พลาดตกม้าตายบน Production

Receiving Webhooks Without Getting Burned: A Production Guide

Inewgen

Inewgen

#API Security

อันตรายจาก AI Agent ที่มีสิทธิ์มากเกินไปและแนวทางป้องกัน

Inewgen

LLM API Router: 9 จาก 428 ตัวกลางแอบฉีดโค้ดใส่ Agent

Inewgen

บั๊กคู่แฝดพังระบบจ่ายเงิน AI บน APEX Versus

Inewgen

ทำไม Guardrails ของ AI Agent ถึงคุมเรื่องเงินไม่ได้

Inewgen

เจาะช่องโหว่ Metabase SQL Injection: ขโมยสิทธิ์แอดมินสู่ฐานข้อมูล

Inewgen

เจาะลึกวิธีรับ Webhook ให้ปลอดภัย ไม่พลาดตกม้าตายบน Production

Inewgen