شناسه CVE-2026-22444 :CVE
CWE-20 :CWE
yes :Advisory
منتشر شده: ژانویه 21, 2026
به روز شده: ژانویه 21, 2026
امتیاز: 7.1
نوع حمله: Improper input validation

اثر گذاری: Information Disclosure
حوزه: سرورهای اپلیکیشن
برند: Apache Software Foundation
محصول: Apache Solr
وضعیتPublished :CVE
Yes :POC
وضعیت آسیب پذیری: patch شده

چکیده

آسیب‌پذیری با شدت بالا در موتور جستجوی Apache Solr با شناسه CVE-2026-22444 شناسایی شده است. این ضعف که ناشی از اعتبارسنجی ناکافی ورودی در API create core است، باعث می‌شود Solr پیش از اعمال محدودیت‌های امنیتی تعیین‌شده توسط تنظیم allowPaths، وجود مسیرهای فایل‌سیستم غیرمجاز را بررسی کرده و به‌صورت فقط‌خواندنی به آن‌ها دسترسی پیدا کند. در نتیجه، امکان ایجاد هسته با پیکربندی‌های غیرمنتظره فراهم می‌شود و این عملکرد در سیستم‌های ویندوزی با پشتیبانی از مسیرهای شبکه‌ای UNC Path می‌تواند منجر به افشای هش‌های احراز هویت NTLM کاربران شود.

توضیحات

آسیب‌پذیری CVE-2026-22444 در API ایجاد هسته (Create Core API) در Apache Solr نسخه‌های 8.6 تا 9.10.0، ناشی از اعتبارسنجی نادرست ورودی مطابق با CWE-20 است. در این ضعف، برخی پارامترهای ورودی API پیش از اعمال کنترل‌های امنیتی نهایی بررسی می‌شوند؛ به‌گونه‌ای که Solr قبل از اجرای مکانیزم محدودکننده‌ی allowPaths (تنظیم امنیتی تعریف‌شده در فایل پیکربندی solr.xml برای محدودسازی دسترسی به مسیرهای مشخص در فایل‌سیستم)، اقدام به بررسی وجود مسیرها و تلاش برای خواندن آن‌ها به‌صورت فقط‌خواندنی (Read-Only Access) می‌کند.

از منظر فنی، در جریان ایجاد هسته جدید، عملیات‌هایی مانند تبدیل مسیر به مسیر مطلق (instancePath.toAbsolutePath()) ، بررسی وجود فایل یا مسیر (Files.exists()) و باز کردن جریان ورودی فایل (Files.newInputStream()) پیش از اجرای تابع assertPathAllowed() انجام می‌شوند. این ترتیب نادرست در اعتبارسنجی باعث می‌شود مسیرهایی که طبق سیاست امنیتی Solr باید غیرمجاز باشند، پیش از مسدودسازی مورد دسترسی قرار گیرند. در نتیجه، مهاجم می‌تواند با سوءاستفاده از این عملکرد، Solr را وادار کند مسیرهای خارج از محدوده‌ی مجاز تعریف‌شده در allowPaths را بررسی کرده و از آن‌ها برای ایجاد هسته استفاده نماید.

در چنین شرایطی، مهاجم حتی با سطح دسترسی پایین و در صورت دسترسی به API ایجاد هسته، قادر خواهد بود هسته‌های Solr را با استفاده از Configsetهای غیرمنتظره یا غیرمجاز قابل دسترس در فایل‌سیستم ایجاد کند. این مسئله می‌تواند منجر به بارگذاری پیکربندی‌های ناخواسته، تغییر عملکرد موتور جست‌وجو و در برخی سناریوها افشای جزئی اطلاعات حساس مرتبط با ساختار فایل‌سیستم یا تنظیمات داخلی Solr شود.

این آسیب‌پذیری در سیستم‌های ویندوزی اثرگذاری شدیدتری دارد. در محیط‌هایی که استفاده از مسیرهای شبکه‌ای UNC (Universal Naming Convention) مجاز است، عملیات بررسی مسیر پیش از اعتبارسنجی نهایی باعث برقراری ارتباط شبکه‌ای ناخواسته می‌شود. در این وضعیت، سیستم‌عامل ویندوز برای احراز هویت در مسیر شبکه‌ای، اطلاعات NTLM را ارسال می‌کند و در نتیجه هش‌های NTLM کاربران افشا می‌شوند.

بهره‌برداری از این ضعف مستلزم دسترسی به API ایجاد هسته است؛ وضعیتی که معمولاً زمانی رخ می‌دهد که Apache Solr در حالت مستقل (Standalone Mode) اجرا شده باشد و RuleBasedAuthorizationPlugin (پلاگین مجوزدهی مبتنی بر قوانین) غیرفعال باشد یا در صورت فعال بودن، مجوز از پیش تعریف‌شده‌ی core-admin-edit (یا یک مجوز سفارشی معادل آن) به نقش‌هایی با سطح اعتماد پایین، یعنی کاربران غیرمدیریتی، اعطا شده باشد. در چنین سناریویی، مهاجم می‌تواند با ارسال یک درخواست HTTP مخرب به مسیر مدیریتی /admin/cores و دستکاری پارامترهایی مانند path یا configSet، Solr را وادار به انجام عملیات خواندن مسیرهای غیرمجاز نماید.

