Най-интересното

Данни изтичат всеки ден. Понякога това са имейли и пароли. Понякога – пълни сканове на паспорти.

Разследване на Financial Times показа, че над 700 паспорта и държавни лични документи на участници в Abu Dhabi Finance Week са били достъпни онлайн чрез незащитено cloud хранилище на външен доставчик. Сред засегнатите има бивш премиер на Великобритания, ръководители на хедж фондове и криптокомпании. Данните са били публично достъпни поне два месеца, преди сървърът да бъде защитен.

Почти паралелно CBS News разказа различен, но показателен случай от Калифорния. Мъж разбира, че самоличността му е използвана за регистрация като шофьор в Uber, когато получава данъчни формуляри за близо 7 000 USD доход, който никога не е изкарвал. Приходите са отчетени на негово име и с номера на социалната му осигуровка (еквивалентът на ЕГН в България). Следват блокиране на кредити, загубено време в обяснения пред IRS (американският НАП) и доказване, че „доходът“ е измамен.

Двата случая са различни по мащаб, но показват една и съща уязвимост: когато изтекат чувствителни идентификационни данни – паспорт, лична карта, ЕГН – рискът не е само репутационен. Той е пряко измерим в пари и загубено време.

Пълен скан на паспорт може да се използва за откриване на акаунти, кандидатстване за работа, регистрация в платформи или изграждане на убедителни phishing атаки. А когато приходите се „генерират“ на твое име, институциите очакват ти да платиш данъците – докато не докажеш обратното.

Това е реалността на 2026 г.: течове има постоянно. Разликата е в тежестта на последствията. Имейлът може да се смени. Паспортът и идентичността – много по-трудно.

Cloudflare преживя сериозен глобален срив на 18 ноември 2025 г., довел до недостъпност на множество сайтове по света. Проблемът започна малко след 13:20 часа българскореме, когато прокси инфраструктурата на компанията започна да връща 5xx грешки. Причината не беше кибератака, а вътрешна грешка: промяна в база данни, която генерира неправилно оформен файл за модул за управление на бот трафик. Файлът става значително по-голям от обичайното и предизвика сривове в няколко подсистеми. Резултатът:

По-технически, Cloudflare обяснява, че промяна в правата в ClickHouse е довела до дублиране на редове в данните, от които се генерира файл с характеристики за ML модел, използван от компонента Bot Management. Тъй като този файл надхвърля допустимия размер, разпространението му е предизвикало сривове в техните FL/FL2 проксита — централните компоненти, които обработват глобалния трафик. Проблемът се е разпространил бързо по мрежата, което е довело до масовите грешки при крайни потребители.

Възстановяването е започнало с блокиране на генерирането на проблемния файл, връщане към стабилна версия и рестартиране на прокси слоевете. Към 19:06 часа бълагрско време услугите на Cloudflare са били напълно възстановени. Компанията определя инцидента като „неприемлив“ заради ролята си в глобалната интернет инфраструктура — това е най-големият им срив от 2019 г. насам.

За крайните потребители инцидентът показа колко силно дигиталната екосистема зависи от единични точкови доставчици. Макар Cloudflare да остава една от най-стабилните платформи в света, подобни вътрешни грешки не могат да бъдат изключени напълно — особено в среди с автоматизирани CI/CD процеси и сложни ML-базирани компоненти.

Затова препоръчваме на организациите да мислят за диверсифициране на риска:

1. разделяне на DNS, CDN и WAF функциите по различни доставчици;
2. резервен CDN или локален кеш при критични приложения;
3. редовни симулации „доставчикът е недостъпен“ и ясни процедури за комуникация при инциденти.

Макар абсолютна защита да не съществува, многослойната архитектура значително намалява въздействието на подобни глобални сривове.

В края на миналата седмица забелязахме критична zero-day уязвимост (CVE-2025-8570 с оценка 9.8) в REST API на плъгина BeyondCart (BeyondCart Connector), която позволяваше неавтентикирани заявки да достъпват и модифицират данни за потребители. При определена последователност това може да доведе до ескалиране на привилегии и сдобиване с администраторски акаунт в сайта ви – както се случи в нашия казус.

