RCE 'តាមការរចនា' របស់ MCP៖ ពេលអ្នកផ្គត់ផ្គង់និយាយថា ភាពងាយរងគ្រោះជាមុខងារ

មានប្រភេទនៃការរកឃើញសុវត្ថិភាពជាក់លាក់មួយ ដែលបំបែកពិធីការធម្មតា។ ជាធម្មតា អ្នកស្រាវជ្រាវបង្ហាញ អ្នកផ្គត់ផ្គង់បញ្ជាក់ patch ត្រូវដឹក មនុស្សគ្រប់គ្នាធ្វើបច្ចុប្បន្នភាព CVE បិទ។ វដ្តមានរូបរាង ហើយរូបរាងបញ្ចប់ដោយ fix។ ភាពងាយរងគ្រោះដែល OX Security បានបង្ហាញនៅក្នុង Model Context Protocol SDK ផ្លូវការរបស់ Anthropic មិនមានរូបរាងនោះទេ។ អ្នកស្រាវជ្រាវបានរកឃើញផ្លូវ remote code execution ដែលដំណើរការតាម SDK ដែលផ្ដល់ថាមពលដល់ agent Python, TypeScript, Java, និង Rust។ Anthropic បានបញ្ជាក់អំពើនេះ។ ហើយបន្ទាប់មក ជំនួសឱ្យ patch ចម្លើយត្រឡប់មកវិញ៖ នេះជាការរចនា។ ការ sanitization ជាទំនួលខុសត្រូវរបស់អ្នកអភិវឌ្ឍ។ គ្មាន CVE ត្រូវបិទទេ ព្រោះតាមអ្នកផ្គត់ផ្គង់ គ្មានអ្វីខូចទេ។

នោះជា paradox ដែលគួរអង្គុយជាមួយ។ យើងបានគ្របដណ្ដប់រូបរាងទូលំទូលាយនៃបញ្ហានេះកាលពីមុនក្នុង MCP in 2026: The Universal Standard — and Its Security Problem ដែលអំណះអំណាងគឺថា standard plug ត្រូវបានដោះស្រាយ ប៉ុន្តែសុវត្ថិភាពនៃអ្វីដែលអ្នកដោត នៅបើកចំហ។ អត្ថបទនេះជា sequel ជាក់លាក់តាមឧប្បត្តិហេតុ។ អត្ថបទមុនព្រមានអំពី ecosystem; អត្ថបទនេះអំពី SDK នៅកណ្ដាលវា ហើយអំពីអ្វីដែលវាមានន័យ ពេលដែលកំហុសធ្ងន់ធ្ងរបំផុតក្នុង protocol ត្រូវបានចាត់ថ្នាក់ឡើងវិញ ដោយមនុស្សដែលជាម្ចាស់ protocol ថាជាអំពើដែលមានចេតនា។

យន្តការ៖ config ទៅ command គ្មាន gate នៅចន្លោះ

ដើម្បីយល់ពីមូលហេតុដែល “តាមការរចនា” អាចការពារបានតាមបច្ចេកទេស និងគួរឱ្យភ័យខ្លាចតាមប្រតិបត្តិការក្នុងពេលដំណាលគ្នា អ្នកត្រូវមើលរបៀបដែល STDIO transport របស់ MCP ដំណើរការ។ MCP server អាចដំណើរការជា process មូលដ្ឋាន។ ពេល agent ភ្ជាប់ទៅវាតាម STDIO វា spawn server ដោយ execute command មួយ — binary, interpreter, script — ជាមួយ argument ទាំងអស់អានពី configuration។ Configuration នោះគ្រាន់តែជាទិន្នន័យ៖ blob បែប JSON ដែលនិយាយថា “ដើម្បីចាប់ផ្ដើម server នេះ run command នេះ ជាមួយ argument ទាំងនេះ”។

កំហុស ដូចដែល OX Security និងការវិភាគបន្តពី Zealynx Security (“Anthropic MCP SDK Vulnerability Full Analysis,” ឧសភា ២០២៦) ពិពណ៌នា គឺថា field command ត្រូវបានយកតាមតម្លៃមុខ ហើយ execute នៅលើ host។ បើអ្វីៗដែលអ្នកវាយប្រហារអាចមានឥទ្ធិពលហូរចូលក្នុង field នោះ — config ដែលទាញពីប្រភពពីចម្ងាយ តម្លៃ template ពី user input ឬ server entry ទាញពី marketplace — នោះអ្នកវាយប្រហារកំពុងជ្រើសរើសអ្វីដែល run នៅលើម៉ាស៊ីន។ Agent មិនចាំបាច់ initialize MCP server ត្រឹមត្រូវដោយជោគជ័យទេ។ Code execute កំឡុង ការប៉ុនប៉ង។ គ្មាន gate ផ្ទៀងផ្ទាត់រវាង “នេះជា config” និង “នេះជា process ដែលដំណើរការជាមួយសិទ្ធិរបស់អ្នក”។

