Złośliwe serwery MCP i bezpieczeństwo poczty elektronicznej: nowe zagrożenie dla łańcucha dostaw

We wrześniu 2025 roku pojedyncza linijka ukrytego kodu w bibliotece npm typu open source podważyła nasze dotychczasowe przekonania dotyczące bezpieczeństwa łańcucha dostaw. Dzięki temu złośliwe oprogramowanie atakujące serwery poczty elektronicznej MCP zyskało rozgłos jako nowa, niebezpieczna kategoria zagrożeń.

Przez ponad tydzień pakiet o nazwie „postmark-mcp” codziennie przekazywał atakującemu od 3 000 do 15 000 firmowych wiadomości e-mail. Nie chodziło tu o żadną spektakularną lukę typu zero-day, a jedynie o prostą, ukrytą regułę dotyczącą ukrytej kopii (BCC), uruchamianą z pełnymi uprawnieniami administratora. Skutki były katastrofalne – doszło do wycieku haseł, wewnętrznych faktur, danych klientów oraz aktywnych tokenów uwierzytelniających.

Jest to pierwszy udokumentowany przypadek włamania do złośliwego serwera MCP w środowisku produkcyjnym. W miarę jak autonomiczne agenty AI zyskują coraz większe znaczenie w korporacyjnych procesach, ujawniają one ogromną lukę w zabezpieczeniach. Tradycyjne mechanizmy ochronne, takie jak SPF, DKIM oraz DMARC zostały stworzone z myślą o erze przewidywalnego, sterowanego przez ludzi routingu poczty. Paradygmat Model Context Protocol (MCP) całkowicie zmienia tę sytuację, wprowadzając warstwę zagrożeń wewnętrznych, których tradycyjne filtry obwodowe po prostu nie są w stanie wykryć.

Co się wydarzyło – incydent z Postmark-mcp

Postmark (obsługiwany przez ActiveCampaign) to popularna usługa poczty transakcyjnej, z której korzystają tysiące firm do wysyłania ważnych automatycznych powiadomień, takich jak resetowanie haseł i potwierdzenia zamówień. Aby sprostać gwałtownemu rozwojowi generatywnej sztucznej inteligencji, na platformie GitHub uruchomiono oficjalne repozytorium open source, które umożliwia programistom bezpośrednie połączenie asystenta AI Claude firmy Anthropic z infrastrukturą Postmark za pośrednictwem protokołu Model Context Protocol.

Wykorzystując tę lukę, złośliwy podmiot opublikował fałszywy pakiet o nazwie „postmark-mcp”. Nie była to zwykła pomyłka w nazwie; chodziło o dokładne dopasowanie nazwy, mające na celu zwabienie programistów pragnących szybko zainstalować pakiet za pomocą npm.

Długofalowa strategia: budowanie zaufania

Atakujący prowadził przemyślaną, długofalową grę. Przez piętnaście kolejnych wydań (od wersji 1.0.0 do 1.0.15) pakiet działał bez zarzutu. Odzwierciedlał kod z oficjalnego repozytorium, bezbłędnie wykonywał wywołania API i nie wywoływał żadnych alertów. Dzięki temu z powodzeniem ominął automatyczne kontrole w piaskownicy i zdobył podstawowe zaufanie systemów monitorujących bezpieczeństwo.

Aktywacja ładunku

17 września 2025 r. doszło do poważnych szkód w związku z wersją 1.0.16. W głębi pliku index.js, w wierszu 231, wydawca dodał jedną linię kodu. Ta modyfikacja powodowała dołączanie ukrytego adresu BCC do treści każdej wiadomości e-mail przechodzącej przez serwer oraz przekierowywanie kopii do domeny kontrolowanej przez atakującego [giftshop.club].

Ponieważ moduł ten znajdował się w ramach zweryfikowanej warstwy aplikacji, miał już autoryzowany dostęp do aktywnych kluczy API. Atak nie wymagał stosowania żadnych nietypowych metod podwyższenia uprawnień. Udał się, ponieważ kod działał w ramach zaufanego korporacyjnego łańcucha procesów. Wyciek danych trwał do 25 września 2025 r., kiedy to silnik analizy ryzyka firmy Koi Security wykrył nietypowe wzorce zachowań pochodzące z tej biblioteki.

Wpływ