کد اثبات مفهومی (PoC) عمومی برای این آسیب‌پذیری در مخزن GitHub منتشر شده است که شامل اسکریپت exploit.py و مجموعه‌ای از فایل‌های configset می‌شود. این PoC نشان می‌دهد که چگونه در محیط‌های ویندوزی و در حالت Standalone می‌توان از این ضعف برای افشای هش‌های NTLM و در سناریوهای خاص، در صورت عدم وجود کنترل‌های امنیتی تکمیلی، حتی برای دستیابی به اجرای کد از راه دور (RCE) سوءاستفاده کرد.

پیامدهای اصلی این آسیب‌پذیری شامل نقض جدی محرمانگی (Confidentiality) به دلیل امکان افشای اطلاعات احراز هویت و داده‌های حساس و تأثیر محدود بر یکپارچگی (Integrity) از طریق بارگذاری یا استفاده از پیکربندی‌های ناخواسته است. این ضعف امنیتی با انتشار نسخه 9.10.1 به‌طور کامل پچ شده است.

CVSS

Score	Severity	Version	Vector String
7.1	HIGH	3.1	CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N

لیست محصولات آسیب پذیر

Versions	Product
affected from 8.6 through 9.10.0	Apache Solr

لیست محصولات بروز شده

Versions	Product
9.10.1 or greater	Apache Solr

استفاده محصول در ایران

در این جدول، تعداد صفحات ایندکس‌شده در گوگل با دامنه .ir که Apache Solr را ذکر کرده اند، ثبت شده است. این داده صرفاً برای برآورد تقریبی حضور محصولات در وب ایران استفاده شده و نمایانگر میزان نصب دقیق و استفاده واقعی نیست.

Approx. Usage in .ir Domain via Google (Total Pages)	Search Query (Dork)	Product
9,960	site:.ir “Apache Solr”	Apache Solr

نتیجه گیری

این آسیب‌پذیری با شدت بالا در Apache Solr، امکان افشای اطلاعات حساس (به‌ویژه هش NTLM در ویندوز) و دورزدن محدودیت allowPaths را از طریق API ایجاد هسته در حالت standalone فراهم می‌کند. با توجه به وجود PoC عمومی و انتشار پچ امنیتی رسمی، اجرای فوری اقدامات زیر برای جلوگیری از بهره‌برداری و کاهش ریسک توصیه می‌شود:

به‌روزرسانی فوری: Solr را در اسرع وقت به نسخه 10.1 یا بالاتر به‌روزرسانی کنید. این اقدام مؤثرترین و قطعی‌ترین راهکار برای رفع آسیب‌پذیری است و باید در اولویت قرار گیرد. سایر اقدامات نقش مکمل را دارند و می‌توانند به کاهش ریسک این آسیب پذیری و مقابله با حملات مشابه کمک کنند.
فعال‌سازی RuleBasedAuthorizationPlugin: در صورت غیر فعال بودن این پلاگین، فوراً آن را فعال کنید و لیست مجوزها (Permission List) را به‌گونه‌ای تنظیم نمایید که مجوز core-admin-edit (یا معادل سفارشی آن برای ایجاد و ویرایش هسته) تنها به نقش‌های ادمین اعطا شود. کاربران عادی نباید توانایی ایجاد هسته جدید داشته باشند.
محدودسازی دسترسی API: Endpointهای مدیریتی مانند /admin/cores را پشت احراز هویت قوی (مانند Basic Auth، JWT یا روش مشابه) قرار دهید و از دسترسی مستقیم اینترنت به آن‌ها جلوگیری کنید. در صورت امکان، دسترسی را به شبکه‌های داخلی یا VPN محدود نمایید.
غیرفعال کردن UNC paths در ویندوز: اگر Solr روی ویندوز اجرا می‌شود، پشتیبانی از مسیرهای UNC را در سطح سیستم‌عامل یا JVM غیرفعال کنید تا از افشای هش‌های NTLM جلوگیری شود.
نظارت و ثبت لاگ: لاگ‌های Solr را برای درخواست‌های create core و مسیرهای مشکوک (مانند \ یا مسیرهای خارج از allowPaths) نظارت کنید و از ابزارهای SIEM برای تشخیص تلاش‌های بهره‌برداری استفاده نمایید.
تست امنیتی: پس از به‌روزرسانی، اپلیکیشن را با ابزارهایی مانند Burp Suite یا OWASP ZAP اسکن کنید و سناریوهای ایجاد هسته با مسیرهای مخرب را ارزیابی نمایید؛ همچنین از Fuzzing روی پارامترهای API بهره ببرید.
آموزش و بازبینی پیکربندی: تیم‌های DevOps و امنیتی را نسبت به ریسک‌های فعال بودن APIهای مدیریتی بدون مجوز مناسب و اهمیت allowPaths آموزش دهید و پیکربندی‌های فعلی را بازبینی کنید.

اجرای این اقدامات، به ویژه به‌روزرسانی نسخه‌ها و تقویت کنترل دسترسی، ریسک بهره‌برداری را به‌طور چشمگیری کاهش می‌دهد و امنیت استقرارهای Apache Solr را به‌طور قابل‌توجهی بهبود می‌بخشد.

امکان استفاده در تاکتیک های Mitre Attack (در زمان اجرای حمله)