Самата уязвимост е открита на 10 септември от потребителя kr0d и е публикувана в базите на WordFence и PatchStack. Лошото в случая е, че имаме доказателства, че се използва активно буквално от 11 септември, затова – още преди да продължите да четете, ъпдейтнете модула. 

Атаката протича на няколко етапа

1. първоначално разузнаване на публични endpoint-и (в нашия случай от Индонезия – пълен списък на IP адресите по-долу),
2. експлоатация с PUT заявка за промяна на администраторски акаунт (подмяна на имейл и парола)
3. последвано от вход в админ панела
4. деактивиране на BeyondCart Connector (хакерите не искат някой да ги надхака, явно)
5. инсталиране на WP File Manager и качване на модната версия на ядрото на WordPress, в която има persistent backdoor – class-action.php
6. модификация на functions.php на темата и добавка: скрипт за ексфилтриране на администраотски акаунти
7. прикриване на следите от атаката

Причината за казуса

Уведомихме веднага екипа на BeyondCart. Те потвърдиха проблема и вече са премахнали уязвимия код от публичното хранилище. Към момента плъгинът е временно недостъпен за изтегляне в WordPress.org, докато тече проверка.

Коренът на проблема е липсата на правилна последователност: автентикацията трябва да се валидира преди проверката на разрешенията за даден customer ID. В сегашната реализация endpoint-ът може да върне данни и за неаутентифицирани потребители, което отваря врата за по-нататъшна ескалация.

	public function user_permissions_check( $request ) {
		$id = (int) $request['id'];

		if(!isset($request['id'])) {
			$id = (int) $request['customer'];
		}
		

		if ( get_current_user_id() != $id ) {
			return new WP_Error( 'BeyondCart', __( 'Sorry, you are not allowed to do this.', "grind-mobile-app" ), array( 'status' => rest_authorization_required_code() ) );
		}

		return true;
	}

За какво да се оглеждате

1. Ако имате версия на плъгина, по-ниска от 3.Х и той е деактивиран, без да знаете защо – най-вероятно сте компрометирани
2. Провете администраторските акаунти – ако броят на администраторите, които виждате в списъка с потребители, не съвпада с този, който виждате до линка Администратори в таба – най-вероятно има компрометиран акаунт
3. Проверете директорията wp-content/plugins – ако в нея видите нещо като hide-user или hide-user.php, най-вероятно сте засегнати, а вътре ще видите потребителското име на вече създадения администратоски акаунт

Самият плъгин е делистнат без предупреждение от WordPress – които дори не са уведомили авторите му за уязвимостта (а може би трябваше, за да бъде своевременно отстранена). Според екипа разработчици, вече седмица се чака да се качи одобрената версия на модула в публичното репо с плъгини на платформата.

Какво да правите

Ако използвате BeyondCart, ъпдейтнете плъгина незабавно до версия 3.Х (може да я получите директно от авторите му, след като се свържете с тях тук). След това:

1. сменете всички администраторски пароли;
2. завъртете AUTH_KEY и SALT стойностите в wp-config.php (wp config shuffle-salts в WP CLI конзолата – като това ще изиска от всички ваши клиенти да се логнат);
3. активирайте двуфакторна автентикация а администратори;
4. сканирайте файловата система и базата за скрити потребители и непознати скриптове;
5. провете за заявки от следните IP адреси:2400:9800:16c:6071:e181:be8:5a56:ce88
   172.81.132.152

Поуката е ясна — дори „малки“ грешки в проверките могат да имат сериозни последствия, когато REST API е публично достъпен. Препоръчваме на всички клиенти да въведат мониторинг, WAF правила за ограничаване на PUT/POST заявки и одит на външните интеграции.

Един от най-масовите supply-chain инциденти в екосистемата на npm е в ход: акаунт на maintainer е компрометиран чрез фишинг („update your 2FA“) и през него са публикувани злонамерени версии на поне 18 популярни пакета, сред които chalk и debug. Сумарно те имат ~2 млрд. изтегляния седмично. Първите сигнали и технически разбори идват от Aikido, а в GitHub вече има потвърдени тикети за компрометирани версии (напр. chalk 5.6.1, debug 4.4.2).