Kontrole przeprowadzone po incydencie przez firmy Koi Security i Snyk wykazały, że pakiet ten odnotował około 1643 pobrań, co przełożyło się na około 1500 aktywnych instalacji tygodniowo, z których codziennie dochodziło do wycieku danych.

Gdy sprawa wyszła na jaw, wydawca usunął pakiet z npm. Jednak prawdziwym problemem przy usuwaniu jest to, że wycofanie pakietu z publicznego repozytorium nie powoduje jego usunięcia z aktywnych środowisk. Każdy aktywny klaster chmury lub potok kontenerów działający w wersji 1.0.16 nadal ujawniał dane, dopóki zespoły nie namierzyły go i nie usunęły ręcznie. Firma Postmark szybko wydała oświadczenie, w którym wyjaśniła, że nie opracowała, nie autoryzowała ani nie utrzymywała tego pakietu. Ponieważ była to raczej luka behawioralna niż błąd w kodzie, nie przypisano jej formalnego identyfikatora Common Vulnerabilities and Exposures, co pozostawia po sobie unikalny, niezweryfikowany ślad ataku na łańcuch dostaw serwerów MCP.

Jeśli podejrzewasz, że Twój zespół kiedykolwiek korzystał z tego pakietu, potraktuj to jako aktualny incydent: natychmiast odinstaluj go ze wszystkich środowisk, zaktualizuj wszystkie dane uwierzytelniające i klucze API, które kiedykolwiek przez niego przepływały, oraz przeszukaj logi poczty pod kątem wiadomości wysyłanych w kopii ukrytej (BCC) do oznaczonej domeny. Warto również sprawdzić pozostałą część konta wydawcy; ten sam autor zarządzał około 31 innymi pakietami, z których każdy może stwarzać podobne zagrożenie.

Dlaczego serwery MCP stanowią atrakcyjny cel ataków e-mailowych?

Protokół Model Context Protocol (MCP) szybko staje się standardową platformą integracyjną dla rozwiązań AI w przedsiębiorstwach. Firma Gartner przewiduje, że do końca 2026 roku 75% dostawców bram API wdroży natywne zestawy narzędzi MCP do zarządzania agentową sztuczną inteligencją w zakresie bezpieczeństwa poczty elektronicznej.

Czym dokładnie jest integracja z protokołem Model Context Protocol? Serwer MCP można traktować jako bezpieczny most API łączący asystenta AI (takiego jak Claude) z zewnętrznymi repozytoriami danych, środowiskami programistycznymi i narzędziami innych producentów. Zamiast zarządzać chaotyczną siecią niestandardowych interfejsów API, agent AI wykorzystuje ten ujednolicony protokół do samodzielnego wysyłania zapytań do baz danych, sprawdzania systemów CRM lub koordynowania procesów związanych z pocztą elektroniczną.

Główna słabość: całkowite zaufanie

Aby serwer MCP mógł spełniać swoją rolę, potrzebuje długoterminowych, szerokich uprawnień operacyjnych. Podłączając agenta AI do bramy pocztowej w celu zautomatyzowania planowania lub obsługi klienta, przyznajesz mu pełny dostęp do odczytu i zapisu. Działa on wtedy jak pracownik posiadający pełne uprawnienia delegowane.

Jak ujął to Idan Dardikman, dyrektor ds. technicznych w firmie Koi Security, organizacje w zasadzie przekazują uprawnienia administracyjne o nieograniczonym zakresie narzędziom backendowym stworzonym przez niezweryfikowanych i niewiarygodnych zewnętrznych twórców.

W przeciwieństwie do tradycyjnych ataków na łańcuch dostaw oprogramowania (takich jak SolarWinds), które wymierzone są w głęboką infrastrukturę, zagrożenia związane z serwerami MCP stron trzecich nie wymagają włamania do infrastruktury. Atakujący muszą jedynie nakłonić użytkownika do zainstalowania modułu, a agent AI uruchamia go samodzielnie. Ponieważ w procesie tym nie bierze udziału człowiek, który mógłby zweryfikować zautomatyzowany przebieg pracy, zainfekowana biblioteka może przez wiele dni wyciekać poufne dane, nie wzbudzając żadnych podejrzeń.

Luka w uwierzytelnianiu wiadomości e-mail – przed czym chroni DMARC, a przed czym nie