Initial Access (TA0001)
مهاجم با استفاده از یک حساب کاربری معتبر و دارای سطح دسترسی پایین (Low Privilege) که به API create core در Solr دسترسی دارد، وارد سامانه می‌شود. شرط کلیدی در این مرحله، پیکربندی نادرست کنترل‌های دسترسی Solr است، به‌طوری که یا پلاگین RuleBasedAuthorizationPlugin غیرفعال باشد، یا مجوز core-admin-edit به کاربران غیرادمین اعطا شده باشد. این امر به مهاجم اجازه می‌دهد بدون نیاز به دسترسی ادمین، درخواست‌های مخرب خود را به اندپوینت حساس ارسال کند.

Discovery (TA0007)
پس از دسترسی اولیه، مهاجم با ارسال درخواست‌های متوالی به API آسیب‌پذیر و آزمایش پارامترهای مختلف مسیر، می‌تواند ساختار فایل سیستم سرور را کاوش کند. این کار به او امکان می‌دهد مکان فایل‌های پیکربندی حساس، داده‌های برنامه یا دیگر دارایی‌های اطلاعاتی موجود در مسیرهایی که توسط allowPaths محدود شده‌اند را کشف نماید. موفقیت این مرحله وابسته به وجود تنظیمات allowPath و آسیب‌پذیر بودن منطق اعتبارسنجی است که به مهاجم اجازه می‌دهد به‌تدریج نقشه‌ای از مسیرهای قابل دسترسی و غیرمجاز ایجاد کند.

Collection (TA0009)
با شناسایی مسیرهای حاوی اطلاعات ارزشمند، مهاجم می‌تواند از همان مکانیزم API create core برای درخواست خواندن محتوای این فایل‌ها استفاده کند. در این حالت، آسیب‌پذیری به عنوان یک کانال برای جمع‌آوری داده‌های محرمانه عمل می‌نماید. همچنین، در یک حمله پیشرفته‌تر روی سیستم‌های ویندوزی، مهاجم می‌تواند با تزریق یک مسیر UNC که به یک سرور SMB تحت کنترل خود اشاره می‌کند، سیستم Solr را وادار به آغاز احراز هویت NTLM نماید. این عمل منجر به افشای هش‌های احراز هویت کاربر (در سطح سیستم یا سرویس) می‌شود که مهاجم می‌تواند آن‌ها را برای عملیات بعدی مانند شکستن رمز یا حمله Relay جمع‌آوری کند.

Impact (TA0040)
بهره‌برداری موفق از این آسیب‌پذیری عمدتاً بر محرمانگی (Confidentiality) سیستم تأثیر می‌گذارد. یک مهاجم می‌تواند با دور زدن کنترل‌های امنیتی طراحی‌شده، به اطلاعات حساسی دست یابد که نباید در دسترس او قرار می‌گرفت. این اطلاعات می‌تواند شامل فایل‌های پیکربندی داخلی برنامه، داده‌های لاگ حاوی جزئیات فنی، یا حتی (در بدترین حالت در محیط ویندوز) هش‌های رمزعبور سیستمی باشد. افشای چنین اطلاعاتی نه‌تنها حریم خصوصی و امنیت داده‌های ذخیره‌شده در پلتفرم جستجو را نقض می‌کند، بلکه می‌تواند به عنوان پایه‌ای برای حملات گسترده‌تر و عمیق‌تر علیه زیرساخت سازمان مورد استفاده قرار گیرد و منجر به خسارات جدی اعتباری و مالی شود.

منابع

گزارش اثبات آسیب‌پذیری CVE-2026-22444

اطلاعات آسیب‌پذیری

عنوان: اعتبارسنجی ناکافی ورودی در API ایجاد هسته Apache Solr امکان دسترسی به مسیرهای محدودشده و افشای اطلاعات را فراهم می‌کند.

شناسه: CVE-2026-22444

وضعیت مشاوره: Advisory / Patch Available

نمره CVSS تقریبی: CVSS v3.1: 7.1 (High)

محصول / نسخه‌های آسیب‌پذیر: Apache Solr (حالت مستقل)

در نسخه‌های زیر (پیش از اعمال وصله امنیتی):
- کلیه نسخه‌های Apache Solr از نسخه ۸.۶ تا نسخه ۹.۱۰.۰.
- این آسیب‌پذیری منحصراً در حالت اجرای مستقل (Standalone Mode) این موتور جستجو تأثیرگذار است و استقرارهای مبتنی بر ابر (SolrCloud) از این آسیب مصون هستند.
- آسیب‌پذیری تنها در صورتی فعال می‌شود که تنظیم امنیتی allowPaths در فایل xml برای محدود کردن دسترسی به فایل‌سیستم پیکربندی شده باشد.

محیط‌های درگیر

سرورهای Apache Solr که در حالت مستقل و عموماً برای اهداف توسعه، آزمایش یا workloadهای سبک‌تر به‌کار گرفته می‌شوند.
محیط‌هایی که از پیکربندی allowPaths برای افزایش امنیت و محدود کردن دامنه دسترسی Solr به فایل‌سیستم میزبان استفاده می‌کنند.
استقرارهایی که کنترل‌های دسترسی مبتنی بر نقش (RBAC) به درستی پیاده‌سازی یا اجرا نشده‌اند و Endpoint مدیریتی ایجاد هسته در معرض کاربران با سطح دسترسی پایین قرار دارد.
سیستم‌های ویندوزی که Solr بر روی آن‌ها نصب شده و پشتیبانی از مسیرهای شبکه‌ای (UNC Paths) فعال است.
محیط‌های چندکاربره یا سرویس‌هایی که یک نمونه Solr بین چندین تیم یا پروژه به اشتراک گذاشته شده است.