នេះជាមូលហេតុដែល Anthropic អាចហៅវាថា តាមការរចនា។ SDK ធ្វើពិតប្រាកដនូវអ្វីដែលវានិយាយ៖ វា run command ដែលអ្នក configure។ Library មិនមែនជាកន្លែង តាមទស្សនៈរបស់ពួកគេ ដែល untrusted input គួរត្រូវចាប់។ ការចាប់គួរកើតឡើងនៅ upstream ក្នុង application ដោយអ្នកអភិវឌ្ឍ។ ត្រឹមត្រូវតាមបច្ចេកទេស។ ប៉ុន្តែតាមការអនុវត្ត វាមានន័យថា ប្រតិបត្តិការគ្រោះថ្នាក់បំផុតក្នុង stack — arbitrary command execution — ត្រូវបានការពារដោយគ្មានអ្វីក្រៅពីការសន្មតថា អ្នកអភិវឌ្ឍ downstream រាប់លាននាក់ម្នាក់ៗ sanitize ត្រឹមត្រូវរាល់ផ្លូវដែលអាចទៅដល់ field config។

គ្រួសារ attack បួន

ការបង្ហាញ និងការសរសេរជុំវិញ (SuperML.dev MCP’s Security Debt Just Came Due និង DevOps Daily “The MCP Design Flaw That Exposes 150M Downloads to RCE”) ដាក់ការទាញយកប្រយោជន៍ជាក់ស្ដែងជាប្រហែលបួនគ្រួសារ៖

• UI injection ដោយគ្មានការផ្ទៀងផ្ទាត់។ ឧបករណ៍ដែលបើក MCP ជាច្រើនបង្ហាញ interface មូលដ្ឋាន — panel, web view, control surface — ដែលទទួល server configuration ដោយមិនផ្ទៀងផ្ទាត់អ្នកស្នើ។ អ្នកវាយប្រហារដែលអាចទៅដល់ surface នោះ អាចចុះឈ្មោះ server ជាមួយ command field អរិភាព ហើយឱ្យវា execute ដោយមិនត្រូវការ credential។
• ការ bypass sanitization។ កន្លែងដែលអ្នកអភិវឌ្ឍ បាន ព្យាយាមត្រង field command, filter នោះរាក់។ ល្បិច encoding, ការបំបែក argument, និងការប្រើ shell-feature ខុស រអិល payload អរិភាពកាត់ allowlist និង denylist សាមញ្ញ។ guard ពាក់កណ្ដាលជាសញ្ញាអាក្រក់ជាងគ្មាន guard ព្រោះវាមើលទៅដូចជាបញ្ហាត្រូវបានដោះស្រាយ។
• Zero-click prompt injection។ នេះជារឿងដែលគួរធ្វើឱ្យប្រតិបត្តិករ agent ព្រួយបារម្ភបំផុត។ tool description ដែលមានពិស ឬឯកសារអរិភាព ដែលស្រូបដោយ agent ដែលដំណើរការក្នុង IDE ឬ pipeline ស្វ័យប្រវត្តិ អាចដឹក model ឱ្យចុះឈ្មោះ ឬ invoke server ដែល command field ផ្ទុក payload — ដោយគ្មានមនុស្សចុចអ្វីទេ។ Injection ជិះលើ autonomy របស់ agent ផ្ទាល់។ អត្រាជោគជ័យ tool-poisoning លើស 60% ប្រឆាំង LLM agent ធំៗ ត្រូវបានរាយការណ៍ក្នុងថ្នាក់នេះ។
• Marketplace និងការចែកចាយអរិភាព។ ពេល ecosystem រីកធំ registry និង marketplace ដែលចែកចាយ server definition ក៏រីកដែរ។ Entry អរិភាព ឬត្រូវ compromise អាចដឹក command field ដែល compromise រាល់ host ដែលដំឡើងវា — supply-chain compromise ជាមួយឆានែលចែកចាយផ្ទាល់របស់ protocol ជាយន្តការដឹក។ ការដាក់ស៊ុមរបស់ OX Security ក្នុងអត្ថបទ មេសា ២០២៦ “The Mother of All AI Supply Chains” មិនមែនជាការនិយាយបំផ្លើសទេ ដោយសារ reach។