Podczas gdy zespoły ds. bezpieczeństwa starają się chronić przed tymi zagrożeniami w postaci wiadomości e-mail wykorzystujących sztuczną inteligencję w łańcuchu dostaw, wielu zakłada, że protokoły takie jak SPF, DKIM i DMARC powstrzymają ten problem. Musimy jednak dokładnie przyjrzeć się temu, czym faktycznie zajmują się te mechanizmy kontroli i gdzie leżą luki w zabezpieczeniach.

Czego miały zapobiegać protokoły DMARC, SPF i DKIM

Podstawowy zestaw narzędzi SPF, DKIM i DMARC został stworzony w celu zapobiegania fałszowaniu adresów domenowych oraz uniemożliwienia nieuczciwym podmiotom przeprowadzania kampanii polegających na fałszowaniu wiadomości e-mail lub atakach typu BEC z wykorzystaniem tożsamości Twojej marki.

• SPF sprawdza, czy adres IP serwera pocztowego wysyłającego wiadomość jest uwzględniony w Twoich rekordach DNS.
• DKIM dodaje do nagłówka unikalny podpis cyfrowy, aby potwierdzić, że wiadomość nie została zmieniona podczas przesyłania.
• DMARC łączy je ze sobą, narzucając zasady dotyczące sposobu, w jaki serwery odbierające radzą sobie z niepowodzeniami.

W przypadku luki typu „postmark-mcp” mechanizmy te nie zostały obejście; były one po prostu zupełnie nieistotne. Ponieważ złośliwy pakiet został wbudowany w legalną aplikację firmową, wykorzystywał on prawidłowe klucze API do kierowania wiadomości przez autoryzowane serwery Postmark. Każda skradziona wiadomość e-mail posiadała bezbłędny podpis DKIM i bez problemu przechodziła kontrolę SPF. Jest w tym gorzka ironia: ten prawidłowy podpis DKIM pomógł nawet własnemu serwerowi odbiorczemu atakującego potwierdzić, że skradzione wiadomości są autentyczne.

W jakich sytuacjach uwierzytelnianie poczty elektronicznej jest częściowo pomocne

Czego można, a czego nie można oczekiwać od uwierzytelniania poczty elektronicznej w tym przypadku

Protokoły DMARC, SPF i DKIM zostały stworzone z myślą o zapobieganiu fałszowaniu adresów, a nie wyciekom danych przez pracowników

Siła raportów DMARC w zakresie zapewniania widoczności

Chociaż nie zapobiegnie to pierwotnemu wstrzyknięciu kodu, dobrze opracowana konfiguracja uwierzytelniania wiadomości e-mail zapewnia niezbędny wgląd w sytuację. Sprowadza się to do szczegółowych raportów DMARC (RUA/RUF).

Po odpowiedniej konfiguracji rekordy te zapewniają przejrzysty obraz wszystkich adresów IP i usług wysyłających działających w Twojej domenie. Raporty zbiorcze (RUA) podsumowują wolumeny wysyłek według źródła, natomiast raporty o błędach (RUF) zawierają szczegółowe informacje na temat poszczególnych awarii. Jeśli Twój zespół SecOps na bieżąco monitoruje te strumienie, może wykryć nagłe, niewyjaśnione skoki w wolumenach transakcji wychodzących. Śledzenie tych anomalii pełni rolę czujnika dymu, sygnalizującego, że w integracji dochodzi do wycieku danych.

Wprowadzenie mechanizmu zabezpieczającego połączonego z rygorystycznym egzekwowaniem przepisów

Przeniesienie domeny do trybu DMARC z rygorystycznym ustawieniem p=reject stanowi kluczową ochronę przed skutkami ubocznymi. Nie powstrzyma to wprawdzie wewnętrznego serwera MCP przed wysyłaniem danych w kopii ukrytej (BCC), ale uniemożliwi atakującym wykorzystanie skradzionych danych do szkodliwych celów. Polityka odrzucania uniemożliwia cyberprzestępcom wykorzystywanie wyciekłych faktur lub danych klientów do przeprowadzania wysoce ukierunkowanych, sfałszowanych kampanii phishingowych wymierzonych w Twoich klientów i partnerów przy użyciu Twojej rzeczywistej domeny.

Prawdziwa luka – dbanie o certyfikaty i uprawnienia

W gruncie rzeczy ta luka w zabezpieczeniach wynikała z nieprawidłowości w zarządzaniu tożsamością i dostępem, a nie z problemu z protokołem uwierzytelniania. Atak zakończył się sukcesem, ponieważ niezweryfikowane oprogramowanie uzyskało dostęp do legalnego klucza API o wysokich uprawnieniach.