کامپوننت‌های آسیب‌پذیر

API مدیریتی ایجاد هسته (Core Admin Create Core API) که از طریق Endpoint /admin/cores در دسترس است.
منطق اعتبارسنجی ورودی برای پارامترهای مرتبط با مسیر (مانند instanceDir، configSet) در طول فرآیند ایجاد هسته جدید.
تابع assertPathAllowed() که مسئول اعمال محدودیت‌های تعریف‌شده در allowPaths است. آسیب‌پذیری ناشی از فراخوانی دیرهنگام این تابع پس از انجام برخی عملیات بررسی فایل‌سیستم است.

ریشه مشکل (Root Cause Analysis)

ریشه این آسیب‌پذیری در یک نقص طراحی توالی و اعتبارسنجی (Sequential Logic & Validation Flaw) در جریان پردازش درخواست ایجاد هسته نهفته است. در کد آسیب‌پذیر، عملیات‌های حساس فایل‌سیستمی مانند تبدیل مسیر به فرمت مطلق (toAbsolutePath())، بررسی وجود فایل (Files.exists()) و حتی تلاش برای باز کردن جریان خواندن از فایل (Files.newInputStream()) پیش از اعمال نهایی کنترل امنیتی allowPaths انجام می‌شوند. این ترتیب نادرست، اصل “اعتماد نکن، اعتبارسنجی کن” (Never Trust, Always Verify) و رویکرد “Fail-Secure” را نقض می‌کند. در نتیجه، مهاجم می‌تواند با ارائه یک مسیر مخرب در پارامترهای درخواست، سیستم را وادار کند تا پیش از مسدود شدن توسط allowPaths، به مسیرهای خارج از محدوده مجاز دسترسی خواندنی پیدا کند. این طراحی اشتباه مرز امنیتی تعریف‌شده توسط مدیر سیستم را تضعیف نموده و مسیری برای نشت اطلاعات فراهم می‌آورد.

بخش آسیب‌پذیر

رفتار نا امن سیستم:

انجام عملیات بررسی و دسترسی اولیه خواندنی به مسیرهای فایل‌سیستم مشخص شده در پارامترهای ورودی API ایجاد هسته، پیش از اعمال کنترل نهایی امنیتی مبتنی بر لیست سفید مسیرهای مجاز (allowPaths). این رفتار، هدف از تعریف allowPaths که ایزوله کردن Solr از بخش‌های غیرضروری فایل‌سیستم است را خنثی می‌کند.

نحوه سوءاستفاده مهاجم:

مهاجمی که دارای دسترسی اولیه (معمولاً با سطح پایین) به API مدیریتی Solr است، اقدامات زیر را انجام می‌دهد:

مهاجم یک درخواست HTTP POST به Endpoint /admin/cores ارسال می‌کند و عمل action=create را مشخص می‌نماید.
در بدنه درخواست، مقادیر پارامترهایی مانند name (برای نام هسته جدید)، instanceDir یا configSet را به گونه‌ای دستکاری می‌کند که به یک مسیر خارج از محدوده تعریف‌شده در allowPaths اشاره کند. این مسیر می‌تواند به یک فایل پیکربندی حساس، دایرکتوری لاگ یا در محیط ویندوز، به یک مسیر شبکه‌ای UNC (مثلاً \ATTACKER-IP\share) اشاره داشته باشد.
سرور Solr، پیش از رد درخواست توسط مکانیزم allowPaths، عملیات اولیه روی مسیر را انجام می‌دهد. در مورد مسیرهای UNC در ویندوز، این عمل منجر به آغاز پروتکل احراز هویت NTLM از سوی سرور Solr به سمت سرور تحت کنترل مهاجم می‌شود و هش NTLM حساب سرویس Solr افشا می‌گردد.
در برخی سناریوها، اگر مسیر مورد نظر حاوی یک مجموعه پیکربندی (configSet) معتبر Solr باشد، ممکناست هسته جدیدی با استفاده از آن پیکربندی غیرمجاز ایجاد شود که می‌تواند رفتار موتور جستجو را تغییر دهد.

نقش این آسیب‌پذیری در زنجیره حمله

این آسیب‌پذیری عمدتاً در فاز “اکتشاف” (Discovery – TA0007) و “جمع‌آوری” (Collection – TA0009) چارچوب MITRE ATT&CK مورد استفاده قرار می‌گیرد. یک مهاجم داخلی یا خارجی که دسترسی اولیه محدودی به Solr دارد، می‌تواند از این آسیب‌پذیری به عنوان یک “اسکنر مجاز” برای نقشه‌برداری از فایل‌سیستم سرور، شناسایی فایل‌های پیکربندی حساس یا حتی استخراج اعتبارنامه‌های سیستم (در ویندوز) استفاده کند. اطلاعات به دست آمده می‌تواند برای برنامه‌ریزی حملات بعدی با هدف افزایش سطح دسترسی (Privilege Escalation) یا حرکت جانبی (Lateral Movement) در شبکه مورد استفاده قرار گیرد. در بدترین حالت، افشای هش NTLM می‌تواند به مهاجم اجازه دهد تا با استفاده از تکنیک‌هایی مانند عبور دادن هش (Pass-the-Hash)، خود را به عنوان حساب سرویس Solر در دیگر سیستم‌های شبکه جا بزند.