កាំរស្មីផ្ទុះ

លេខគឺជាអ្វីដែលផ្លាស់វាពីកំហុសទៅជាឧប្បត្តិហេតុជាប្រព័ន្ធ។ SDK ដែលជាប់ពាក់ព័ន្ធផ្ទុក 150M+ ការទាញយក។ ការ scan របស់ OX Security បានកំណត់ប្រហែល 7,000 MCP server ដែលបង្ហាញជាសាធារណៈ និងប៉ាន់ស្មាន 200,000 instance ងាយរងគ្រោះ ក្នុងធម្មជាតិ។ លើស CVE downstream ដប់ ត្រូវបានដាក់ ពេលការរកឃើញរីករាលដាលតាមគម្រោងពឹងផ្អែក — CVE-2026-30615, -30617, -30618, និងផ្សេងៗក្នុងលំដាប់នោះ — សូម្បីតែអំពើ root ក្នុង SDK ខ្លួនវាគ្មាន patch ព្រោះអ្នកផ្គត់ផ្គង់មិនចាត់ទុកវាជាកំហុស។

អង្គុយជាមួយ governance gap ដែលបើកនៅទីនេះ។ CVE ក្នុងចំណោមរបស់ផ្សេង គឺជា artifact នៃការទទួលខុសត្រូវ៖ វាដាក់ឈ្មោះកំហុស កំណត់ severity ហើយបង្កើតការរំពឹងថា នរណាម្នាក់ fix វា។ ពេលអ្នកផ្គត់ផ្គង់ប្រកាសថា root cause មានចេតនា ខ្សែសង្វាក់នៃការទទួលខុសត្រូវត្រូវកាត់នៅកំពូល ហើយភ្ជាប់ឡើងវិញ ជាអចិន្ត្រៃយ៍ ទៅបាត — ទៅអ្នកអភិវឌ្ឍម្នាក់ៗដែលរួមបញ្ចូល SDK។ ការទទួលខុសត្រូវមិនបាត់ទេ។ វាត្រូវបានចែកចាយ ស្ងាត់ៗ លើមនុស្ស 150 លានការទាញយក ដែលភាគច្រើនមិនដឹងថា ពួកគេបានទទួលមរតកវា។ នេះជាថាមវន្តដូចគ្នាដែលយើងបានតាមដានក្នុង The $100 Billion Guardrail៖ ការងារសុវត្ថិភាពមិនបាត់ទេ ពេល platform បដិសេធធ្វើវា; វាគ្រាន់តែផ្លាស់ទៅ downstream ហើយក្លាយជា cost center របស់នរណាម្នាក់ផ្សេង។ នៅទីនេះ ការផ្លាស់ច្បាស់លាស់។ អ្នកផ្គត់ផ្គង់បានដាក់ឈ្មោះម្ចាស់នៃបញ្ហា ហើយម្ចាស់គឺអ្នក។

ហេតុអ្វីបានជានេះជាឱកាសអាស៊ីអាគ្នេយ៍ មិនមែនត្រឹមហានិភ័យអាស៊ីអាគ្នេយ៍

បើ spec មិនចាប់ untrusted input មុនពេលវាក្លាយជា command នោះ នរណាម្នាក់ ត្រូវសាងស្រទាប់ដែលធ្វើ — MCP command allowlist, config validator, registration monitor។ ហើយនេះជាផ្នែកដែលសំខាន់សម្រាប់ក្រុមមានដើមទុនតិចនៅ ភ្នំពេញ ដាណាង ឬ សេប៊ូ៖ ការសាងស្រទាប់នោះមិនត្រូវការ GPU មិនត្រូវការ training run មិនត្រូវការ data center។ វាត្រូវការការយល់ពី protocol ការ audit surface ដែល config ទៅដល់ការ execute និងការសរសេរ validation ប្រកបដោយវិន័យ។ នោះជាវិស្វកម្ម មិនមែនដើមទុន។

