LiteLLM gateway ভেঙে API key চুরি—খোলা AI control plane-ই লক্ষ্য

Microsoft Security Research-এর ২৬ আগস্টের তদন্তে ইন্টারনেটে উন্মুক্ত একটি LiteLLM gateway দখল করে model-provider API key, LiteLLM master key ও database connection string চুরির প্রমাণ পাওয়া গেছে। আক্রমণকারীরা পরে backend PostgreSQL database থেকে model configuration ও proxy-issued virtual key সংগ্রহ করেছে, host-এ স্থায়ী প্রবেশের ব্যবস্থা করেছে এবং cryptomining-এর উপযোগী payload চালিয়েছে।

প্রাথমিক প্রবেশ উন্মুক্ত LiteLLM gateway surface দিয়েই হয়েছিল বলে উচ্চ আস্থায় মূল্যায়ন করা হয়েছে, তবে নির্দিষ্ট প্রথম request বা exploit সরাসরি শনাক্ত হয়নি। আলাদা LiteLLM security advisory দেখায়, authenticated command-execution ত্রুটি CVE-2026-42271 সংস্করণ 1.74.2 থেকে 1.83.7-এর আগের release-এ ছিল; 1.83.7-এ ত্রুটিটি ঠিক করা হয়েছে।

Gateway থেকে command execution কীভাবে সম্ভব হয়েছিল

CVE-2026-42271 LiteLLM-এর MCP server সংযোগ যাচাইয়ের দুটি endpoint-কে প্রভাবিত করেছিল: POST /mcp-rest/test/connection এবং POST /mcp-rest/test/tools/list। Endpoint দুটি request body থেকে stdio transport-এর command, arguments ও environment নিয়ে proxy host-এ subprocess চালাতে পারত।

এই route-গুলোতে বৈধ proxy API key প্রয়োজন হলেও কোনো role check ছিল না। ফলে administrator না হয়েও low-privilege internal-user key-ধারী gateway process-এর ক্ষমতায় arbitrary command চালাতে পারত। 1.83.7 release-এ দুটি endpoint-এর জন্য PROXY_ADMIN role বাধ্যতামূলক করা হয়েছে; তাৎক্ষণিক upgrade সম্ভব না হলে reverse proxy বা API gateway-এ route দুটি block করাই প্রকাশিত workaround।

পর্যবেক্ষিত compromise-এর সঙ্গে CVE-2026-42271 এবং CVE-2026-48710-কে যুক্ত করা হয়েছে। দ্বিতীয় ত্রুটিটি আক্রান্ত configuration-এ Starlette host-header validation এড়িয়ে authentication boundary দুর্বল করতে পারে, ফলে প্রথম ত্রুটির command-execution capability বৈধ credential ছাড়াও নাগালে আসতে পারে। তবে সব deployment-এ এই unauthenticated chain কার্যকর ছিল বা এই নির্দিষ্ট chain-ই ঘটনার প্রথম প্রবেশপথ—কোনোটিই চূড়ান্তভাবে প্রমাণিত নয়।

কোন secret ও database record চুরি হয়েছে

প্রথম পর্যায়ে payload gateway process-এর environment পড়েছে। Containerized deployment-এ LiteLLM যদি PID 1 হিসেবে চলে, /proc/1/environ থেকে তার environment variable পাওয়া যায়। পর্যবেক্ষিত code সেখানে master key, API key, token, password ও UI-সংক্রান্ত শব্দ খুঁজে provider credential, LiteLLM master key, database URL, UI credential এবং অন্য secret-like value আলাদা করেছে।

সংগৃহীত তথ্য attacker-controlled infrastructure-এ পাঠাতে Python urllib, curl ও wget—একাধিক বিকল্প রাখা হয়েছিল। একটি outbound পদ্ধতি অনুপস্থিত বা blocked হলেও অন্যটি ব্যবহার করার এই ব্যবস্থা exfiltration-কে আরও সহনশীল করেছে।

চুরি environment variable-এ থামেনি। সংগৃহীত DATABASE_URL ব্যবহার করে Azure Database for PostgreSQL-এ সংযোগ দেওয়া হয় এবং LiteLLM_ProxyModelTable ও LiteLLM_VerificationToken থেকে record নেওয়া হয়। এসব record-এ upstream provider key material, provider endpoint, model configuration ও LiteLLM-এর জারি করা virtual key থাকতে পারে; output base64-এ encode করে ছোট অংশে callback endpoint-এ পাঠানো হয়েছিল।