Атаката започва с много правдоподобен имейл от домейна npmjs.help (а не npmjs.com), който „напомня“ за обновяване на двуфакторната автентикация. След като е взет контрол над акаунта, в пакетите е инжектиран код с цел кражба на крипто/уеб3 активност в браузър (cryptostealer). Някои версии са свалени, но рискът остава за екипите, които са обновили в последните часове.

Това е абсолютен wake-up call за всички организации – няма застраховани. Дори да не пишете JavaScript, ваши инструменти за билд, CLI-та или CI пайплайни вероятно стъпват върху Node/npm и могат да изтеглят уязвими зависимости автоматично. Следете официалните съвети и списъците с засегнати версии и проверете дали сте дърпали ъпдейти в последните 24–48 часа.

За разработчиците:

• прегледайте зависимостите и подзависимостите си, фиксирайте версии и разчитайте на lockfile-и (npm ci)
• ограничете/забранете postinstall скриптове в CI, генерирайте SBOM и наблюдавайте advisories
• Ротирайте npm/GitHub токени,
• активирайте 2FA навсякъде, за предпочитане passkeys, и потвърждавайте подобни съобщения само през директно отворен npmjs.com (не през линкове в имейл – между другото, и засегантият разработчик казва, че „по прицнип не кликам на линкове, но този път…“).

Уроците понякога идват по трудния начин – с реални загуби. Споделяме тази история с позволението на автора, Иван Давидов, който иска неговият горчив опит да послужи като предупреждение за други. В преследване на нова възможност, Иван участва в уж легитимен процес по наемане през LinkedIn – включващ интервюта, тестово задание и комуникация по заплащане. Всичко изглежда достоверно, докато не е помолен да свърже своя крипто портфейл към „тестов“ сайт. Малко след това губи 0.9 ETH (около 2500 USD), без нито едно подозрително действие от негова страна.

Скамърът изчезва, сайтът е свален, а профилът в LinkedIn е деактивиран. Иван подава сигнал до ChainAbuse и премества останалите си активи в хардуерен Ledger портфейл. Всеки, който борави с крипто, трябва да помни: дори технически грамотни хора могат да станат жертва на измама, когато социалното инженерство е умело поднесено. Никога не свързвайте портфейла си към непроверени сайтове – особено когато става въпрос за „тестове“ в процес на интервю.

Цялата история споделяме в поста на Иван:

Мобилните браузъри масово събират чувствителна информация за потребителите — но Chrome се откроява като най-агресивен. Данните са от прочуването Web Browser Privacy: What Do Browsers Say When They Phone Home? на Surfshark.

Chrome е единственият, който събира финансова информация, освен всички други категории лични данни. Изследването сравнява 10 популярни браузъра на Android и iOS, включително Safari, Firefox, Brave, DuckDuckGo и Opera.

Браузърът на Google събира 20 от възможните 55 типа данни, включително данни за местоположение, контакти, здраве, финансова активност и др. Впечатление прави, че Google използва тези данни както за „персонализация на продукта“, така и за „маркетингови цели“. Safari също не изостава значително, докато DuckDuckGo и Firefox събират значително по-малко — само 5 типа данни, и то основно за анонимна диагностика.

Изненадващият извод е, че повечето браузъри събират данни дори когато не е абсолютно необходимо. Brave, въпреки репутацията си, събира 2 типа данни (анонимизирани), включително идентификатори и данни за употреба. Edge и Opera, от своя страна, събират по 6 типа данни.

За потребителите в България, това означава, че дори интуитивният избор на „по-сигурен“ браузър невинаги означава реална защита. Ако използвате Chrome по подразбиране, вашите здравни, финансови и поведенчески данни може вече да се използват за таргетиране. Време е не само да преосмислим браузъра, а и да настояваме за по-ясна отчетност от страна на компаниите, които тихомълком превръщат поведението ни в продукт.

 