Najskuteczniejszym zabezpieczeniem w tym przypadku jest kontrola zależności kodu oraz dbanie o bezpieczeństwo danych uwierzytelniających. Jednak wdrożenie autonomicznych narzędzi opartych na sztucznej inteligencji bez aktywnej warstwy monitorującej sprawia, że nie masz żadnego wglądu w sytuację. Ciągłe monitorowanie DMARC tworzy aktywną siatkę bezpieczeństwa niezbędną do wykrywania anomalii w zachowaniu, które mogą wskazywać na aktywny atak.

Jak chronić swoją organizację przed złośliwymi atakami e-mailowymi wykorzystującymi protokół MCP

Zapewnienie bezpieczeństwa poczty elektronicznej na serwerze MCP wymaga podjęcia następujących działań operacyjnych:

1. Sprawdź, ile miejsca zajmuje serwer MCP

Nie da się zabezpieczyć tego, czego się nie monitoruje. Sporządź szczegółowy wykaz wszystkich aktywnych integracji, wtyczek i punktów połączeń powiązanych z Twoją konfiguracją poczty.

• Sprawdź, czy integracja pochodzi z oficjalnego repozytorium dostawcy, czy też z niezweryfikowanego pakietu społecznościowego dostępnego na npm lub PyPI.
• Należy wyraźnie określić, z jakimi danymi i punktami końcowymi może współpracować każda integracja.
• Warto korzystać z narzędzi bezpieczeństwa typu open source, takich jak mcp-scan, aby zidentyfikować i przeanalizować środowisko pod kątem nieprawidłowości w zachowaniu.

2. Stosowanie zasady minimalnych uprawnień w integracjach poczty elektronicznej z AI

Przestańcie przyznawać narzędziom automatycznym nieograniczony dostęp administracyjny.

• Ogranicz zakres kluczy API tak, aby zezwalały one wyłącznie na dokładnie te czynności, które są konieczne (np. wysyłanie powiadomień), jednocześnie wyraźnie blokując pełny dostęp do skrzynki pocztowej w trybie odczytu i zapisu.
• Należy ściśle przestrzegać harmonogramów rotacji kluczy API i natychmiętnie unieważniać poświadczenia, jeśli któryś z komponentów zgłosi alert.
• Należy stosować zaporę sieciową i zasady bezpieczeństwa sieciowego w celu ograniczenia miejsc docelowych połączeń wychodzących z serwerów MCP oraz dołączyć do białej listy wyłącznie znane punkty końcowe firmowego interfejsu API poczty elektronicznej.

3. Włącz raportowanie DMARC i monitoruj występowanie nieprawidłowości

Jeśli nie analizujesz na bieżąco zbiorczych danych DMARC, masz poważną lukę w monitorowaniu operacyjnym. Wdrożenie dedykowanego narzędzia do analizy DMARC zapewni Twojemu zespołowi stały wgląd w sytuację, co pozwoli śledzić strumienie danych, określać poziomy referencyjne natężenia ruchu oraz otrzymywać powiadomienia o nagłych skokach liczby wysyłanych wiadomości transakcyjnych, zanim dojdzie do poważnych szkód.

4. Wprowadź ustawienie DMARC na p=reject

Pozostawienie domeny w słabej konfiguracji p=none nie zapewnia żadnej rzeczywistej ochrony. Przejście na rygorystyczny poziom egzekwowania p=reject gwarantuje, że nawet jeśli atakującemu uda się wykraść treść wiadomości za pośrednictwem zainfekowanego interfejsu integracyjnego, nigdy nie będzie mógł wykorzystać tych skradzionych danych do przeprowadzenia fałszywych kampanii naśladujących oficjalną domenę Twojej marki.

5. Sprawdź serwery MCP przed wdrożeniem

Każdy moduł serwera MCP należy traktować z taką samą starannością, jak każdy inny element infrastruktury korporacyjnej o uprawnieniach administracyjnych. Przed wdrożeniem do środowiska produkcyjnego należy sprawdzić historię wydawcy, porównać pakiety z oficjalną dokumentacją dostawcy oraz przeanalizować kod źródłowy.