Security Risk Advisors-এর সাম্প্রতিক threat summary একই ঘটনার সীমা পুনরায় তুলে ধরেছে: LiteLLM থেকে provider API key, master key, connection string ও virtual-key record সংগ্রহের পর XMRig deployment এবং SSH ও cron-ভিত্তিক persistence দেখা গেছে। এটি LiteLLM-এর আলাদা supply-chain ঘটনার বিবরণ নয়; Microsoft-এর পর্যবেক্ষিত LiteLLM, RAGFlow ও Kestra compromise-এর সারসংক্ষেপ।

Version, exposure ও secret rotation-এর অগ্রাধিকার

LiteLLM operator-এর প্রথমে চলমান package version এবং gateway-এর public reachability—দুটিই যাচাই করা প্রয়োজন। Version 1.74.2 বা তার পরের, কিন্তু 1.83.7-এর আগের হলে 1.83.7 কিংবা আরও নতুন supported release-এ upgrade করতে হবে। শুধু endpoint login-এর আড়ালে আছে ধরে নিরাপদ ভাবা যাবে না, কারণ ঝুঁকিপূর্ণ release-এ low-privilege বৈধ key-ই command execution-এর পূর্বশর্ত পূরণ করত।

1. Exposure থামানো: internet-facing gateway ও management route trusted network, VPN বা কঠোর authenticated management path-এর পেছনে নিতে হবে। সন্দেহজনক host-এর অপ্রয়োজনীয় outbound যোগাযোগ সীমিত করলে আরও exfiltration ও payload download ঠেকানো যায়।
2. প্রমাণ সংরক্ষণ: restart বা rebuild-এর আগে process tree, container ও host log, network connection, temporary artifact, cron এবং authorized_keys-এর অবস্থা সংরক্ষণ করা প্রয়োজন। Gateway process থেকে shell, Python, curl বা wget চালুর ঘটনা বিশেষভাবে গুরুত্বপূর্ণ সংকেত।
3. সব সংশ্লিষ্ট secret ঘোরানো: শুধু LiteLLM master key বদলানো যথেষ্ট নয়। Model-provider API key, virtual key, database credential, UI credential, token এবং একই environment বা database-এ থাকা password revoke করে নতুন করে দিতে হবে। Provider account-এ অস্বাভাবিক model invocation ও ব্যয়ও পরীক্ষা করা দরকার।
4. Persistence সরানো: service account-এর authorized_keys, অপরিচিত cron entry, daemon-সদৃশ নামে চলা binary, hidden temporary file এবং immutable file attribute পরীক্ষা করতে হবে। Compromise নিশ্চিত হলে পরিচ্ছন্ন image থেকে rebuild কেবল দৃশ্যমান process বন্ধ করার চেয়ে নির্ভরযোগ্য।
5. Database scope নির্ধারণ: model ও verification-token table-এর কোন record পড়া হয়েছে তা audit করে সংশ্লিষ্ট downstream credential-কে exposed হিসেবে ধরতে হবে।

খোলা AI control plane কেন এমন বড় লক্ষ্য

LiteLLM শুধু request forwarder নয়; অনেক deployment-এ এটি application, tenant এবং একাধিক model provider-এর মধ্যবর্তী control point। একই runtime provider credential, routing rule, virtual key ও database access ধারণ বা উদ্ধার করতে পারে। তাই gateway process-এ command execution পাওয়া মানে একটি application container দখলের চেয়েও বিস্তৃত সুযোগ—এক জায়গা থেকে downstream AI account ব্যবহার, database collection, host persistence ও compute theft সম্ভব হয়।

RAGFlow ও Kestra compromise-এ প্রবেশপথ আলাদা ছিল, কিন্তু control-plane ঝুঁকির একই ধরন দেখা গেছে। RAGFlow-এ application startup path বদলে TenantLLM configuration flow-তে hook বসানো হয়েছিল, যাতে পরে যোগ করা provider credential ধরা যায়। Kestra-তে workflow-origin shell execution ও mounted Docker socket ব্যবহার করে container environment দেখা, data সংগ্রহ এবং miner চালানোর কার্যকলাপ পাওয়া গেছে।

এখন পর্যন্ত LiteLLM ঘটনার post-exploitation ধাপ, চুরি হওয়া secret-এর শ্রেণি এবং persistence artifact প্রকাশিত হয়েছে। কিন্তু victim-এর পরিচয়, মোট কত deployment আক্রান্ত, প্রথম compromise-এর সময় এবং কোন vulnerability request নিশ্চিতভাবে initial access দিয়েছে—এসব প্রকাশ করা হয়নি। ফলে শুধু version check দিয়ে ঝুঁকি নির্ধারণ করা যাবে না; public exposure ও compromise indicator মিললে gateway-সংলগ্ন credential ইতিমধ্যে ফাঁস হয়েছে ধরে containment করাই নিরাপদ অবস্থান।