چرا در ۲۰ اکتبر ۲۰۲۶ همه کارت‌های Revolut رد شدند؟ توضیح کامل این قطعی

اگر امروز صبح کارت Revolut شما پشت صندوق فروشگاه، در پمپ‌بنزین یا در خودپرداز رد شد، مشکل نه از کارت بود و نه از شما. در صبح سه‌شنبه ۲۰ اکتبر ۲۰۲۶، Revolut دچار قطعی سراسری شد. پرداخت با کارت، انتقال وجه، برداشت از خودپرداز و حتی ورود به اپلیکیشن برای مشتریان در بریتانیا، فرانسه، اسپانیا، آلمان و یونان و همچنین ایرلند از کار افتاد. Revolut اختلالی را که چندین سرویس را تحت تأثیر قرار داده تأیید کرد و گفت پول و داده‌های همه مشتریان در امان است. محتمل‌ترین عامل، خرابی Google Cloud در منطقه لندن آن است که از ساعت ۰۶:۰۸ UTC، یعنی ۰۸:۰۸ به وقت پاریس، آغاز شد و گوگل از آن زمان آن را به یک رخداد برق نسبت داده است. فردی آگاه از موضوع به رویترز گفت که قطعی Revolut با اختلال Google Cloud مرتبط بوده است. هیچ‌یک از دو شرکت این ارتباط را علنی تأیید نکرده‌اند.

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

چرا کارت Revolut من در ۲۰ اکتبر رد شد؟

چون Revolut، شرکتی که هر پرداخت انجام‌شده با کارت‌هایش را تأیید می‌کند، چند ساعت نمی‌توانست پاسخ دهد. به گزارش Clubic، از حدود ساعت ۰۸:۰۰ به وقت پاریس، اپلیکیشن پیام خطا نشان می‌داد، کارت‌ها در فروشگاه‌ها و تاکسی‌ها رد می‌شدند و انتقال‌ها ناکام می‌ماندند. Revolut تنها در فرانسه بیش از ۸ میلیون مشتری دارد. مطبوعات فناوری فرانسه از رد شدن کارت‌ها پشت صندوق‌ها و در خودپردازها گزارش دادند.

صفحه وضعیت خود Revolut دیر به‌روز شد. در ساعت ۰۹:۴۲ به وقت پاریس هنوز همه سیستم‌ها را عملیاتی نشان می‌داد؛ بعدها ۳۱ سرویس را به‌عنوان بخشی در دسترس‌نبودن فهرست کرد، از جمله پرداخت با کارت، انتقال وجه، برداشت از خودپرداز، سرویس‌های پریمیوم و ورود به حساب. روند صبح به این ترتیب پیش رفت.

تا ساعت ۱۳:۲۵ به وقت پاریس در ۲۰ اکتبر، گوگل این قطعی را به یک رخداد برق در ناحیه europe-west2-b نسبت می‌دهد و می‌گوید رخداد برق مهار شده و سرویس‌ها به‌تدریج در حال بازیابی‌اند، اما رخداد آن همچنان باز است و گزارش کامل رخداد آن منتشر نشده است. Revolut هیچ اعلامیه بازیابی منتشر نکرده و علتی هم نام نبرده است. وقتی Revolut یا گوگل گزارش کالبدشکافی منتشر کنند، این مطلب را به‌روز خواهیم کرد.

مشکل از Revolut بود، از Visa یا از فروشگاه؟

هر پرداخت کارتی سه طرف دارد. پایانه فروشگاه و بانک آن (پذیرنده) اطلاعات کارت را می‌گیرند و درخواست تأییدیه می‌فرستند. شبکه کارت، یعنی Visa، Mastercard یا CB در فرانسه، آن درخواست را مسیریابی می‌کند. صادرکننده، یعنی بانکِ پشت کارت شما، در لحظه پاسخ بله یا نه می‌دهد. در ۲۰ اکتبر، ما هیچ رخداد گزارش‌شده‌ای از سوی Visa، Mastercard یا CB پیدا نکردیم و هیچ صادرکننده کارت دیگری هم مشکلی برای کارت‌ها گزارش نکرد، که بنا بر همه شواهد، خرابی را در سمت Revolut به‌عنوان صادرکننده کارت قرار می‌دهد.

