Grafana MCP-তে patch-এর পরও SSRF ছিল—এবার destination-ও বাঁধা
২ সেপ্টেম্বর ২০২৬ প্রকাশিত Pillar Security-এর কারিগরি বিশ্লেষণ দেখিয়েছে, Grafana MCP-এর আগের patch service-account token অপরিচিত host-এ পাঠানো বন্ধ করলেও server-কে সেই host-এ request করতে বাধা দেয়নি। Caller তাই MCP server-এর নিজস্ব network reach ব্যবহার করতে পারত; গবেষকের demonstration controlled canary-তে সীমিত ছিল, live Grafana instance বা cloud metadata service স্পর্শ করা হয়নি।
১১ আগস্ট প্রকাশিত Grafana Labs-এর security advisory এই ত্রুটিকে critical CVE-2026-19516 হিসেবে চিহ্নিত করেছে, CVSS score দিয়েছে ৯.১ এবং Grafana MCP ১.১.০ বা পরের সংস্করণকে fixed বলেছে। অর্থাৎ চলমান release ওই সীমার নিচে হলে upgrade প্রয়োজন; তবে ২ সেপ্টেম্বরের বিশ্লেষণ দেখায়, deployment-এর exposure, inbound authentication এবং অনুমোদিত outbound destination-ও আলাদাভাবে পরীক্ষা করা জরুরি।
আগের patch credential বেঁধেছিল, destination নয়
ত্রুটির কেন্দ্র ছিল grafana_api_request tool ও caller-controlled X-Grafana-URL header। Toolটি ব্যবহার করতে সক্ষম caller ওই header দিয়ে outbound request-এর destination বেছে নেওয়ার পাশাপাশি method, path, body ও header প্রভাবিত করতে পারত। Destination configured Grafana instance-এ সীমিত না থাকায় request internal, loopback বা link-local service-এ পাঠিয়ে response পড়ার পথ তৈরি হয়েছিল—এটাই SSRF।
আগের CVE-2026-15583 সংশোধন একটি নির্দিষ্ট ক্ষতি ঠেকিয়েছিল: X-Grafana-URL অন্য host নির্দেশ করলে configured Grafana service-account token আর সেই host-এ যুক্ত হতো না। কিন্তু credential কোথায় যাবে এবং server কোথায় connection খুলতে পারবে—এ দুটি পৃথক security boundary। Token গোপন থাকলেও caller-নির্ধারিত address-এ request পাঠিয়ে response ফেরত দিলে MCP server readable network proxy হিসেবে কাজ করতে পারে।
এই পার্থক্যই নির্বাচিত শিরোনামের মূল দাবি: প্রথম patch token binding ঠিক করেছিল, কিন্তু outbound destination খোলা রেখেছিল; পরের সংশোধনে request-কে configured Grafana target-এর সীমায় বাঁধতে হয়েছে। তাই কোনো পরিবর্তনকে শুধু “SSRF fix” নামে বিচার না করে সেটি credential, caller identity নাকি destination—কোন property নিয়ন্ত্রণ করছে, তা দেখা দরকার।
ক্ষতির সীমা নির্ভর করে server কোথায় পৌঁছাতে পারে
CVE-2026-19516 কাজে লাগানোর সরাসরি পূর্বশর্ত হলো grafana_api_request invoke করার ক্ষমতা। সেই ক্ষমতা পাওয়া caller নিজের device থেকে অদৃশ্য কোনো service-এ সরাসরি পৌঁছাতে না পারলেও MCP server-কে requester বানাতে পারে। ফলে ঝুঁকি শুধু public internet exposure দিয়ে মাপা যায় না; container, virtual machine, cluster বা corporate network থেকে দৃশ্যমান address-গুলিও blast radius-এর অংশ।
সম্ভাব্য destination-এর মধ্যে private service, localhost listener, link-local endpoint ও cloud instance metadata endpoint রয়েছে। Response caller-এর কাছে ফেরায় এটি কেবল blind port probe নয়: reachable service কী ফেরায় এবং caller-controlled method বা header গ্রহণ করে কি না, তার ওপর internal তথ্য প্রকাশ, metadata credential নেওয়ার চেষ্টা বা lateral movement-এর সুযোগ তৈরি হতে পারে। এগুলি সম্ভাব্য প্রভাব—প্রতিটি deployment metadata service-এ পৌঁছাতে পারে বা সেখানে মূল্যবান credential থাকে, এমন প্রমাণ প্রকাশিত হয়নি।
Inbound authentication এই ঝুঁকির একটি স্তর কমায়, কিন্তু destination policy-এর বিকল্প নয়। বৈধ account দখল, অতিরিক্ত tool permission অথবা ভুলভাবে উন্মুক্ত endpoint—যেভাবেই invocation সম্ভব হোক, unrestricted egress server-এর network অবস্থানকে আলাদা ক্ষমতায় পরিণত করে। তাই MCP deployment-এর পূর্ণ audit-এ পরিচয় ও tool authorization-এর সঙ্গে network boundary-ও রাখা প্রয়োজন।
Controlled demo কী প্রমাণ করেছে—আর কী করেনি
গবেষকের নিয়ন্ত্রিত পরীক্ষায় একটি internal canary caller-নির্ধারিত POST request ও body পেয়েছিল। Grafana service-account token সেখানে যায়নি—অর্থাৎ আগের credential-binding protection কার্যকর ছিল—কিন্তু canary-এর response MCP caller-এর কাছে ফিরে এসেছিল। পৃথক IMDSv2-ধাঁচের পরীক্ষায় caller-selected PUT request ও TTL header দিয়ে পরীক্ষামূলক metadata session token নেওয়া হয়, তারপর আরেকটি request সেই token ব্যবহার করে canary credential ফেরত আনে।
এই ফল server-side request primitive-এর ক্ষমতা দেখায়: destination-এর সঙ্গে method ও header নিয়ন্ত্রণ করে server-এর network position থেকে readable request চালানো সম্ভব ছিল। এটি কোনো বাস্তব cloud account compromise-এর প্রমাণ নয়, কারণ পরীক্ষায় live metadata service বা live Grafana instance ব্যবহৃত হয়নি। কোনো প্রতিষ্ঠানে প্রকৃত ক্ষতি হয়েছিল কি না জানতে version-এর পাশাপাশি network route, egress policy ও সংশ্লিষ্ট request log দেখতে হবে।
চার ধাপে deployment audit
Administrator-এর audit-এ একই chain-এর চারটি boundary আলাদা করে দেখা উচিত। Package update হয়ে গেলেই পুরোনো replica, উন্মুক্ত transport বা বিস্তৃত egress policy নিজে থেকে সংশোধিত হয় না।
- Exposure: SSE বা streamable HTTP endpoint কোন interface-এ bind করা, internet, shared VPC, cluster ও corporate network থেকে কারা পৌঁছাতে পারে এবং reverse proxy কোন route প্রকাশ করছে—listener, ingress, load balancer ও firewall configuration মিলিয়ে দেখুন।
- Authentication: MCP session identifier-কে credential হিসেবে গণ্য করবেন না। Remote transport-এ bearer-token authentication configured কি না এবং credential ছাড়া request tool execution-এর আগেই 401 পায় কি না নিয়ন্ত্রিত পরিবেশে যাচাই করুন। Enabled tool অনুযায়ী authorization সীমিত রাখুন এবং service account-কে শুধু প্রয়োজনীয় Grafana permission দিন।
- Allowed destination: grafana_api_request কেবল অনুমোদিত Grafana origin-এ যেতে পারে কি না পরীক্ষা করুন। Hostname resolve করার পর loopback, private, link-local, metadata ও অন্য অননুমোদিত range defaultভাবে block রাখা এবং connection-এর সময় address পুনরায় যাচাই করা DNS rebinding-এর exposure কমায়। প্রয়োজন না থাকলে arbitrary method ও header forwarding-ও সীমিত করুন।
- Fixed version: repository manifest নয়, চলমান binary, container image বা deployed package থেকে version নিশ্চিত করুন। প্রতিটি instance ১.১.০ বা পরের release-এ আছে কি না দেখুন এবং staging-এ configured origin-এর বাইরের X-Grafana-URL প্রত্যাখ্যাত হচ্ছে কি না যাচাই করুন। পুরোনো replica, rollback image ও dormant environment-ও একই inventory-তে রাখুন।
যা নিশ্চিত, আর যা এখনও প্রমাণিত নয়
নিশ্চিত তথ্য হলো, আগের সংশোধন service-account token-কে অননুমোদিত host থেকে রক্ষা করলেও destination সীমিত করেনি; পরের critical advisory সেই অবশিষ্ট SSRF-এর fixed floor নির্ধারণ করেছে। গবেষকের controlled test আবার দেখিয়েছে, token না গেলেও MCP server caller-এর নাগালের বাইরের network location-এ method-সক্ষম request চালিয়ে response ফেরাতে পারত।
প্রকাশিত নথিতে বাস্তব পরিবেশে exploitation, cloud account compromise বা সব deployment-এ metadata access-এর প্রমাণ নেই। Operator-এর জন্য অমীমাংসিত অংশ তাই নিজস্ব deployment-নির্ভর: vulnerable instance reachable ছিল কি না, caller authentication কার্যকর ছিল কি না, server কোন destination-এ যেতে পারত এবং বর্তমানে চলমান সব instance fixed release ও সীমিত destination policy ব্যবহার করছে কি না।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।