پیش‌نیازهای بهره‌برداری (Prerequisites)

وجود یک نمونه Apache Solr در نسخه‌های آسیب‌پذیر (۸.۶ تا ۹.۱۰.۰) که در حالت مستقل (Standalone) اجرا شود.
پیکربندی و فعال بودن تنظیم امنیتی allowPaths در فایل xml.
دسترسی مهاجم به API ایجاد هسته (/admin/cores). این دسترسی معمولاً در یکی از دو حالت زیر فراهم است:
- غیرفعال بودن پلاگین RuleBasedAuthorizationPlugin (کنترل دسترسی مبتنی بر نقش).
- فعال بودن این پلاگین، اما اعطای مجوز core-admin-edit به نقش‌ها یا کاربرانی که سطح اعتماد پایینی دارند.
برای سناریوی افشای NTLM در ویندوز، باید امکان دسترسی به مسیرهای UNC از طرف سرور Solr وجود داشته باشد و مهاجم کنترل یک سرور SMB (مانند یک ابزار مانند Responder یا Metasploit) را در شبکه در دست داشته باشد.

رفتار مورد انتظار در حالت امن (Expected Secure Behavior)

در یک پیاده‌سازی امن، تمامی فرآیندهای مرتبط با اعتبارسنجی ورودی‌های کاربر که به منابع سیستمی مانند فایل‌سیستم دسترسی دارند، باید از اصل اعتبارسنجی زودهنگام و جامع پیروی کنند. رفتار ایده‌آل شامل موارد زیر است:

اعتبارسنجی اولویت‌دار: اولین قدم در پردازش هر پارامتر ورودی مرتبط با مسیر، اعمال کنترل امنیتی allowPaths باید باشد. هیچ عملیات فایل‌سیستمی (حتی بررسی وجود) نباید قبل از تأیید مجاز بودن مسیر انجام شود.
خطای امن پیش‌فرض (Fail-Secure): در صورت عدم تطابق مسیر با allowPaths، درخواست باید بلافاصله و بدون انجام هیچ عمل جانبی رد شده و یک خطای امنیتی عمومی به کاربر بازگردانده شود.
جداسازی منطق تجاری و امنیتی: منطق بررسی مجوزهای دسترسی به فایل‌سیستم باید در یک لایه یکپارچه و متمرکز کپسوله شده و توسط کلیه بخش‌های کد که نیاز به چنین دسترسی‌ای دارند، فراخوانی شود.
کنترل دقیق دسترسی به APIهای مدیریتی:Endpointهایی که امکان ایجاد، تغییر یا حذف منابع حیاتی مانند هسته‌های جستجو را می‌دهند، باید توسط مکانیزم‌های احراز هویت و کنترل دسترسی قوی محافظت شوند و دسترسی به آن‌ها تنها به مدیران سیستم محدود گردد.
غیرفعال‌سازی قابلیت‌های خطرناک در صورت عدم نیاز: در محیط‌های ویندوزی که نیازی به دسترسی به اشتراک‌های شبکه از طریق Solr نیست، پشتیبانی از مسیرهای UNC باید در سطح JVM یا سیستم عامل غیرفعال شود تا بردار حمله مربوطه کاملاً حذف گردد.

راهکارها و کاهش ریسک (Mitigation / Patch Guidance)

اقدامات فوری برای کاهش ریسک

به‌روزرسانی فوری تمامی نمونه‌های Apache Solr به آخرین نسخه پایدار که این آسیب‌پذیری در آن رفع شده است (نسخه ۹.۱۰.۱ یا بالاتر). این اقدام اساسی‌ترین راه حل برای اصلاح منطق معیوب اعتبارسنجی است.
بازبینی فوری مجوزهای دسترسی در پلاگین RuleBasedAuthorizationPlugin. اطمینان حاصل کنید که مجوز core-admin-edit (یا هر مجوز سفارشی مشابه) منحصراً به نقش‌های مدیریتی معتبر اختصاص یافته و از دسترس کاربران عادی یا سرویس‌های با امتیاز پایین خارج است.
در سیستم‌های ویندوزی که مورد هدف این آسیب‌پذیری قرار گرفته‌اند، بلافاصله کلیه رمزهای عبور حساب‌هایی که هش NTLM آن‌ها ممکن است افشا شده باشد (به ویژه حساب سرویس اجراکننده Solr) را تغییر دهید.

اقدامات کوتاه‌مدت / میان‌مدت برای کاهش ریسک