Aby zminimalizować ryzyko, należy unikać surowych pakietów społecznościowych i korzystać wyłącznie z certyfikowanych, zweryfikowanych przez dostawców integracji. W przypadku zespołów wdrażających automatyzację sprawdzenie zweryfikowanych opcji dostawców, takich jak serwer PowerDMARC MCP, gwarantuje bezpieczną, uwierzytelnioną warstwę integracyjną stworzoną specjalnie z myślą o bezpiecznym funkcjonowaniu przedsiębiorstwa.

Szersza perspektywa – zabezpieczenia MCP będą miały decydujący wpływ na kolejny etap zagrożeń związanych z pocztą elektroniczną

Atak na bibliotekę postmark-mcp był z założenia mało skomplikowany: jeden programista, prosta sztuczka polegająca na dopasowywaniu nazw oraz pojedyncza linijka ukrytego kodu. A jednak doprowadził on do ujawnienia ogromnej ilości danych. W miarę jak firmy coraz szybciej wdrażają autonomiczne narzędzia oparte na sztucznej inteligencji, a MCP staje się standardem w architekturach oprogramowania, grupy hakerskie nieuchronnie będą przeprowadzać znacznie bardziej zaawansowane operacje.

Zespoły ds. bezpieczeństwa muszą przygotować się na kilka nowych wektorów zagrożeń:

• Pośrednie wprowadzenie poleceń: Atakujący wysyłają złośliwe wiadomości e-mail, których celem jest manipulowanie agentem AI obsługującym skrzynkę odbiorczą i nakłonienie go do błędnego przekierowania poufnych danych lub ujawnienia wewnętrznych kluczy.
• Złośliwe narzędzia do automatyzacji procesów: Atakujący udostępniają pozornie przydatne narzędzia do zwiększania wydajności oparte na sztucznej inteligencji, które w tle potajemnie zbierają dane logowania i tokeny.
• Podróbki o dużej wartości: wyrafinowane kampanie typu „typosquatting”, wymierzone w integracje systemów CRM, HR i finansowych dla przedsiębiorstw w sieciach pakietów programistycznych.

Poczta elektroniczna jest dość podatna na zagrożenia, ponieważ stanowi punkt styku komunikacji korporacyjnej, weryfikacji tożsamości (resetowanie haseł) oraz krytycznych danych biznesowych. Serwery MCP, łączące sztuczną inteligencję z tą infrastrukturą, mają dostęp do wszystkich tych elementów.

Wniosek

Zagrożenia związane z pocztą elektroniczną wykraczają obecnie daleko poza zwykłe ataki phishingowe z zewnątrz. Incydent związany z Postmark-MCP dowodzi, że organizacje mają obecnie do czynienia z zagrożeniami w łańcuchu dostaw opartymi na sztucznej inteligencji, które działają w ukryciu w zaufanych środowiskach wewnętrznych. Ataki integracyjne wykorzystują prawdziwe dane uwierzytelniające do ominięcia dotychczasowych filtrów, i właśnie dlatego kwestia zabezpieczeń poczty elektronicznej przed złośliwymi serwerami MCP powinna znaleźć się w planach działania każdego dyrektora ds. bezpieczeństwa informacji (CISO).

Ochrona przedsiębiorstwa wymaga znalezienia równowagi między rygorystyczną kontrolą uprawnień a ciągłym monitorowaniem danych. Połączenie surowej polityki egzekwowania zasad z dogłębnymi analizami raportów pozwala wykrywać nietypowe ilości wysyłanych danych oraz wykrywać nieautoryzowane integracje, zanim dojdzie do trwałej utraty danych.

Nie pozostawiaj swoich zautomatyzowanych systemów bez nadzoru. Już dziś zabezpiecz swoją domenę przed ukrytymi zagrożeniami na poziomie aplikacji. Sprawdź wszystkie źródła wysyłające wiadomości e-mail w imieniu Twojej domeny; rozpocznij monitorowanie za pomocą narzędzia DMARC Analyzer firmy PowerDMARC.

Najczęściej zadawane pytania

Chwileczkę, jeśli moje e-maile przechodzą weryfikację SPF i DKIM, to w jaki sposób jest to luka w zabezpieczeniach?