Ransomware атаките затвърждават позицията си като най-често срещата тактика за компрометиране на малки и средни бизнеси – и в България, и на глобално ниво. Макар и оскъдна, статистиката за страната ни показва, че пробиви не липсват, а ефектите от тях са мащабни. Същевременно, българският бизнес подценява сериозността на проблема, което може да доведе до по-сериозни щети при потенциален успешен пробив.

Глобални тенденции

• По данни на Sophos, рансъмуер атаките съставляват над 90% от инцидентите при средни предприятия и 70% при малки фирми през 2024 г. ​

• Атаките често се извършват от неуправляеми устройства, използвайки мрежови връзки за достъп до файлове, което затруднява откриването им от традиционните антивирусни решения.

• През 2024 г. са регистрирани над 317 млн. опита за рансъмуер атаки, като 32% от тях започват чрез непачнати уязвимости. ​

Ситуацията в България

• През 2024–2025 г. в България са регистрирани поне 9 жертви на рансъмуер атаки, включително Върховния административен съд, Smart Media Group и EasyPay

• Атаката срещу Smart Media Group през октомври 2024 г. води до изтичане на 40 GB чувствителни данни, като е използвана zero-day уязвимост

• Според проучване на Allianz, само 12% от българските компании определят кибератаките като основен бизнес риск през 2025 г., което ги поставя на 10-то място сред най-значимите заплахи

Рансъмуерът продължава да бъде сериозна заплаха за МСП както глобално, така и в България. Компаниите трябва да инвестират в проактивни мерки за киберсигурност, включително обучение на персонала, редовно обновяване на системите и използване на многослойни защитни решения.

След шест години разработки и амбициозни обещания за по-добра защита на личните данни, Google официално се отказва от инициативата Privacy Sandbox и плановете си за премахване на third-party cookies в браузъра Chrome. Решението бележи края на опита на компанията да наложи нови стандарти за онлайн реклама, съчетаващи ефективност и поверителност.

Какво беше Privacy Sandbox?

Privacy Sandbox стартира през 2019 г. като отговор на нарастващата критика към използването на third-party cookies за проследяване на потребителите. Инициативата предвиждаше нови технологии за таргетиране без директна идентификация — като FLoC (по-късно заменен от Topics API), Protected Audience API и Attribution Reporting API. Въпреки това, проектът срещна сериозен отпор от конкуренти, регулатори и организации за защита на личните данни.

Защо Google се отказва?

• Регулаторен натиск: Британският регулатор CMA, както и други институции, изразиха тревога, че Sandbox може да засили пазарната доминация на Google.
• Критики от индустрията: Рекламни платформи като Criteo предупредиха, че липсата на адекватна алтернатива може да нанесе щети на онлайн бизнеса и издателите.
• Технически предизвикателства: Въпреки многобройните тестове, предложените API-та не демонстрираха достатъчна ефективност и не убедиха индустрията.

Какво следва?

Вместо да премахне third-party cookies, Google ще предостави на потребителите избор дали да ги активират – една промяна, която звучи като победа за личната неприкосновеност, но на практика напомня добре познатите cookie банери в европейските сайтове.

Опцията съществува, но мнозинството потребители – в това число и в България – просто натискат „Разреши всичко“ без да четат, движени по-скоро от нетърпение, отколкото от разбиране. Това прави новия „избор“ в Chrome по-скоро формалност, отколкото реален инструмент за контрол. Google ще продължи работа по някои от Privacy Sandbox API-тата, но вече без амбицията да ги наложи като универсален стандарт за индустрията.

Отказът от Privacy Sandbox е знак за трудностите, пред които се изправя технологичната индустрия в опитите си да съчетае личната неприкосновеност с ефективна реклама. Google признава, че едностранни решения не могат да променят цялата екосистема — и засега, third-party cookies остават неизменна част от уеб пространството.

Meta обяви, че от 26 юни 2025 г. ще започне да използва публично достъпно съдържание от потребителите в Европейския съюз за обучение на своите AI модели. Това включва постове, коментари, снимки и описания, публикувани в Instagram и Facebook.