در صورتی که به‌روزرسانی فوری ممکن نیست، به عنوان یک کنترل جبرانی موقت، دسترسی شبکه به Endpoint مدیریتی /admin/cores را محدود کنید. این کار می‌تواند از طریق فایروال برنامه (WAF)، قوانین فایروال میزبان یا محدود کردن آدرس‌های IP مجاز برای اتصال به پورت Solr انجام شود.
فعال‌سازی و پیکربندی دقیق RuleBasedAuthorizationPlugin در صورت غیرفعال بودن آن. یک سیاست دسترسی حداقلی تعریف کنید که فقط مدیران سیستم بتوانند هسته ایجاد یا تغییر دهند.
مرور و تقویت تنظیمات allowPaths در فایل xml. اطمینان حاصل کنید که این تنظیمات تنها به دایرکتوری‌های کاملاً ضروری برای عملکرد Solr اجازه دسترسی می‌دهند و مسیرهای حساس سیستم عامل در لیست مجاز قرار ندارند.
غیرفعال‌سازی پشتیبانی از مسیرهای UNC در سرورهای ویندوزی که نیازی به آن ندارند. این کار را می‌توان با تنظیمات رجیستری یا با محدود کردن دسترسی شبکه سرویس Solr انجام داد.

اقدامات بلندمدت برای کاهش ریسک

اجرای یک چارچوب امنیتی یکپارچه برای مدیریت هویت و دسترسی (IAM) در سطح سازمان و یکپارچه‌سازی Apache Solr با این چارچوب. این امر مدیریت متمرکز کاربران، نقش‌ها و مجوزها را ممکن می‌سازد.
گنجاندن بازبینی امنیتی کد (Security Code Review) و تست نفوذ دوره‌ای (Penetration Testing) بر روی استقرارهای حیاتی مانند موتورهای جستجو. این تست‌ها باید سناریوهای سوءاستفاده از APIهای مدیریتی و دور زدن کنترل‌های دسترسی را پوشش دهند.
آموزش تیم‌های توسعه و عملیات در مورد اصول امنیتی طراحی و پیکربندی نرم‌افزارهایی مانند Solr. تأکید ویژه بر اهمیت کنترل دسترسی دقیق، اعتبارسنجی ورودی و مدیریت پیکربندی امن باشد.
پیاده‌سازی و نگهداری یک خط لوله به‌روزرسانی نرم‌افزار (Patch Management Pipeline) که امکان اعمال سریع وصله‌های امنیتی بر روی نرم‌افزارهای حیاتی مانند Solr را در یک چارچوب زمانی تعریف‌شده و تست شده فراهم می‌کند.

تشخیص و مانیتورینگ (Detection & Monitoring)

نشانه‌های تلاش برای سوءاستفاده

نشانه‌های زیر می‌توانند بیانگر تلاش برای بهره‌برداری از آسیب‌پذیری موردنظر باشند و لازم است به‌صورت مستمر پایش شوند:

درخواست‌های HTTP POST غیرمعمول به Endpoint /admin/cores از آدرس‌های IP غیرمعمول یا کاربرانی با نقش غیرمدیریتی.
مشاهده پارامترهای instanceDir یا configSet در لاگ‌های Solr که حاوی مسیرهایی خارج از دایرکتوری‌های معمول Solr (مانند /etc/، /windows/، C:\Windows\System32\ یا مسیرهای شبکه‌ای با فرمت \\) هستند.
ایجاد هسته‌های جدید با نام‌های عجیب یا نامتعارف، به ویژه اگر این هسته‌ها به سرعت پس از ایجاد حذف شوند (ممکن است نشانه تست مهاجم باشد).
در سیستم‌های ویندوزی، هشدارها یا رویدادهای مربوط به تلاش‌های احراز هویت NTLM ناموفق یا خروجی از سرویس Solr به سمت آدرس‌های IP داخلی یا خارجی غیرمعمول در لاگ‌های امنیتی ویندوز (Event Viewer) یا ابزارهای تشخیص نفوذ شبکه.
افزایش تعداد خطاهای Permission denied یا Path not allowed در لاگ‌های Solr که ممکن است نشان‌دهنده تلاش‌های متعدد مهاجم برای تست مسیرهای مختلف باشد.

منابع پیشنهادی برای مانیتورینگ و پایش

به‌منظور تشخیص به‌موقع و مؤثر تلاش‌های سوءاستفاده، پایش منابع زیر توصیه می‌شود:

لاگ‌های دسترسی و خطای Apache Solr: این لاگ‌ها باید در سطح INFO یا DEBUG برای ماژول‌های مربوط به مدیریت هسته (core) پیکربندی شوند تا جزئیات درخواست‌های ایجاد هسته ثبت گردد.
لاگ‌های امنیتی سیستم عامل میزبان: در ویندوز، مانیتورینگ Event ID 4625 (شکست در ورود) و 4648 (ورود با استفاده از اعتبارنامه‌های صریح) می‌تواند تلاش‌های احراز هویت NTLM مشکوک را نشان دهد. در لینوکس، لاگ‌های auditd می‌توانند دسترسی به فایل‌ها توسط پروسه java (فرآیند Solr) را ردیابی کنند.
ترافیک شبکه: استفاده از سیستم تشخیص نفوذ شبکه (NIDS) مانند Zeek یا Suricata برای شناسایی ترافیک SMB/NTLM خروجی غیرعادی از سرور Solr.
ابزارهای مانیتورینگ عملکرد برنامه (APM) یا SIEM: تجمیع و همبستگی لاگ‌های Solr، سیستم عامل و شبکه در یک پلتفرم مرکزی برای ایجاد هشدار بر اساس الگوهای چندلایه (مانند درخواست ایجاد هسته مشکوک به دنبال آن ترافیک SMB خروجی).
اسکن‌های دوره‌ای پیکربندی: استفاده از ابزارهای اتوماسیون برای بررسی دوره‌ای تنظیمات xml و security.json و اطمینان از عدم تغییر غیرمجاز مجوزها یا تنظیمات allowPaths.

