Gitea-র ৯.৮ মাত্রার ত্রুটি সক্রিয় হামলায়—1.27.1-এর নিচে ঝুঁকি

২৫ আগস্ট ২০২৬-এ Gitea-র গুরুতর code-injection ত্রুটি CVE-2026-60004 সক্রিয় হামলায় ব্যবহৃত vulnerability হিসেবে চিহ্নিত হয়। ওই দিন CISA ত্রুটিটি Known Exploited Vulnerabilities বা KEV তালিকায় যোগ করেছে এবং কানাডার Cyber Centre সতর্কতা 1.27.1-এর আগের installation হালনাগাদের নির্দেশ দিয়েছে।

প্রকল্পের নির্দিষ্ট affected range Gitea 1.17 থেকে 1.27.0; সংশোধন রয়েছে 1.27.1-এ। ২৭ আগস্ট প্রকাশিত CERT Santé-এর নথি CVSS v3.1 score ৯.৮, সক্রিয় exploitation, affected range এবং fixed version—চারটিই নিশ্চিত করেছে।

কোন configuration-এ credential ছাড়াই হামলা সম্ভব

শুধু আক্রান্ত version থাকলেই exploit সফল হবে না; কয়েকটি runtime শর্ত একসঙ্গে পূরণ হতে হয়। Gitea প্রকল্পের security advisory অনুযায়ী সাধারণ repository write access, Git 2.32 বা নতুন সংস্করণ, সক্রিয় diffpatch route এবং writable ও executable temporary filesystem প্রয়োজন।

Open registration চালু থাকলে আগে থেকে account নেই এমন visitor স্বাভাবিক account ও repository তৈরি করে প্রয়োজনীয় write access পেতে পারে। এই অবস্থায় প্রাথমিক HTTP request authentication ছাড়া শুরু হলেও exploit chain-এর মধ্যে account registration থাকে। তাই open registration-কে vulnerability-টির কারণ না বলে credential-বিহীন প্রবেশপথের শর্ত বলা বেশি নির্ভুল।

Registration বন্ধ থাকলে ওই নির্দিষ্ট পথটি আটকে যায়, কিন্তু ত্রুটি নিষ্ক্রিয় হয় না। বৈধ writer account, চুরি হওয়া credential বা অতিরিক্ত permission পাওয়া কোনো account আক্রান্ত repository-তে patch পাঠাতে পারলে ঝুঁকি থেকে যায়। Custom build বা backported package ব্যবহারকারীদের version label-এর বদলে সংশ্লিষ্ট fix অন্তর্ভুক্ত হয়েছে কি না যাচাই করতে হবে।

diffpatch কীভাবে Gitea service account-এ command চালায়

diffpatch API repository-নিয়ন্ত্রিত patch একটি shared bare temporary clone-এ প্রয়োগ করে। একই crafted patch দুবার পাঠালে add/add collision তৈরি হতে পারে; Git-এর three-way fallback indexed path disk-এ লিখে দেয়। Bare clone-এ repository root-ই $GIT_DIR, ফলে executable hooks/post-index-change file একটি সক্রিয় Git hook হয়ে উঠতে পারে।

Git index লেখার সময় hook-টি চলে এবং command Gitea OS service account-এর অধিকার পায়। এটি web interface-এর মধ্যে সীমাবদ্ধ কোনো ত্রুটি নয়: process যে file, mount, environment variable, database বা network service ব্যবহার করতে পারে, সফল আক্রমণকারীও deployment-এর permission অনুযায়ী সেগুলোর নাগাল পেতে পারে।

সম্ভাব্য exposure-এর মধ্যে app.ini, application ও process-environment secret, mounted repository, database credential ও content, OAuth token এবং integration credential রয়েছে। প্রকৃত ক্ষতির পরিধি নির্ভর করবে Gitea process-এর privilege, container বা host isolation, mounted volume এবং outbound network access-এর ওপর।

পাঁচ ধাপের প্রতিরক্ষা decision tree

Upgrade জরুরি, তবে সক্রিয় exploitation-এর প্রেক্ষাপটে সেটিই response-এর শেষ ধাপ নয়। প্রশাসকের সিদ্ধান্তক্রম version, প্রবেশপথ, exploit-এর runtime শর্ত এবং সম্ভাব্য secret exposure আলাদা করে দেখা উচিত।