នេះជាឱកាសដូចគ្នាដែលយើងបានអះអាងម្ដងហើយម្ដងទៀត។ ក្រុមដែលអាចយក MCP deployment ហើយផលិតកំណែដែលរឹង audit និងមាន allowlist — កំណែដែលអនុវត្តអ្វីដែល SDK បដិសេធ — កំពុងសាង IP ការពារបាន ចេញពីជំនាញ ជាជាងការចំណាយ។ អ្នកផ្គត់ផ្គង់បានផ្ទេរ fix ទៅ downstream ជាអចិន្ត្រៃយ៍; ការផ្ទេរនោះជាទីផ្សារ។ ព្រំដែនដែលអ្នកនឹងអនុវត្ត គឺពិតជាការងារ guardrail-ជា-ព្រំដែន-អនុលោមភាព អនុវត្តនៅប្រតិបត្តិការគ្រោះថ្នាក់បំផុតក្នុង agent stack។ ហើយវាផ្គូផ្គងធម្មជាតិជាមួយវិន័យ isolation ពី Sandboxing the Agent — allowlist សម្រេចថា អ្វីអាច run, sandbox កំណត់ថា ការខូចខាតអាចទៅដល់អ្វី ពេលអ្វីមួយរអិល allowlist។ ការការពារ ដូចដែលយើងបាននិយាយក្នុង Defense in the Loop ត្រូវអង្គុយនៅពាក់កណ្ដាល task រវាង config និង command មិនមែនភ្ជាប់ក្រោយ។

អ្វីដែលប្រតិបត្តិករត្រូវធ្វើថ្ងៃនេះ

ជំហររបស់អ្នកផ្គត់ផ្គង់មានន័យថា ការទទួលខុសត្រូវឥឡូវ ច្បាស់លាស់ ជាប្រតិបត្តិការ។ ជាក់ស្ដែង៖

• ផ្ទៀងផ្ទាត់រាល់ MCP server config មុនពេលវាត្រូវ load។ ចាត់ទុក field command ជាប្រតិបត្តិការសិទ្ធិដែលវាជា។ វាគួរជា binary path ដែលដឹង និងថេរ មិនមែនជាតម្លៃផ្គុំនៅ runtime។
• អនុវត្ត command allowlist។ Agent គួរត្រូវបានអនុញ្ញាតឱ្យចាប់ផ្ដើមតែ server command សំណុំច្បាស់ និង audit។ អ្វីដែលមិននៅលើបញ្ជី មិន run។ នេះជាស្រទាប់ដែល SDK នឹងមិនផ្ដល់ឱ្យអ្នក ដូច្នេះអ្នកសាងវា។
• កុំ pipe untrusted user input ចូល STDIO config field។ គ្មាន templating គ្មាន string interpolation គ្មានផ្លូវ “ងាយស្រួល” ដែលឱ្យ request body, ឯកសារ fetch, ឬ marketplace entry ទៅដល់ command។ បើ input ត្រូវមានឥទ្ធិពលលើអំពើ route វាតាម parameter ដែលផ្ទៀងផ្ទាត់ មិនមែន executable ខ្លួនវា។
• តាមដាន MCP registration ដែលមិនរំពឹង។ server ថ្មីដែលលេចឡើងក្នុង config របស់ agent ដែលគ្មាននរណា deploy ជាឧប្បត្តិហេតុ មិនមែនជារឿងចង់ដឹង។ Alert លើវា។ Zero-click injection ដំណើរការពិតប្រាកដ ព្រោះ registration ស្ងាត់។
• Sandbox process server។ សន្មតថា allowlist នឹងត្រូវ bypass នៅទីបំផុត ហើយកំណត់កាំរស្មីផ្ទុះ ជាមួយ isolation, least privilege, និងការគ្រប់គ្រង network egress។

MCP បានដោះស្រាយរបៀបដែល agent ភ្ជាប់ទៅឧបករណ៍ ហើយនោះជាសមិទ្ធផលពិត។ ប៉ុន្តែអ្នកផ្គត់ផ្គង់ឥឡូវបានគូសបន្ទាត់ភ្លឺ៖ SDK run អ្វីដែលអ្នកប្រាប់វា run ហើយការចាប់អ្វីដែលមិនគួរប្រាប់វា ជាការងាររបស់អ្នក ជារៀងរហូត។ នោះមិនមែនជាស្ថានភាពបណ្ដោះអាសន្នរង់ចាំ patch ទេ។ វាជាកិច្ចសន្យាអចិន្ត្រៃយ៍។ ក្រុមដែលយល់ដឹងវា — ហើយសាង allowlist ដែល spec បដិសេធ — គឺជាក្រុមដែលអាចប្រើ MCP ដោយមិនទទួលមរតក CVE អាក្រក់បំផុតរបស់វាតាមលំនាំដើម។