واکنش به حادثه (Incident Response)

اقدامات اضطراری که در صورت مشاهده نشانه‌های نفوذ یا سوءاستفاده موفق باید اتخاذ شود:

قطع دسترسی و جداسازی: بلافاصله دسترسی شبکه به نمونه Solr آسیب‌دیده (یا کل سرور میزبان در صورت لزوم) را از شبکه تولیدی قطع کنید تا از گسترش احتمالی حمله جلوگیری شود. در صورت شناسایی یک هسته مخرب ایجاد شده، آن را غیرفعال (unload) یا حذف کنید.
حفظ شواهد دیجیتال: از کلیه لاگ‌های Solr، پیکربندی‌ها، تاریخچه فرمان‌های اجرا شده و در صورت امکان، یک ایمیج از حافظه (memory dump) فرآیند Solr، قبل از هر گونه تغییر، نسخه پشتیبان امن تهیه کنید.
تحلیل و تعیین دامنه: لاگ‌های جمع‌آوری شده را برای تعیین زمان دقیق حمله، آدرس IP منبع، پارامترهای خاص استفاده شده در درخواست‌ها و شناسایی هر گونه داده یا اعتبارنامه افشا شده تحلیل کنید. بررسی کنید که آیا مهاجم از طریق این آسیب‌پذیری به اطلاعات بیشتری دسترسی یافته یا مراحل بعدی حمله را انجام داده است.
پاکسازی و بازیابی: سیستم Solr را با آخرین نسخه وصله‌شده (۹.۱۰.۱ یا بالاتر) از نو نصب و پیکربندی کنید. اگر از SolrCloud استفاده می‌شود، مهاجرت به معماری ابری را به عنوان یک راهکار بلندمدت‌تر برای افزایش امنیت در نظر بگیرید. تمامی اعتبارنامه‌های افشا شده (به ویژه در سناریوی NTLM) را باطل و مجدداً ایجاد کنید.
گزارش‌دهی و بهبود مستمر: یک گزارش جامع از حادثه تهیه کرده و مراحل وقوع، پاسخ و درس‌های آموخته شده را مستند کنید. این گزارش باید به عنوان مبنایی برای بازبینی و تقویت خط‌مشی‌های امنیتی، کنترل‌های دسترسی و فرآیندهای نظارتی مورد استفاده قرار گیرد.

جریان حمله (Attack Flow)

در شکل ۱جریان کلی بهره‌برداری از این آسیب‌پذیری نشان داده شده است.در یک سناریوی حمله معمول، مهاجم که ممکن است یک کاربر داخلی با دسترسی محدود یا یک مهاجم خارجی باشد که از طریق یک آسیب‌پذیری دیگر به API دسترسی یافته، از Endpoint مدیریتی ایجاد هسته برای آزمایش محدودیت‌های امنیتی سیستم استفاده می‌کند. با ارسال درخواست‌های متوالی و دستکاری پارامترهای مسیر، مهاجم به تدریج قادر به شناسایی ساختار فایل‌سیستم سرور و یافتن مسیرهای خارج از محدوده allowPaths می‌شود. در محیط ویندوز، این فرآیند می‌تواند به یک حمله هدفمند برای استخراج هش‌های احراز هویت سیستم تبدیل شود. اطلاعات جمع‌آوری شده از طریق این کانال نشت، اغلب به عنوان سنگ بنایی برای حملات پیشرفته‌تر با اهداف مخرب گسترده‌تر مورد استفاده قرار می‌گیرد.

شکل 1: نمودار توالی جریان حمله منطقی برای CVE-2026-22444

اثبات مفهوم (PoC) — کاملاً غیرمخرب

آزمایشگاه تخصصی Vulnerbyte این آسیب‌پذیری را در یک محیط ایزوله و کنترل‌شده مورد بررسی قرار داده است.کدهای اثبات مفهوم منتشر شده برای این آسیب‌پذیری، که عموماً برای محیط‌های آزمایشگاهی کنترل‌شده طراحی شده‌اند، مکانیزم بهره‌برداری را به وضوح نشان می‌دهند. این PoCها معمولاً شامل یک اسکریپت (مانند Python) هستند که:

به یک نمونه Solr آسیب‌پذیر متصل می‌شود.
یک درخواست ایجاد هسته را با پارامتر configSet یا instanceDir که به یک مسیر آزمایشی خارج از home (مثلاً /etc/passwd در لینوکس یا \\ATTACKER-IP\fake در ویندوز) اشاره می‌کند، شبیه‌سازی می‌نماید.
پاسخ سرور را تحلیل می‌کند. یک خطای خاص یا تغییر در رفتار لاگ‌ها ممکن است نشان‌دهنده موفقیت‌آمیز بودن دسترسی اولیه به مسیر غیرمجاز باشد.
در نسخه ویندوز، PoC ممکن است شامل راه‌اندازی یک سرور SMB ساده برای ضبط و نمایش هش NTLm ارسالی باشد.

این اسکریپت‌ها صرفاً برای اثبات وجود آسیب‌پذیری و افزایش آگاهی امنیتی طراحی شده و فاقد هرگونه کد مخرب برای تخریب داده یا سیستم هستند.