Решението ще засегне стотици милиони потребители, включително българските, чиито профили са публични или които имат публична активност в платформите. От компанията заявяват, че няма да използват лични съобщения или съдържание, споделено само с приятели.

Какво точно ще правят?

Meta ще използва данните за обучение на генеративни AI модели, включително чатботове и системи за препоръки. С други думи – публичното ви съдържание може да бъде използвано за подобряване на нещо като Meta AI, конкурент на ChatGPT.

Подобни модели изискват огромни масиви от данни, а Meta залага на „публичното, създадено от потребители съдържание“, за да се конкурира с Google и OpenAI.

Ще получим мейли

В следващите седмици потребителите в ЕС ще започнат да получават имейли от Meta с обяснение за новата политика. В тях ще има и възможност за отказ (opt-out).

За да се откажете, ще трябва да посетите специална страница с формуляр, озаглавен „Право на възражение“ (Right to Object). Meta е длъжна да го уважава съгласно GDPR, ако аргументите ви не са явно неоснователни.

Формулярът ще бъде достъпен и през настройките на профила в Instagram и Facebook, но ще трябва сами да го намерите и попълните.

Защо това е важно?

Решението отваря голям етичен и регулаторен дебат. Публичното съдържание не е непременно предназначено да се ползва за обучение на AI. Нито всеки потребител е дал съзнателно съгласие за това.

В България това вероятно ще доведе до първа вълна от откази – особено сред по-информираните потребители, фирми и инфлуенсъри. Дали Meta ще уважава напълно възраженията – предстои да видим. Но темата ще остане актуална и в контекста на новия AI Act на ЕС.

Когато става дума за кибератаки, никой не е застрахован. Дори най-големите експерти по киберсигурност.

Последният пример за това дойде миналата седмица. Създателят на Have I Been Pwned Трой Хънт разкри, че е станал жертва на една от най-старите измами в онлайн света – фишинг. Чрез автоматизирана атака, маскирана като известие от доставчика на бюлетини Mailchimp, измамниците са откраднали около 16 000 записа на настоящи и предишни абонати на блога му. Те включват имейл адреси, статуси на абонамент и IP адреси, както и данни за географската ширина и дължина.

Добрата новина е, че Хънт все пак незабавно е успял да разкрие атаката. Той описва случая 34 минути след като е станал жертва.

Какво се случва?

На 25 март Хънт получава фишинг имейл от името на Mailchimp. През платформата той изпраща по електронната поща новите материали от блога си на абонираните читатели. В имейла се твърди, че Mailchimp временно прекъсва услугата му, защото  е получила оплаквания за спам.

Фишинг имейлът е бил с убедителен дизайн и е заплашвал с последствия, ако получателят му не предприеме действия. Но, както казва Хънт, „преди това съм получавал милиарди подобни фишинг имейли, които съм идентифицирал рано“. Този път обаче хакерите успяват.

Едно от нещата, които карат Хънт да се замисли, е, че когато се опитва да влезе в профила си в Mailchimp през фишинг имейла, мениджърът му за пароли не попълва автоматично данните за профила му. Това не е червен флаг за пробив, но е хубаво да се има предвид.

След като осъзнава грешката си, Хънт веднага сменя паролата си и свързва с Mailchimp, за да помогне за изтриването на API ключа на измамника. След това той проверява дали уебсайтът, към който е бил насочен при фишинг атаката, е бил изключен.

Не на последно място, Хънт добавя информацията за пробива в списъка си в сайта Have I Been Pwned (HIBP). Платформата помага на хората да разберат дали са били жертва на нарушение на сигурността на данните.

„Когато разговарям с компании, които са нарушили сигурността на данните, моето послание е кристално ясно: бъдете прозрачни и експедитивни в докладването на инцидента и дайте приоритет на комуникацията с клиентите си“, казва Хънт. „Ако направя нещо по-малко от това, ще бъде лицемерно, включително и по отношение на начина, по който след това обработвам данните от нарушението, а именно добавянето им към HIBP“.

Бъдете внимателни за всякакви опити за фишинг, използващи данните от Have I Been Pwned като примамка.