--- service: "Publicasta" schema_version: "1.0" article_id: 613 title: "CVE-2026-76461: użytkownicy Cisco Secure Email Gateway potrzebują aktualizacji i analizy śladów włamania" language: "pl" default_language: "en" canonical_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response?lang=pl" json_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response.json?lang=pl" api_url: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles/cisco_secure_email_gateway_cve_2026_76461_response?lang=pl" channel_url: "https://publicasta.com/api/public/v1/channels/cybersecurity" channel_articles: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-09-15T06:53:56+00:00" updated_at: "2026-09-15T06:53:56+00:00" translations: - language: "ar" html_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response?lang=ar" markdown_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response.md?lang=ar" json_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response.json?lang=ar" - language: "de" html_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response?lang=de" markdown_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response.md?lang=de" json_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response.json?lang=de" - language: "en" html_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response?lang=en" markdown_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response.md?lang=en" json_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response.json?lang=en" - language: "es" html_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response?lang=es" markdown_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response.md?lang=es" json_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response.json?lang=es" - language: "fr" html_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response?lang=fr" markdown_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response.md?lang=fr" json_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response?lang=pl" markdown_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response.md?lang=pl" json_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response?lang=ru" markdown_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response.md?lang=ru" json_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response?lang=zh" markdown_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response.md?lang=zh" json_url: "https://publicasta.com/cybersecurity/cisco_secure_email_gateway_cve_2026_76461_response.json?lang=zh" --- # CVE-2026-76461: użytkownicy Cisco Secure Email Gateway potrzebują aktualizacji i analizy śladów włamania > Cisco informuje o aktywnie wykorzystywanej luce SQL injection w Secure Email Gateway. Sama aktualizacja nie wystarczy: trzeba ustalić podatne urządzenia, wdrożyć poprawiony AsyncOS i sprawdzić logi pocztowe pod kątem oznak naruszenia. Cisco ujawniło aktywnie wykorzystywaną lukę w Cisco Secure Email Gateway, która wymaga natychmiastowej uwagi organizacji korzystających z urządzeń fizycznych lub wirtualnych. CVE-2026-76461 to nieuwierzytelniona luka SQL injection w logice analizowania poczty produktu. Cisco ocenia ją na 9,8 w skali CVSS i informuje, że udany atak może doprowadzić do wykonania poleceń z uprawnieniami roota w bazowym systemie operacyjnym. ![Ogólna firmowa brama bezpieczeństwa poczty e-mail ze wskaźnikami alertów i analizą kryminalistyczną dzienników](https://publicasta.com/storage/projects/9/pages/613/2026/09/e32267d3-1c5e-4171-a9eb-564d344c04b5.webp) Najważniejszy szczegół operacyjny nie sprowadza się do samej oceny. Urządzenie znajduje się na ścieżce poczty przychodzącej do organizacji lub z niej wychodzącej, a Cisco podaje, że luka dotyczy Secure Email Gateway niezależnie od konfiguracji urządzenia. Nie ma rozwiązania zastępczego producenta, które uczyniłoby podatną instalację bezpieczną. Potrzebna jest aktualizacja, a następnie sprawdzenie, czy urządzenie nie zostało już wykorzystane. To problem reakcji na incydent z dwoma odrębnymi pytaniami: jak szybko organizacja może przenieść podatną bramę do poprawionej wersji oraz z jaką pewnością może ustalić, czy brama była nadużywana przed aktualizacją? Potraktowanie pierwszego pytania jako całego zadania pozostawia drugie bez odpowiedzi. ## Co ujawniło Cisco W biuletynie bezpieczeństwa Cisco, opublikowanym 14 września 2026 r., CVE-2026-76461 wskazano jako lukę w logice analizowania poczty oprogramowania Cisco AsyncOS dla Cisco Secure Email Gateway. Przyczyną jest niewystarczająca walidacja danych wejściowych. W praktyce napastnik może przesłać przez podatne urządzenie specjalnie przygotowaną wiadomość e-mail. Cisco opisuje wynikający z tego problem jako SQL injection, który może prowadzić do wykonania dowolnych instrukcji SQL, a następnie do wykonania poleceń z uprawnieniami roota. Atak nie wymaga uwierzytelnienia, uprzywilejowanego konta ani interakcji użytkownika. Opublikowany przez Cisco wektor CVSS to AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Opisuje on lukę dostępną przez sieć, o niskiej złożoności ataku i wysokim potencjalnym wpływie na poufność, integralność oraz dostępność. Wynik pomaga wyjaśnić pilność sprawy, ale nie dowodzi, że każda brama została przejęta. Cisco wymienia jako podatne zarówno fizyczne, jak i wirtualne wdrożenia Secure Email Gateway. Biuletyn stwierdza, że podatność występuje niezależnie od konfiguracji urządzenia. Cisco osobno wskazuje Secure Email and Web Manager oraz Secure Web Appliance jako produkty, których ta konkretna luka nie dotyczy. To rozróżnienie ma znaczenie dla właścicieli zasobów korzystających z kilku produktów bezpieczeństwa Cisco: podobnie brzmiąca nazwa produktu nie wystarcza do ustalenia ekspozycji, a bramy, która nie jest wystawiona do internetu, nie należy automatycznie uznawać za bezpieczną. Biuletyn Cisco jest podstawowym źródłem technicznym informacji o luce, rodzinie produktów, wskaźnikach i poprawionym oprogramowaniu. Kanadyjskie Centrum Cyberbezpieczeństwa powtórzyło alert 14 września i odnotowało, że Cisco zgłosiło aktywne wykorzystywanie luki. CISA dodała również CVE do katalogu Known Exploited Vulnerabilities, co stanowi sygnał priorytetyzacji dla zespołów zarządzania podatnościami i obowiązkowej naprawy dla amerykańskich federalnych agencji cywilnych zgodnie z właściwym procesem CISA. ## Aktywne wykorzystywanie zmienia decyzję Cisco informuje, że jego PSIRT dowiedział się o aktywnym wykorzystywaniu luki we wrześniu 2026 r. To sformułowanie ma znaczenie. Jest mocniejsze niż demonstracja kodu proof of concept przez badacza albo dyskusja społeczności bezpieczeństwa o teoretycznej ścieżce ataku. Oznacza, że obrońcy powinni przyjąć założenie, iż luka jest wykorzystywana w rzeczywistych działaniach, jednocześnie unikając niepopartego dowodami wniosku, że doszło do włamania w konkretnej organizacji. W publicznych materiałach, w tym w analizowanym biuletynie, nie przypisano tej aktywności konkretnemu aktorowi zagrożeń ani nie opisano potwierdzonej kampanii przeciwko określonemu sektorowi. Brak takich informacji nie jest powodem do czekania. Istotna decyzja opiera się na ekspozycji, statusie wykorzystywania i roli urządzenia w dostarczaniu poczty. Organizacje nie potrzebują medialnego nagłówka o dużym incydencie, aby rozpocząć ograniczanie skutków i analizę. Właściwy priorytet jest więc warunkowy, ale szybki: - Jeśli organizacja obsługuje podatną bramę Secure Email Gateway, należy ustalić dokładne wydanie AsyncOS i zaplanować poprawioną aktualizację jako zmianę awaryjną. - Jeśli urządzenie odbierało pocztę, gdy było podatne, trzeba zachować i przeanalizować jego logi, zanim zwykła retencja lub rotacja usunie przydatne dowody. - Jeśli pojawią się podejrzane działania, urządzenie należy traktować jako potencjalnie przejęty element kontroli bezpieczeństwa i zaangażować osoby odpowiedzialne za reagowanie na incydenty, wsparcie Cisco oraz właścicieli bezpieczeństwa poczty. Aktualizacja zamyka znaną lukę w oprogramowaniu. Nie usuwa jednak poleceń, które napastnik mógł już wykonać, ustanowionej przez niego persystencji ani danych pocztowych i poświadczeń, do których mógł uzyskać dostęp. ## Które wersje są poprawione Wrześniowe wydanie wzmacniające Cisco zawiera najbardziej użyteczne mapowanie aktualizacji dla administratorów. Dla Cisco Secure Email Gateway Release 15.5 i wcześniejszych pierwszym poprawionym wydaniem jest 15.5.5-014. Kanadyjski alert Cisco wymienia także poprawione gałęzie rodziny produktu: 15.5.5-014, 16.0.4-302 oraz 16.5.0-780, zależnie od używanej gałęzi. Administratorzy powinni skorzystać z aktualnego, właściwego dla produktu biuletynu Cisco oraz informacji o pobieraniu oprogramowania, aby wybrać wspierane poprawione wydanie dla swojego wdrożenia, zamiast kopiować numer wersji z niepowiązanej gałęzi. Aktualizacja nie jest opisana jako mała zmiana konfiguracji. Biuletyn wzmacniający Cisco podaje, że po aktualizacji urządzenie uruchamia się ponownie. Tworzy to krótkie wyzwanie związane z planowaniem obsługi poczty, ale nie uzasadnia bezterminowego odkładania naprawy. Okno zmian powinno obejmować potwierdzenie, że kolejki pocztowe, routing, kwarantanna, certyfikaty, dostęp administracyjny oraz konfiguracja wysokiej dostępności lub klastra działają prawidłowo po restarcie. Cisco Secure Email Cloud wymaga nieco innej ścieżki operacyjnej. Cisco informuje, że usługa obejmuje urządzenia Secure Email Gateway oraz Secure Email and Web Manager jako część rozwiązania i że Cisco zapewnia regularne utrzymanie. Klienci mogą poprosić o aktualizację za pośrednictwem wsparcia Cisco Secure Email Cloud. Organizacje korzystające z usługi chmurowej powinny otworzyć lub zweryfikować zgłoszenie do wsparcia, zapytać, które urządzenia bazowe i wydania utrzymaniowe obejmują to CVE, a także zachować dostępne po stronie klienta logi na czas wyjaśniania sprawy. Nie należy mylić braku lokalnego przycisku aktualizacji z brakiem odpowiedzialności. Usługa zarządzana zmienia podmiot wykonujący aktualizację, ale nie usuwa potrzeby ustalenia, że aktualizacja rzeczywiście nastąpiła i że odpowiedni okres został sprawdzony pod kątem podejrzanej aktywności. ## Dlaczego sama aktualizacja nie wystarczy Cisco podaje wąski, lecz wartościowy test oznak naruszenia: należy przejrzeć `mail_logs` urządzenia pod kątem podejrzanych instrukcji SQL. Biuletyn podaje `COPY ... TO PROGRAM` jako przykładowy wzorzec i informuje, że obecność takiego wpisu może wskazywać na próbę wykorzystania luki. W przypadku wdrożenia klastrowego Cisco zaleca przegląd logów każdego urządzenia w klastrze. Ten test należy traktować jako gromadzenie dowodów, a nie poszukiwanie jednego magicznego ciągu znaków. Czysty wynik wyszukiwania przykładowego wzorca nie może dowieść, że nie wystąpiła żadna inna aktywność. Z kolei pasujący wpis wymaga kontekstu: należy zachować znaczniki czasu, informacje o źródle, identyfikatory wiadomości, tożsamość urządzenia, zdarzenia administracyjne, zmiany konfiguracji i powiązaną telemetrię, zanim analitycy wyciągną wnioski. Wyszukiwanie jest punktem wyjścia wskazanym przez producenta, a nie pełną oceną przejęcia. Praktyczna analiza powinna odpowiedzieć na następujące pytania: - Które bramy działały z podatnym wydaniem i jaki był dokładny przedział czasu ich podatności? - Które z tych bram przyjmowały pocztę z niezaufanych lub szeroko dostępnych źródeł? - Czy `mail_logs` są dostępne dla całego okresu ekspozycji na każdym węźle, w tym w kopiach przechowywanych, rotowanych lub scentralizowanych? - Czy logi pokazują podejrzaną składnię SQL, nietypową obsługę wiadomości, nieoczekiwaną aktywność administracyjną, zmiany konfiguracji albo procesy i połączenia, których urządzenie nie powinno tworzyć? - Czy brama przetwarzała pocztę, poświadczenia, tokeny, certyfikaty, zawartość kwarantanny, książki adresowe lub inne informacje, których ujawnienie wymagałoby powiadomienia albo rotacji? - Czy brama jest częścią systemu zarządzania lub monitorowania, który mógłby rozszerzyć dostęp napastnika poza samo urządzenie? Dwa ostatnie pytania pokazują, kiedy reakcja na podatność staje się reakcją na incydent. Brama pocztowa może nie być głównym magazynem danych organizacji, ale przetwarza wiadomości zawierające informacje biznesowe, linki do resetowania haseł, faktury, dokumenty tożsamości, próbki złośliwego oprogramowania i wewnętrzne szczegóły routingu. Przejęcie może również pozwolić napastnikowi ingerować w filtrowanie lub dostarczanie wiadomości, co tworzy problem zaufania nawet wtedy, gdy nie ma dowodów na masową kradzież danych. ## Sekwencja reakcji, którą można obronić Najpierw trzeba ustalić właścicieli i wykonać inwentaryzację. Zespół odpowiedzialny za zarządzanie podatnościami może mieć spis oprogramowania, zespół pocztowy zna urządzenia, a zespół sieciowy kontroluje ścieżkę ekspozycji. Te rejestry należy połączyć. Warto zapisać numery seryjne lub identyfikatory instancji wirtualnych, lokalizację wdrożenia, rolę produktu, wydanie AsyncOS, ścieżkę zarządzania, członkostwo w klastrze, ostatnią kopię zapasową, status retencji logów i właściciela zmiany. Celem jest skończona lista urządzeń oraz opatrzone znacznikiem czasu stwierdzenie, które z nich były podatne. Następnie należy ograniczyć możliwą do uniknięcia ekspozycję w czasie przygotowywania zmiany. Nie wolno wymyślać obejścia ani zakładać, że reguła zapory jest równoważna poprawce producenta. Warto sprawdzić, czy interfejsy administracyjne są ograniczone do sieci zarządzających, czy ścieżki przychodzącej poczty można zawęzić do zamierzonych przekaźników organizacji oraz czy monitoring działa. Takie działania mogą ograniczyć niepotrzebną dostępność, ale nie naprawiają błędu analizowania danych w urządzeniu, które nadal musi odbierać zewnętrzną pocztę. Potem każde podatne urządzenie należy zaktualizować do odpowiedniego poprawionego wydania. Trzeba zapisać wersję przed i po zmianie, okno utrzymaniowe, czas restartu, wynik walidacji oraz każdy węzeł, którego nie udało się zaktualizować lub którego aktualizację odłożono. W klastrze należy zweryfikować każdego członka. Częściowo zaktualizowany klaster nadal jest narażony, a stary obraz urządzenia wirtualnego może ponownie wprowadzić podatne wydanie podczas odtwarzania lub skalowania. Bezpośrednio po aktualizacji należy zachować dowody, które mogłyby zniknąć w wyniku normalnych operacji. Eksport lub kopię odpowiednich logów trzeba wykonać zgodnie z procedurami organizacji dotyczącymi obsługi incydentów. Należy zachować oryginalne znaczniki czasu i odnotować, kto zebrał każdy plik. Jeśli urządzenie wygląda na zmodyfikowane, trzeba unikać wielokrotnych zmian niszczących kontekst analizy śledczej. Należy zaangażować specjalistów, którzy ocenią, czy bezpieczniejsza będzie czysta odbudowa lub wymiana urządzenia, zamiast zaufania zaktualizowanemu systemowi. Na końcu trzeba obrócić te elementy, które według analizy mogły zostać ujawnione. Dokładna lista zależy od konfiguracji bramy i dowodów. Kandydatami mogą być lokalne poświadczenia administracyjne, poświadczenia usług, tokeny API, certyfikaty i klucze prywatne, poświadczenia przekaźników, dostęp do kwarantanny oraz sekrety przechowywane w integracjach. Rotację należy skoordynować z przepływem poczty, aby poprawa bezpieczeństwa nie spowodowała po cichu awarii. ## Co powinny zrobić poszczególne zespoły Dla administratorów poczty najpilniejszym zadaniem jest zidentyfikowanie każdej bramy fizycznej, wirtualnej i wspieranej przez chmurę oraz potwierdzenie jej poprawionego wydania. Członków klastra należy sprawdzać osobno. Po restarcie trzeba skontrolować przepływ poczty i upewnić się, że logowanie pozostaje włączone oraz, jeśli to możliwe, scentralizowane. Dla zespołów security operations potrzebne jest ukierunkowane okno analizy obejmujące okres, w którym każde urządzenie było podatne. Należy przeszukać wskazane przez producenta lokalizacje logów i powiązaną telemetrię, a następnie skorelować ustalenia ze zdarzeniami uwierzytelniania, sieci, DNS, punktów końcowych i tożsamości. Celem jest ustalenie, czy brama była tylko wystawiona, atakowana, czy skutecznie zmodyfikowana. Dla zespołów zarządzania podatnościami CVE-2026-76461 powinno być zapisane jako podatność wykorzystywana, a nie tylko wysoko oceniona. Lista KEV CISA jest użyteczna, ponieważ dodaje dowód wykorzystywania do decyzji o ryzyku. Wyjątki należy śledzić wraz z właścicielem i terminem wygaśnięcia. Wyjątek bez kontroli kompensującej, planu gromadzenia dowodów i terminu jest jedynie nieudokumentowanym opóźnieniem. Klienci usług zarządzanych powinni skontaktować się z dostawcą, zadając precyzyjne pytania: jaki produkt i jakie wydanie jest wdrożone, czy dostawca zastosował poprawione wydanie na każdym odpowiednim węźle, kiedy zakończono prace, czy logi są przechowywane oraz czy dostawca wykrył złośliwą aktywność. Należy poprosić o odpowiedź dotyczącą rzeczywistych instancji organizacji, a nie ogólne zapewnienie, że usługa jest utrzymywana. Dla osób odpowiedzialnych za decyzje użyteczny raport statusowy powinien być krótki i rzeczowy: liczba urządzeń dotkniętych problemem, liczba naprawionych, liczba oczekujących, okres ekspozycji, dostępność logów, podejrzane ustalenia, obrócone poświadczenia lub certyfikaty oraz termin kolejnego przeglądu. Nie należy przedstawiać wyniku CVSS tak, jakby był statusem incydentu. Wynik wyjaśnia potencjalną dotkliwość, ale nie mówi kierownictwu, czy organizacja została przejęta. ## Na jakie pytania biuletyn nie odpowiada Publiczne biuletyny są często początkowo celowo niepełne. Cisco wskazuje aktywne wykorzystywanie, ale w analizowanych materiałach nie przedstawia pełnej historii kampanii. Z tego nie wynika, że każdy szczegół techniczny jest publiczny, że istnieje publiczny exploit ani że cicha brama jest czysta. Oznacza to, że obrońcy powinni korzystać z poprawionych wydań i wskaźników producenta, jednocześnie traktując analizę jako lokalne pytanie oparte na dowodach. Biuletyn nie zmienia też przeglądu logów w test binarny. Logi mogą być niepełne, centralizacja może mieć luki, a wyrafinowany intruz może używać aktywności, która nie pasuje do przykładu dostarczonego przez producenta. Jakość wniosku zależy od widoczności dostępnej na urządzeniu i w systemach otaczających. Jeśli zapisów urządzenia brakuje dla istotnego okresu, należy wyraźnie odnotować to ograniczenie, zamiast zamieniać je w fałszywe uspokojenie. Biuletyn nie oznacza również, że wszystkie produkty bezpieczeństwa Cisco są objęte tą samą ekspozycją. Wskazanym podatnym produktem jest Cisco Secure Email Gateway. Secure Email and Web Manager określono jako nieobjęty tą konkretną poradą dotyczącą SQL injection, chociaż osobny wrześniowy biuletyn wzmacniający obejmuje szerszy zestaw podatności i uwzględnia produkt Manager. Właściciele zasobów powinni mapować każde CVE do dokładnego produktu i wydania, zamiast stosować jedną szeroką etykietę do całego środowiska Cisco. ## Spokojne podsumowanie CVE-2026-76461 jest pilne, ponieważ podatny komponent pełni funkcję internetowej kontroli poczty w wielu organizacjach, atak nie wymaga uwierzytelnienia, Cisco opublikowało ocenę dotkliwości 9,8, a także poinformowało o aktywnym wykorzystywaniu luki. Reakcję można jednak opanować, jeśli zostanie przełożona na konkretne czynności. Trzeba znaleźć urządzenia. Potwierdzić wydania. Zaktualizować je do poprawionej gałęzi AsyncOS. Zachować i przeanalizować `mail_logs` na każdym odpowiednim węźle. Podejrzane wyniki należy zbadać przed zamknięciem sprawy, a poświadczenia lub certyfikaty obrócić, gdy uzasadniają to dowody albo architektura. Jeśli usługa jest zarządzana w chmurze, trzeba uzyskać od dostawcy potwierdzenie dotyczące konkretnych instancji. Najważniejsze rozróżnienie przebiega między naprawą a dowodem. Instalacja poprawki naprawia znaną podatność. Przegląd okresu ekspozycji i dostępnych dowodów pozwala organizacji powiedzieć, z uczciwie określonym poziomem pewności, czy brama została wykorzystana przeciwko niej. ## Źródła i dalsza lektura - [Biuletyn bezpieczeństwa Cisco: luka SQL injection w Cisco Secure Email Gateway](https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-esa-inj-2bLVGmhX.html) — podatne produkty, dotkliwość, informacja o aktywnym wykorzystywaniu, poprawione oprogramowanie i wskaźniki naruszenia. - [Biuletyn bezpieczeństwa Cisco: wydanie wzmacniające bezpieczeństwo Cisco Secure Email Gateway oraz Secure Email and Web Manager, wrzesień 2026](https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-hardening-esa-dfCrfXkm.html) — mapowanie poprawionych wydań i konsekwencje aktualizacji dla szerszego wydania wzmacniającego. - [Kanadyjskie Centrum Cyberbezpieczeństwa: alert Cisco AV26-921](https://www.cyber.gc.ca/en/alerts-advisories/cisco-security-advisory-av26-921) — niezależny alert rządowy potwierdzający status wykorzystywania i podatne wydania Cisco. - [Katalog Known Exploited Vulnerabilities CISA](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) — katalog CISA i ramy priorytetyzacji podatności, o których wiadomo, że są wykorzystywane w rzeczywistych atakach.