شکل 2: نتیجه اجرای اکسپلویت بر روی این آسیب پذیری

رفع مسئولیت

این گزارش صرفاً با هدف آموزش، تحلیل فنی و ارتقای امنیت سازمانی تهیه شده است. هرگونه استفاده مخرب یا خارج از چارچوب‌های قانونی از محتوای آن ممنوع است. اطلاعات ارائه‌شده بر اساس داده‌های عمومی در زمان تدوین است و مسئولیت نهایی اقدامات بر عهده خواننده می‌باشد.

منابع (References)

Apache Solr

CVE-2026-22444 – Improper Input Validation in Core Creation API Allowing Restricted Path Access

Affects

Apache Solr (standalone mode only)
Versions:
- 8.6 through 9.10.0
Deployments that meet all of the following conditions:
- Solr is running in standalone mode (not SolrCloud).
- The allowPaths setting in solr.xml is used to restrict filesystem access.
- The Core Admin “create core” API is exposed to untrusted or low-privilege users.

Description

CVE-2026-22444 is an input validation vulnerability in the Apache Solr Core Admin “create core” API.

In affected versions, certain parameters accepted by the core creation API are not sufficiently validated against Solr’s allowPaths security setting. As a result, Solr may:

check the existence of filesystem paths that should be disallowed, and
attempt read-only access to those paths.

Although the vulnerability does not allow arbitrary file writes, it can enable users to create Solr cores using unexpected or unintended configsets if those configsets are accessible somewhere on the filesystem.

On Windows systems where UNC paths are permitted, this behavior may additionally trigger outbound authentication attempts that can result in NTLM user hash disclosure.

Attack Vector

Primary Attack Vector:
Remote / Authenticated (Low-Privilege) via Solr Core Admin API

Attack Scenario:

An attacker has access to the Solr Core Admin API with permission to create cores.
The attacker submits a crafted core creation request containing manipulated path-related parameters.
Solr checks and attempts to read filesystem paths that should be restricted by allowPaths.
Solr allows the creation of a core using an unintended or unexpected configset.

Windows-Specific Variant:

If UNC paths are allowed, Solr may attempt to access a remote network path.
This can cause Windows to perform NTLM authentication, potentially exposing NTLM user hashes to a remote server.

Key Characteristics:

No exploit code execution is required.
No write access to arbitrary files is gained.
Exploitation relies on insufficient input validation and authorization controls.
Impact is higher in environments with weak role separation.

Impact

Successful exploitation may allow an attacker to:

bypass intended filesystem access restrictions,
create Solr cores using unintended configuration sets,
access sensitive configuration data indirectly,
disclose NTLM user hashes on Windows systems (in certain configurations).

While this issue does not directly allow arbitrary code execution, it can undermine Solr’s security model and lead to further compromise depending on the deployment environment.

Exploitation Conditions

A Solr deployment is vulnerable only if all of the following apply:

Solr is running in standalone mode.
allowPaths is configured to restrict filesystem access.
The RuleBasedAuthorizationPlugin is:
- disabled, or
- enabled but grants core-admin-edit (or equivalent) permissions to low-trust roles.

Severity & Metrics

Severity: High
Attack Vector: Network
Privileges Required: Low
User Interaction: None

Relevant CWE:

CWE-20 – Improper Input Validation
CWE-284 – Improper Access Control

Patch & Vendor Status

Fixed in Apache Solr 9.10.1 and later
The fix strengthens validation of core creation parameters and enforces allowPaths restrictions more consistently.

Users are strongly advised to upgrade to a patched version.

Mitigation & Remediation

Immediate Remediation

Upgrade Apache Solr to 9.10.1 or newer.
Restart Solr after upgrading.
Review existing cores for unexpected or unauthorized configurations.

Configuration-Based Mitigations

If upgrading is not immediately possible:

Enable the RuleBasedAuthorizationPlugin if it is disabled.
Ensure that the core-admin-edit permission is granted only to trusted administrative roles.
Remove core creation permissions from low-trust or non-admin users.
On Windows systems, restrict or disable UNC path access where possible.

These mitigations reduce exposure but do not fully eliminate the vulnerability without upgrading.

Detection & Monitoring

Indicators to Monitor:

Unexpected core creation events.
Cores using unfamiliar or unintended configsets.
Solr logs showing filesystem access attempts outside intended directories.
On Windows, unexpected outbound authentication attempts.

Recommended Actions:

Enable detailed Solr audit logging.
Review Core Admin API usage regularly.
Monitor filesystem access logs where available.

Post-Incident Response

If exploitation is suspected:

Restrict access to the Core Admin API immediately.
Preserve Solr logs and configuration files.
Identify and remove unauthorized cores.
Upgrade to a fixed version.
Review role permissions and filesystem access controls.

Summary Table

Category	Details
Vulnerability	Improper input validation
Component	Core Admin “create core” API
Attack Vector	Remote, authenticated (low privilege)
Impact	Restricted path access, config misuse, NTLM hash disclosure (Windows)
Affected Versions	Solr 8.6 – 9.10.0
Fixed Version	9.10.1
Severity	High

References

Apache Solr Documentation – allowPaths configuration
Apache Solr RuleBasedAuthorizationPlugin documentation
CVE-2026-22444 advisory

CVE-2026-22444

Apache Solr: Insufficient file-access checking in standalone core-creation requests