قطعی صادرکننده یعنی بانکِ پشت کارت شما نمی‌تواند به درخواست تأیید شبکه پرداخت پاسخ دهد، در نتیجه همه پایانه‌ها هم‌زمان کارت را رد می‌کنند، فارغ از اینکه فروشگاه کجا باشد و در کدام کشور. به همین دلیل است که الگوی ماجرا از بیرون این‌قدر عجیب به نظر می‌رسید: کارت همه‌جا هم‌زمان از کار افتاد، در حالی که فرد کناری شما بی‌دردسر پرداخت می‌کرد.

این موضوع همچنین توضیح می‌دهد که چرا پمپ‌بنزین‌های بدون متصدی هر بار کارت را رد می‌کردند در حالی که صندوق فروشگاه گاهی آن را می‌پذیرفت. یک پمپ خودکار شبانه‌روزی فرانسوی پیش از آنکه نازل را بردارید، از صادرکننده می‌خواهد یک مبلغ حداکثری ثابت را تأیید کند، اغلب ۱۰۰ تا ۱۵۰ یورو که جایگاه تعیین می‌کند، و بعداً آن را با مبلغ واقعی جایگزین می‌کند. این تأیید اولیه به پاسخی زنده از صادرکننده نیاز دارد، پس وقتی صادرکننده ساکت است، پمپ هر بار نه می‌گوید. پمپ قطعی صادرکننده را نمایان می‌کند؛ عامل آن نیست. یک توضیح احتمالی برای پرداخت‌هایی که انجام شدند این است که برخی پایانه‌ها می‌توانند مبالغ کوچک را به‌صورت آفلاین تأیید و بعداً تسویه کنند، و شاید به همین دلیل Clubic گزارش داد که برخی مشتریان Revolut همچنان می‌توانستند در بعضی فروشگاه‌ها پرداخت کنند در حالی که بیشتر کارت‌ها رد می‌شدند.

Google Cloud چه ربطی به کارت بانکی من دارد؟

بسیاری از بانک‌ها و فین‌تک‌ها بخش بزرگی از نرم‌افزار خود را روی زیرساخت ابری اجاره‌ای اجرا می‌کنند و وقتی آن زیرساخت از کار بیفتد، سرویس‌هایشان هم ممکن است همراه آن از کار بیفتند. گوگل می‌گوید مشکل از ساعت ۰۶:۰۸ UTC آغاز شد؛ نخستین به‌روزرسانی وضعیت آن، منتشرشده در ساعت ۱۰:۳۵ به وقت پاریس، یعنی حدود دو ساعت و نیم بعد، از افزایش خطاها و خرابی‌های متناوب شبکه در europe-west2، منطقه لندن آن، خبر داد. برای یک دارنده کارت، این فاصله زمانی اهمیت داشت. حدود دو ساعت و نیم صفحه وضعیت گوگل چیزی نمی‌گفت و در ساعت ۰۹:۴۲ به وقت پاریس، صفحه Revolut هنوز همه سیستم‌ها را عملیاتی نشان می‌داد. The Register اشاره می‌کند که europe-west2-b یکی از سه ناحیه در دسترس‌پذیری آن منطقه است. صفحه رخداد گوگل ۳۸ محصول آسیب‌دیده را فهرست می‌کند، از جمله Kubernetes Engine، Cloud Run و BigQuery Data Transfer Service، و گوگل از همه کسانی که آسیب دیده‌اند عذرخواهی کرد. در ساعت ۱۳:۱۲ به وقت پاریس، گوگل نخستین علت را اعلام کرد: «به دلیل یک رخداد برق، دچار قطعی در ناحیه europe-west2-b شدیم. رخداد برق مهار شده است»، و در به‌روزرسانی آن آمده که سرویس‌ها به‌تدریج در حال بازیابی‌اند. بیانیه گوگل به ناحیه خود آن مربوط است و نامی از Revolut نمی‌برد. سایر مناطق گوگل در اروپا، از جمله پاریس و فرانکفورت، هیچ مشکلی گزارش نکردند.