Ponieważ połączenie pochodzi z wnętrza budynku. Złośliwy pakiet nie podszywa się pod Twoją domenę z jakiegoś przypadkowego, nieautoryzowanego serwera. Znajduje się on bezpośrednio w Twoim zaufanym środowisku aplikacji i przejmuje Twoje prawdziwe, legalne klucze API. Dla reszty świata wygląda to tak, jakby Twój serwer wysłał tę wiadomość e-mail zgodnie z prawem, dlatego protokoły zabezpieczeń obwodowych nie blokują jej. Jest to problem związany z wyciekiem danych, a nie z podszywaniem się pod serwer.

Jeśli DMARC nie jest w stanie zapobiec wyciekowi danych, to po co w ogóle go włączać?

Pomyśl o zbiorczych raportach RUA DMARC jak o czujniku dymu w Twojej sieci. Jeśli serwer MCP zacznie po cichu wysyłać tysiące wiadomości operacyjnych w kopii ukrytej (BCC) do skrzynki odbiorczej podmiotu zewnętrznego, liczba Twoich wiadomości transakcyjnych gwałtownie wzrośnie. Jeśli aktywnie monitorujesz swoje źródła danych DMARC, ta nagła zmiana w natężeniu ruchu będzie rzucać się w oczy, dając zespołowi SecOps wczesne ostrzeżenie, by przeprowadził audyt aktywnych zależności kodu.

Nasz zespół potrzebuje narzędzi opartych na sztucznej inteligencji do przetwarzania wiadomości e-mail z działu pomocy technicznej. Jak możemy to zrobić w bezpieczny sposób, nie wyłączając całkowicie integracji?

Nie musisz blokować automatyzacji opartej na sztucznej inteligencji, wystarczy tylko zapewnić jej odpowiednie ramy. Po pierwsze, traktuj serwery MCP jak elementy infrastruktury wysokiego ryzyka: nigdy nie instaluj nieprzetworzonych skryptów ze społeczności bez uprzedniej weryfikacji kodu. Po drugie, ogranicz zakres kluczy API za pomocą bardzo szczegółowych uprawnień; jeśli agent ma jedynie wysyłać odpowiedzi z działu pomocy technicznej, zablokuj jego token API tak, aby fizycznie niemożliwe było wykonywanie operacji masowego odczytu danych, tworzenia kont lub reguł BCC. Wreszcie, trzymaj się sprawdzonych integracji dostawców, takich jak serwer PowerDMARC MCP, zamiast niezweryfikowanych klonów społecznościowych.

Jak sprawdzić, czy mój zespół programistów przypadkowo zainstalował złośliwy serwer MCP?

Pierwszym krokiem jest przeprowadzenie skanowania w ramach analizy składu oprogramowania (SCA) lub skorzystanie z narzędzi open source, takich jak mcp-scan, w celu sporządzenia mapy aktualnego środowiska. Przyjrzyj się dokładnie publicznym rejestrom pakietów, takim jak npm i PyPI, w poszukiwaniu bibliotek społecznościowych innych firm, które obsługują Twoje kanały komunikacyjne. Jeśli biblioteka nie została bezpośrednio opublikowana i podpisana przez zweryfikowanego dostawcę korporacyjnego, takiego jak oficjalne repozytorium Postmark lub bezpieczny serwer PowerDMARC MCP, traktuj ją jako zagrożenie, dopóki kod nie zostanie ręcznie zweryfikowany.

• O
• Latest Posts

Milena Baghdasaryan

Specjalista ds. treści w PowerDMARC

Milena jest wykwalifikowaną pisarką i twórczynią treści z ponad 7-letnim doświadczeniem w tworzeniu angażujących treści na temat IT, cyberbezpieczeństwa, wirtualnych wydarzeń i nie tylko. Ma udokumentowane doświadczenie w dostarczaniu wysokiej jakości prac dla międzynarodowych magazynów i jest absolwentką prestiżowych instytucji, takich jak New York University Abu Dhabi, UWC China i College of Europe.

Najnowsze posty autorstwa Milena Baghdasaryan (zobacz wszystkie)

• Jak wybrać dostawcę usług poczty elektronicznej: ramy oceny oparte na priorytecie bezpieczeństwa – 1 lipca 2026 r.
• Bezpieczeństwo poczty elektronicznej w Ameryce Łacińskiej: Stan wdrożenia protokołu DMARC i uwierzytelniania wiadomości e-mail w Ameryce Łacińskiej w 2026 r. – 30 czerwca 2026 r.
• Nadużywanie legalnej infrastruktury: technika phishingowa pozwalająca ominąć uwierzytelnianie wiadomości e-mail – 30 czerwca 2026 r.