1. চলমান version নির্ধারণ করুন: binary, package বা container image থেকে প্রকৃত runtime version দেখুন। 1.17–1.27.0 হলে 1.27.1 বা পরবর্তী supported release-এ upgrade করুন; load balancer-এর পেছনের node, replica ও standby instance-ও একই পরীক্ষার মধ্যে রাখুন।
2. Registration path যাচাই করুন: public signup ও account তৈরির অন্য উন্মুক্ত পথ আছে কি না দেখুন। তদন্ত চলাকালে অপ্রয়োজনীয় registration বন্ধ করা নতুন credential-বিহীন প্রবেশ কমায়, কিন্তু existing writer account-এর ঝুঁকি দূর করে না।
3. diffpatch activity পরীক্ষা করুন: route-টি reachable ছিল কি না নির্ধারণ করুন। Patch হওয়ার আগের সময়ে অস্বাভাবিক diffpatch request, নতুন account, নতুন repository এবং অপ্রত্যাশিত branch বা ref-এর সময়রেখা মিলিয়ে দেখুন।
4. Filesystem ও isolation মূল্যায়ন করুন: temporary directory একই সঙ্গে writable ও executable ছিল কি না, service account কোন volume পড়তে পারত এবং container host resource বা socket পেত কি না যাচাই করুন। সন্দেহজনক process বা hook পেলে workload isolate করে volatile ও persistent evidence সংরক্ষণ করুন।
5. Credential rotation-এর সীমা স্থির করুন: exploitation-এর প্রমাণ বা জোরালো সন্দেহ থাকলে application secret, database credential, OAuth ও integration token, deploy key এবং process environment-এ থাকা secret পরিবর্তন করুন। আক্রান্ত workload isolate ও evidence সংগ্রহের পর clean environment থেকে rotation করলে নতুন credential আবার পুরোনো process-এর সামনে প্রকাশ পাওয়ার ঝুঁকি কমে।

Patch দেওয়ার পরেও compromise assessment কেন দরকার

নতুন version ভবিষ্যতের exploit বন্ধ করে; patch-এর আগে চালানো command, বদলে দেওয়া data বা কপি হয়ে যাওয়া secret ফিরিয়ে নেয় না। তাই upgrade সম্পন্ন হওয়ার পর পুরোনো instance সরাসরি production-এ রেখে কেবল version check-কে incident closure ধরা যথেষ্ট নয়।

Account ও repository creation, diffpatch request, Git ref পরিবর্তন, Gitea service user-এর child process, অস্বাভাবিক CPU ব্যবহার, downloaded file এবং outbound connection একই সময়রেখায় পর্যালোচনা করা দরকার। কোনো একটি indicator অনুপস্থিত থাকা compromise না হওয়ার প্রমাণ নয়, কারণ exploit-এর command ও attacker-এর পরবর্তী পদক্ষেপ deployment ভেদে আলাদা হতে পারে।

Containerized installation ক্ষতির পরিধি কমাতে পারে, কিন্তু container নিজেই নিশ্চিত নিরাপত্তাসীমা নয়। Privileged mode, host mount, container socket, shared secret বা unrestricted egress থাকলে service account-এর command execution থেকে প্রভাব অন্য workload বা infrastructure-এ ছড়াতে পারে। Read-only mount, সীমিত database privilege এবং restricted outbound access সম্ভাব্য blast radius কমায়, তবে upgrade-এর বিকল্প নয়।

যা নিশ্চিত, আর যে তথ্য এখনো প্রকাশিত নয়

নিশ্চিত তথ্য হলো CVSS score ৯.৮, আক্রান্ত project range 1.17–1.27.0, fixed version 1.27.1 এবং ২৫ আগস্টের KEV অন্তর্ভুক্তি। অর্থাৎ শর্ত পূরণ করা vulnerable installation-কে আর কেবল তাত্ত্বিক ঝুঁকি হিসেবে বিবেচনা করা যায় না।

প্রকাশ্য সরকারি সতর্কতায় এখনো কোনো নির্দিষ্ট threat actor, মোট আক্রান্ত প্রতিষ্ঠানের সংখ্যা বা একটি অভিন্ন campaign-এর পূর্ণ বিবরণ নেই। ফলে একটি installation-এর incident scope নির্ধারণ করতে তার নিজস্ব registration অবস্থা, diffpatch exposure, filesystem execution condition, isolation boundary এবং credential history-ই প্রধান প্রমাণ।