ارتباط با Revolut همچنان در حد نقل‌قول است، نه تأییدشده. فردی آگاه از موضوع به رویترز گفت که قطعی Revolut با اختلال Google Cloud مرتبط بوده است، و بیانیه‌های خود Revolut نامی از گوگل نمی‌برند. The Journal گزارش داد که گمان می‌رود اختلال ناشی از قطعی در یک ارائه‌دهنده ثالث باشد، بدون آنکه نامی ببرد. همان صبح، Downdetector بریتانیا جهش‌هایی برای Lloyds، Halifax، Bank of Scotland، HSBC، NatWest، Santander UK و MBNA و همچنین Royal Mail، Rightmove و GOV.UK نشان داد، و مشتریان ING آلمان برای ورود به بانکداری آنلاین و اپلیکیشن مشکل داشتند. هیچ‌کس آن گزارش‌ها را رسماً به Google Cloud مرتبط نکرده است و جهش‌های Downdetector می‌توانند گمراه‌کننده باشند، چون کاربران نگران سرویس‌هایی را بررسی می‌کنند که در واقع سالم‌اند.

هر چه گزارش نهایی بگوید، شکل این رویداد آشناست. در سپتامبر، وقتی ChatGPT، Claude و Grok با هم از کار افتادند، یک ابر مشترک نخستین مظنون بود و معلوم شد علت نبوده؛ این بار، یک منطقه ابری واحد توضیح اصلی است، هرچند هنوز تأییدنشده. وقتی شرکت‌های زیادی یک ساختمان را اجاره می‌کنند، یک خطا در آن ساختمان می‌تواند یک‌باره خطای همه شود، و این بار سرویس موردبحث کارتِ داخل جیب شما بود.

آیا حمله سایبری بود، یا به حملات به مراکز داده روسیه مرتبط بود؟

بر پایه شواهد موجود، نه. از ۸ اکتبر ۲۰۲۶، پهپادهای اوکراینی به مراکز داده Yandex در ساسوو، کالوگا و ولادیمیر حمله کرده‌اند و سرویس‌های Yandex را در روسیه و کشورهای همسایه مختل کرده‌اند؛ ما آن حملات را اینجا با جزئیات پوشش دادیم. پوشش خبری آن حملات هیچ تأثیری بر بانک‌های اروپایی، پرداخت‌های کارتی یا ارائه‌دهندگان ابری غربی ذکر نمی‌کند. Revolut در روسیه فعالیت نمی‌کند. قطعی Revolut با مشکل یک تأسیسات گوگل در لندن هم‌زمان شد و هیچ منبعی این دو رویداد را به هم پیوند نمی‌دهد. فقط از یک جهت شبیه هم‌اند: هر دو نشان می‌دهند که سرویس‌های حیاتی در شمار اندکی ساختمان فیزیکی جا گرفته‌اند. اما یکی حمله نظامی به زیرساخت است و دیگری یک خرابی معمولی ابری، و خلط این دو به سود هیچ‌کس نیست.

هیچ چیز هم به هک اشاره ندارد. هیچ منبعی نفوذی گزارش نکرده، Revolut می‌گوید پول و داده‌های مشتریان در امان است، و اپلیکیشن بودجه‌بندی Emma که امروز صبح آن هم آسیب دید، مشکل خود را یک خرابی فنی و نه رخنه امنیتی توصیف کرد. تا زمانی که گزارش کالبدشکافی منتشر نشود، حمله سایبری به‌طور رسمی منتفی نیست، اما همه آنچه امروز قابل مشاهده است به یک رخداد ابری اشاره دارد، نه یک حمله، و خودِ گوگل اکنون قطعی لندن خود را به یک رخداد برق در ناحیه europe-west2-b نسبت می‌دهد، در حالی که گزارش کامل رخداد آن هنوز در راه است.

آیا کار نقص لینوکسی PwnEscape بود، یا بخشی از زنجیره‌ای از قطعی‌های ابری؟

پرسش دومی هم سزاوار همین برخورد است. آیا ممکن است یک نقص تازه‌افشاشده لینوکس پشت ماجرا باشد؟ در ۱۵ اکتبر ۲۰۲۶، پنج روز پیش از این قطعی، تیم CVE هسته لینوکس CVE-2026-99999 با نام مستعار PwnEscape را منتشر کرد، نقصی بحرانی در کد شبکه هسته، در پردازش checksum مربوط به IPv4، با امتیاز ۹.۳ از ۱۰ بر اساس CVSS 3.1. این امتیاز به‌خاطر کاری است که این باگ ممکن می‌کند. یک ماشین مجازی مهمانِ مخرب می‌تواند بسته‌های شبکه‌ای دستکاری‌شده بفرستد که هسته ماشین میزبانِ خود را خراب می‌کنند، و پژوهشگران در آزمایشگاه خودشان نشت حافظه میزبان، از کار افتادن میزبان و اجرای کد با دسترسی root روی میزبان را نشان دادند. نقص در پشته شبکه لینوکس که ترافیک مهمان را پردازش می‌کند جای دارد، نه در یک هایپروایزر خاص.

خودِ کشف منظم و اصولی بود. تیم پژوهشی PWN.AI این باگ را در جریان چالش امنیتی سندباکس Vercel پیدا کرد، آن را در ۴ سپتامبر به‌صورت خصوصی به نگهدارندگان هسته گزارش داد و اصلاحیه در ۱۴ اکتبر وارد هسته اصلی لینوکس شد. مهم‌تر آنکه هیچ بهره‌برداری در دنیای واقعی گزارش نشده است. ارزیابی CISA در ۱۶ اکتبر، ثبت‌شده در صفحه CVE، می‌گوید «Exploitation: none» و این نقص در فهرست CISA از آسیب‌پذیری‌های دارای بهره‌برداری شناخته‌شده نیست. گوگل هیچ بولتن امنیتی درباره آن منتشر نکرده و بولتن‌هایش تا ۱۹ اکتبر نامی از آن نمی‌برند. گوگل قطعی لندن را به یک رخداد برق در ناحیه europe-west2-b نسبت می‌دهد، بیانیه‌های Revolut نه از گوگل نام می‌برند و نه از هیچ آسیب‌پذیری، و Emma مشکل خود را خرابی فنی و نه رخنه امنیتی توصیف کرد. هیچ منبع معتبری PwnEscape را به این قطعی پیوند نمی‌دهد.

با این حال، پس‌زمینه ماجرا واقعی است. این پاییز زنجیره‌ای از رخدادهای ابری بزرگ را به همراه داشت. در ۱ سپتامبر، قطع شدن کابل‌های فیبر شبکه در جریان تعمیرات معمول روترها، بخش‌هایی از دو ناحیه در منطقه us-central1 گوگل در آیووا را حدود چهار ساعت، از ۰۷:۴۱ تا ۱۱:۵۲ به وقت پاسیفیک آمریکا، منزوی کرد و ۱۶ محصول را تحت تأثیر قرار داد. از ۳۰ سپتامبر تا ۱ اکتبر، سرویس‌های گیت‌وی Microsoft Azure، از جمله ExpressRoute، VPN Gateway، Azure Firewall، Application Gateway و Azure VMware Solution، از ساعت ۲۰:۳۰ UTC در ۱۸ منطقه دچار اختلال شدند و مایکروسافت از هم‌بستگی با فعالیت سرویس‌دهی به سیستم‌عامل زیرساخت سخن گفت. در ۸ و ۹ اکتبر، یک به‌روزرسانی پیکربندی توزیع بار، نودهای Google Cloud Storage در us-central1 را بیش از حد بارگذاری کرد و در مجموع حدود ۱۸ ساعت در طول دو روز خطاهای نوشتن ایجاد کرد.

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

چرا پیام‌های فیشینگ به دنبال قطعی‌ها می‌آیند؟

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

دلیلی هم هست که این موضوع را به‌ویژه درباره Revolut جدی بگیریم. در سپتامبر ۲۰۲۶، مهاجمی که خود را یک نهاد نظارتی دولت ایتالیا جا زده بود و از دامنه قانونی دولتی ایمیل می‌فرستاد، داده‌های حدود ۶۵۰ مشتری را به دست آورد، از جمله مدارک هویتی، عکس‌ها، صورت‌حساب‌ها و تاریخچه تراکنش‌ها. Revolut آن را یک کلاهبرداری پیچیده مبتنی بر جعل هویت خارجی خواند، گفت سیستم‌ها و وجوه مشتریان آسیب ندیده‌اند و با افراد آسیب‌دیده تماس گرفت. آن نشت به قطعی ۲۰ اکتبر مرتبط نیست، اما به این معناست که مشخصات واقعی برخی مشتریان در گردش است، و همین یک پیام فیشینگ را به‌طرز قانع‌کننده‌ای شخصی جلوه می‌دهد.

هیچ کارشناس پشتیبانی واقعی بانک به PIN، رمزهای عبور، کدهای یک‌بارمصرف یا مشخصات کارت شما نیاز ندارد و هیچ‌کدام از شما نمی‌خواهند به این دلیل که با شما تماس گرفته‌اند چیزی را در اپلیکیشن تأیید کنید؛ در صورت تردید، تماس را قطع کنید و از طریق اپلیکیشن با بانک ارتباط بگیرید. روی لینک‌های داخل پیام‌های مربوط به قطعی نزنید؛ اپلیکیشن را مستقیم باز کنید و اعلان‌های آن را بخوانید. به‌عنوان یک سد پشتیبان، Threat Protection در Le VPN دامنه‌های شناخته‌شده فیشینگ و بدافزار را پیش از بارگذاری مسدود می‌کند. این سرویس نمی‌تواند جلوی رسیدن پیامک را بگیرد یا هر دامنه کلاهبرداری کاملاً تازه را شکار کند، پس شکاکیت خود شما همچنان نخستین خط دفاع است.

دفعه بعد چطور گرفتار نشوید؟

شما نمی‌توانید جلوی قطعی بعدی Revolut را بگیرید، اما می‌توانید کاری کنید که برای خودتان اتفاقی بی‌اهمیت باشد.

• یک کارت دوم از صادرکننده‌ای متفاوت همراه داشته باشید. کارت دوم Revolut همراه با اولی از کار می‌افتد. برای ساکنان فرانسه، یک کارت بانکی فرانسوی روی شبکه CB مکمل خوبی است، چون صادرکننده‌ای دیگر آن را تأیید می‌کند.
• مقداری پول نقد نگه دارید. به اندازه سوخت و خوراک. برداشت از خودپردازهای Revolut هم از کار افتاده بود، پس زمان برداشت پول پیش از قطعی است، نه در میانه آن.
• در جایگاه سوخت، باجه دارای متصدی را امتحان کنید نه پمپ خودکار را، البته ممکن است آنجا هم کارت رد شود.
• ابتدا صفحه وضعیت و اعلان‌های داخل اپلیکیشن را بررسی کنید. پیش از آنکه فرض کنید کارتتان مسدود یا لو رفته است، ببینید آیا صادرکننده رخدادی را گزارش می‌کند. Revolut همچنین دلایل معمول رد شدن را فهرست می‌کند، مانند کارت مسدود، سقف خرج‌کرد، تأییدیه 3-D Secure در انتظار یا نوع پرداخت غیرفعال، و دلیل مشخص در اپلیکیشن نمایش داده می‌شود.
• با وحشت کارت را مسدود، باطل یا بازنشانی نکنید. در زمان قطعی صادرکننده این کار چیزی را تغییر نمی‌دهد، و یک کارت باطل‌شده یعنی پس از بازگشت سرویس باید منتظر کارت جایگزین بمانید.
• هرگز به کسی که با شما تماس می‌گیرد و ادعا می‌کند پشتیبانی Revolut است اطلاعاتی ندهید، به‌ویژه در چنین روزی.
• اسکرین‌شات‌های دارای زمان نگه دارید از پرداخت‌های ردشده و انتقال‌های ناموفق، اگر برایتان هزینه‌ای ایجاد کرده‌اند، و پس از بازگشت سرویس موضوع را از طریق اپلیکیشن با پشتیبانی Revolut مطرح کنید.

چیزی که کمکی نمی‌کرد VPN است، و ما این را به‌عنوان یک ارائه‌دهنده VPN می‌گوییم. تأییدیه کارت میان پایانه، شبکه کارت و صادرکننده جریان دارد؛ اتصال خود شما، با یا بدون یک سرور VPN فرانسوی، هیچ نقشی در تأیید شدن یا نشدن پرداخت ندارد. VPN ترافیک شما را محافظت می‌کند و با Threat Protection بسیاری از دامنه‌های کلاهبرداری را که به دنبال روزی مثل امروز می‌آیند فیلتر می‌کند. اما یک بانک را سرپا نگه نمی‌دارد.

گوگل نخستین علت را اعلام کرده است، یک رخداد برق در ناحیه europe-west2-b آن، اما گزارش کامل رخداد هنوز در راه است. وقتی برسد، سه چیز را باید زیر نظر داشت: اینکه رخداد برق دقیقاً چه چیزی را از کار انداخت، اینکه آیا Revolut ارتباط با Google Cloud را با کلمات خودش تأیید می‌کند، و اینکه چرا صفحه وضعیت آن همه سیستم‌ها را عملیاتی نشان می‌داد در حالی که کارت‌ها همان موقع پشت صندوق‌ها در سراسر اروپا رد می‌شدند.