Топ новини

И така. Със сигурност сте видели заглавията тази седмица. „Критична уязвимост в GitHub.“ „Един git push до RCE.“ „Милиони repo-та компрометирани.“ Това разбира се са обичайните фойерверки на cybersecurity пресата, само че в този случай пожарът е горе-долу пропорционален на фойерверките.

Премислям тази история от няколко дни, отчасти защото попада точно в зоната, в която стои ежедневната ми работа – Cyber Security и Code Review, Agentic платформи, но и отчасти защото начинът, по който този bug беше открит, според мен е по-голямата история от самия bug. Но ще стигнем и дотам.

Какво се случи, опитал съм се да го направя четимо, а не оформено като прес-съобщение, така че имайте търпение.

На 28 април 2026 г. Wiz Research публикуваха disclosure за CVE-2026-3854 – критична remote code execution уязвимост във вътрешната git инфраструктура на GitHub, засягаща github.com, GitHub Enterprise Cloud (във всичките му варианти, включително Data Residency и Enterprise Managed Users), както и GitHub Enterprise Server. CVSS 8.7. е открита от Sagi Tzadik и докладвана през bug bounty програмата на GitHub на 4 март. Следва Patch на github.com за по-малко от два часа от подаването на доклада и commit + deploy в GHES бранчовете до 10 март.

Механиката: всеки автентикиран потребител с push достъп до каквото и да е хранилище, включително прясно създадено, можеше да предизвика arbitrary command execution на GitHub сървър, обработващ неговия push, чрез “натъпкване” на специално конструирани options в една единствена git push команда. Крайния резултат върху github, code execution върху shared storage възли – тоест вашият push можеше да попадне на машина, на която също се съхраняват милиони чужди repo-та. Или иначе казано, пълно компрометаране на сървъра.

Forensic разследването на GitHub са показват, че няма exploitation от трети страни преди patch-а, и че няма достъп до клиентски данни. По-малко добрата новина обаче е, и причината да пиша това е, че когато Wiz направиха публичен проблема, около 88% от GitHub Enterprise Server инстанциите все още бяха на непачнати версии. Ако оперирате GHES, тези 88% вероятно включват и кутии, за които сте забравили, че въобще съществуват.

Какво всъщност е babeld – и защо този bug е толкова неудобен

Ако никога не сте се ровили в това как GitHub сервира git по мрежата, ето тридесетсекундната обиколка. Има парче вътрешна инфраструктура, наречено babeld. Това е proxy-то, което седи между git клиента (вие, на командния ред) и backend сървисите, които вършат истинската работа – repository storage, hooks, audit logging, access control. Всеки git fetch, всеки git clone, всеки git push минава първо през babeld. Това е входната врата към git.

Вътрешно сървисите на GitHub “не вярват” сляпо на каквото им подадете. Те си предават вътрешен metadata header между компонентите – наречен X-Stat. Това е semicolon-delimited блок и носи критичен за сигурността контекст, чрез който Rails средата обработва заявката, къде системата трябва да търси hooks, кой е автентикираният потребител. Обичайната купчинка от „нека верифицираме всичко на входната врата, така че downstream сървисите могат да са сигурни че оперират с проверен контекст.

Downstream сървисите третират X-Stat като евангелие. Защо? Защото е сетнат от babeld, който е вътрешен, което означава, че никой отвън не би трябвало да може да му влияе.

Точно това последно изречение е мястото, където всичко тръгва на криво.

Когато пуснете git push -o key=value, git протоколът праща тези -o push options към сървъра. Push options са допълнение и съществуват, за да позволят на CI системи, server-side hooks и подобни инструменти да предават малки парчета контекст с push-а. Напълно разумно. Проблемът е, че babeld взима тези контролирани от потребителя стрингове и ги залепва в X-Stat header-а буквално. Без escape. Без санитизация на semicolon символа – който е, ако си спомняте, същият символ, използван от X-Stat като разделител. Парсърът от своя страна надолу използва last-write-wins семантика: ако едно и също име на поле се появи два пъти, втората стойност печели.

Комбинирайте тези две неща и получавате header injection като по учебник. Потребителят контролира стринг, който влиза в delimited вътрешен header без санитизация, а консуматорът на този header третира инжектираните полетата като проверени, защото, доколкото може да прецени, babeld вече ги е сетнал.

Bug-ове с тази форма съществуват практически във всяка голяма вътрешна платформа – винаги има някакъв вътрешен протокол, в който доверени upstream сървиси залепват стрингове в delimited формат, а някъде надолу нещо ги обработва. Лошото в случая е, че babeld е бил толкова критичен толкова много години и никой извън GitHub не го е разглеждал или проверявал достатъчно усърдно, за да открие това.

Exploit chain-ът на човешки език

Tzadik премина от „мога да презапиша едно поле в X-Stat“ до „пускам мой двоичен код като git service потребител“ чрез навързване на три injected полета. Накратко:

Стъпка 1 – Излез от production sandbox-а. Ruby кодът на GitHub работи в production Rails среда по подразбиране с доста стегнати правила. С инжектиране на rails_env заявката се прехвърля в по-малко сигурна среда, и вижда пътища които нормално не са достъпни.

Стъпка 2 – Пренасочи откъде идват hooks-овете. Git сървърът на GitHub изпълнява pre-receive hooks по време на push, за да наложи политиките за опазване на съответния branch. Директорията, в която живеят тези hooks, нормално е фиксирана, заключена и доверена. Инжектиране на custom_hooks_dir казва на системата „не, гледай тук за hooks“ и я насочва към директория, върху която атакуващият има влияние.

Стъпка 3 – Спусни arbitrary code чрез path traversal. Последното поле, repo_pre_receive_hooks, пък се инжектира път, в стойността на който атакуващият насочва изпълнението към произволен двоичен код на сървъра. Pre-receive hook машинарията, вършейки си работата, изпълняваше този двоичен код като git service потребителя.

Три инжектирани разделителя. Един git push. Code execution на сървъра.

Как Wiz всъщност откриха това – и защо това е частта, която трябва да ви държи будни

Две неща се открояват в discovery историята, и второто, по мое мнение, е истинското заглавие.

Първо, babeld не е open source. Това е компилиран вътрешен GitHub двоичен код. Исторически, намирането на bug-ове с такава дълбочина в closed-source server изисква или внимателен ръчен reverse-engineering с месеци търпелива работа, или insider leak. Нито едното не scale-ва. Затова уязвимостите в код като babeld обикновено излизат или чрез fuzzing на протокола отвън, или защото някой отвътре го забелязва.

Wiz не направиха нито едното. Те използваха AI-augmented reverse engineering, конкретно tooling, изградено върху Model Context Protocol който прехвърля в IDA Pro – това, което хората сега наричат „IDA MCP“. Това им даде възможност да насочат LLM към компилирани двоични кодове, да го помолят да реконструира вътрешни протоколи и trust boundaries, и да проследи къде user input пресича тези граници, със скорост, която просто не беше възможна за човешки екип преди година-две.

Сега, ето защо мисля, че това е по-голямата история, защото все още милиони ако не и милиарди редове код, писани и забравени остават са все още уезвими и въпроса е не дали и кога, а колко скорострелно ще бъдат открити от AI augmented debugging и кой стои зад него.

IDA MCP инструментариума е един от няколко подобни подхода, които се изграждат точно сега. Кривата на разходите за „намери сериозен bug в затворен двоичен код, който никога не си виждал“ пада. Не е на нула и няма да бъде на нула, но е забележимо под нивото от преди осемнадесет месеца. И продължава да пада.

Другото нещо, което си струва да отбележим: AI не намери нова категория bug тук. Намери много стара категория – header injection чрез delimiter mishandling – на място, на което хората не се бяха сетили да погледнат. Което е реалният pattern, който очаквам, че ще виждаме през следващите няколко години. Не екзотични нови bug класове. Познати bug класове, намирани по-бързо, на повече места, от по-малки екипи.

Но нека се върнем обратно към конкретния проблем и какво трябва да направите, ако сте на GHES. Проверете първо с коя версията сте, сигурните версии, които ви интересуват, са 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6 и 3.19.3. GitHub също имат последващи releases (3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0 и нагоре), които включват този и други fix-ове. Каквото и да е по-старо от патчнатата версия на вашия branch, може да го считате за компрометирано. (въпреки че вероятно не е)

Сега, нещо, за което искам да съм честен: exploit-ът изисква push достъп до някое repo на target инстанцията. На типичен GHES deployment тази летва е толкова ниска, че е почти декоративна. Това са всички с разработчици. Това са контракторите. Това е онзи един външен фрийленсър, на когото сте дали write до едно repo преди три години сте го забравили. Това е всеки service account, чийто token е бил тихомълком разширен отвъд read-only, защото CI се е счупил и най-бързият fix е бил „дай му write“.

Одитирайте кой има push достъп до хранилищата на GHES. ДА, всичките.

Извадете GHES git server log-овете за exposure прозореца и потърсете git push -o активност от акаунти, от които не очаквате да използват push options, особено с option стрингове, съдържащи semicolons или странни символи.

Подновете всички secrets, signing keys, deploy keys или webhook secrets, които са лежали на GHES сървърите по време на exposure прозореца.

Стегнете blast radius-а за следващия път. GHES стои в много архитектури с прекалено широк достъп към продукционни CI, secret stores и artifact регистри. Третирайте го като high-value asset, какъвто е.

Ако сте само на github.com и не оперирате GHES, оперативната ви работа е горе-долу свършена – GitHub патчнаха за два часа, forensic заключението е успокояващо, а и без друго не сте можели да направите много в момента. Това, което все пак си струва да се направи, е да прегледате дали GitHub access tokens, OAuth apps и CI интеграциите имат повече привилегии, отколкото им трябва. Защото blast radius-ът от следващия github.com bug – а ще има следващ – ще се определя от това до какво вашите tokens имат право да докосват.

Повечето англоезични заглавия третират CVE-2026-3854 като US-сентрик: патчнете GHES, подновете tokens-ите… Всичко това е полезно, но не е цялата история,за тези които оперира в EU. От гледна точка на Брюксел този инцидент удря в поне четири регулаторни режима, които са влезли в сила или са се изострили през последните 24 месеца. Релевантният въпрос не е просто „бяхме ли експлоатирани?“ – той е „можем ли да демонстрираме на регулатор, че сме забелязали, реагирали и докладвали в срок?“

Сроковете за транспониране минаха, националните надзорни органи са активни и ясно дават да се разбере, че търпението им е свършило. Под NIS2 трябва да се докладват значими инциденти в рамките на 24 до 72 часа и финален доклад в рамките на месец. Релевантният въпрос за CVE-2026-3854 не е дали сте били експлоатирани, а дали можете да покажете, че сте оценили “проблема” и/или сте изключили възможността за експлоатиране с доказателства.

Но, нека се върнем отново стъпка назад от спецификите за момент. Формата на този инцидент е формата на модерния software-supply-chain риск в концентриран вид.

Все още има хиляди организации, чийто security model имплицитно приема, че „GitHub няма да го пробият“, и които на практика нямат готов отговор на „OK, но ако го пробият?“

Бъдете нащрек.

Пробивът в cloud инфраструктурата на Европейската комисия от края на март 2026 г. вече има по-ясен контекст – и той променя правилата на играта. Първоначалната новина очерта инцидент в инфраструктурата. Новите разкрития показват нещо по-съществено: атаката влиза през инструмент, създаден да защитава. Supply chain атака, която превръща доверието в уязвимост.

Как започва всичко: компрометиран инструмент

Разследванията свързват инцидента с Trivy – широко използван security scanner, интегриран в CI/CD процеси. Атаката таргетира GitHub Actions pipeline-и, което позволява компрометиране още на етап build.

Този модел променя класическата представа за пробив:

• атака се насочва към доверен инструмент
• инструментът се използва масово в автоматизирани процеси
• зловредният код се разпространява чрез легитимни pipeline-и

Резултатът е пробив, който изглежда като нормална дейност.

Повтарящ се модел: от ЕК до Cisco

Случаят с Европейската комисия се вписва в по-широка тенденция. Конкретно само атаката срещу Trivy вече засегна доказано и публично признато:

• LiteLLM – чрез сходен supply chain сценарий
• Cisco – с изтичане на сорс код от компрометирана среда

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

Домино ефектът в модерната киберсигурност

Supply chain атаките рядко спират до една организация. Един компрометиран компонент може да се разпространи в десетки среди за минути.

Как се разгръща ефектът

• един инструмент или библиотека се компрометира
• интеграцията в CI/CD разпространява промяната автоматично
• засегнати стават множество системи и организации
• детекцията се усложнява заради легитимния произход

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

Скоростта в ерата на AI

Развитието на AI ускорява както разработката, така и атаките. Времето между компрометиране и масово разпространение се измерва в часове.

Съвременната киберсигурност изисква баланс между скорост и контрол – бързи реакции, подкрепени от внимателна преценка.

Контекстът показва, че автоматизацията работи в две посоки – същите процеси, които ускоряват development-а, ускоряват и атаките.

Балансът между ъпдейти и контрол

Съвременните среди изискват навременни ъпдейти, за да се адресират zero-day уязвимости. В същото време автоматичното внедряване на всяка нова версия носи нов риск.

Случаите с Trivy и Axios показват двата края на спектъра:

• забавен ъпдейт увеличава риска от експлоатация
• неконтролиран ъпдейт увеличава риска от supply chain атака

Този баланс се превръща в ключова тема за всяка организация, която разчита на модерни DevOps практики.

Какво означава това за България

Българските компании все по-често използват CI/CD, cloud услуги и външни зависимости. Това поставя локалния бизнес в същата рискова категория като глобалните организации.

Екипи, които работят с:

• автоматизирани deployment-и
• open-source библиотеки
• външни security инструменти

се намират в директна зависимост от сигурността на глобалната supply chain.

Темата вече има пряко значение за българската ИТ екосистема и начина, по който се управляват зависимости и процеси.

Пробивът в Европейската комисия очертава (позната) нова реалност в киберсигурността, в която доверието към инструментите изисква същото внимание, както и самата защита.

• Навременните ъпдейти остават критични за защита от нови уязвимости
• Контролираното внедряване добавя слой сигурност срещу supply chain атаки
• Разбирането на зависимостите се превръща в стратегическо предимство

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

Всичко започва по начин, който за много от нас е напълно рутинен.

Контакт през LinkedIn.

Профилът изглежда „истински“ — няколко години история, технологичен бекграунд, снимка, умерена активност. Разговорът е премерен, професионален. Представят се като хора, които работят по иновативен проект и търсят team / tech / product lead, с когото да обсъдят PoC и архитектура.

Нищо агресивно. Нищо очевидно подозрително.

След кратък обмен идва следващата стъпка: „Можем да ти дадем достъп до repository с PoC, за да го разгледаш локално.“

И точно тук започва атаката.

PoC, който се изпълнява сам

Repository-то изглежда напълно легитимно.

Node.js backend, Express, структуриран код, .env, middleware, routes. Има README, инструкции как да се стартира проекта:

npm install
npm run dev

Но още при стартиране се случва нещо, което не трябва да се случва в нормално приложение:

• код се изпълнява още при load-ване на модул,
• без HTTP заявка,
• без user input,
• без логика, свързана с функционалността на приложението.

Това не е bug. Това е умишлено конструирана supply-chain атака.

Dropper, маскиран като middleware

Ключовият елемент е функция с невинно име – verifyToken. Подписът ѝ напомня Express middleware (req, res), но параметрите не се използват.

По-лошото: функцията се извиква директно, на top-level, още при import на модула.

Резултатът е следният:

1. При npm run dev Node.js зарежда routing файла
2. Там, без да чака заявка, се изпълнява verifyToken()
3. Функцията прави HTTP request към външен сървър
4. Получава JSON с поле token
5. Това поле се изпълнява чрез:

new (Function.constructor)('require', payload)

Това е еквивалент на eval, но:

• по-трудно се хваща със статични проверки
• позволява да се подаде require като аргумент

С други думи: пълен Remote Code Execution в контекста на разработчика.

C2 инфраструктура, скрита в .env и base64

Payload-ът не е в самото repository. Той се доставя динамично от C2 сървър, конфигуриран чрез:

• environment променливи
• разделени path компоненти
• base64-кодирани URL-и

Основният endpoint е хостнат на Vercel, вторичен – на отделен домейн с нестандартен порт. Това не е случайно. Това е класически подход за евтина, disposable инфраструктура, която може да се сменя често.

Payload-ът: обфусkиран infostealer, не demo код

Истинската изненада идва, когато разгледаме реалния payload, който C2 сървърът връща. Това не е „hello world“. Това е ~90KB силно обфусциран JavaScript.

Няколко ключови характеристики:

• зарежда child_process, fs, os
• регистрира handlers за uncaughtException и unhandledRejection, за да не се срине
• съдържа собствен string decoding engine с множество азбуки
• проверява execution environment
• подготвен е за асинхронни операции и допълнителни payload-и

Това не е експериментален код. Това е production-grade infostealer, насочен към разработчици.

Какво може да бъде откраднато

При подобен достъп атакуващият потенциално получава:

• SSH ключове (~/.ssh)
• .env файлове с API ключове
• cloud credentials
• Git tokens
• browser data (cookies, saved logins)
• крипто портфейли
• цялата среда, от която работиш

И всичко това – само защото си стартирал PoC, който някой ти е дал „да го разгледаш“.

Защо това напомня на Sha1-Hulud

Този тип атака ужасяващо много прилича на концепцията зад Sha1-Hulud – не защото е същото технически, а защото:

• не се вижда веднага
• движи се през JS екосистемата
• използва доверието и навиците на жертвата

Тук няма zero-day exploit. Няма brute force. Има социално инженерство + supply-chain + доверие в tooling-а.

Защо това е особено опасно

Тази атака не цели „крайни потребители“. Тя цели разработчици, архитекти, tech leads. Хора с:

• достъп
• знания
• ключове
• production системи

И го прави по начин, който заобикаля почти всички класически защитни механизми, защото:

• кодът изглежда легитимен
• payload-ът идва динамично
• няма очевидни индикатори при първичен преглед

Изводът

Ако някой ви пише с „интересен проект“ и ви праща repository:

1. не го стартирайте веднага
2. четете package.json, middleware-ите и top-level calls
3. търсете code execution при import
4. не вярвайте, че PoC означава безопасно

Supply-chain атаките вече не са абстрактен риск. Те са персонализирани, насочени и търпеливи.

И понякога започват просто с едно съобщение в LinkedIn.

Кредит на @Stan за сорса и помощта при анализа

Септември 2025 ще остане в историята като момента, в който автономните AI агенти преминаха от експеримент към реална оперативна способност — и то в ръцете на противника. Репорт на Antropic.ai (авторите на Claude) разкрива първата потвърдена мащабна кибератака, изпълнена почти изцяло от AI модел, използван като самостоятелен агент. Атаката, приписвана с висока степен на увереност на китайска държавно подкрепена група, показва фундаментална промяна в киберрисковете, индустрията и глобалния баланс на силите.

Инфлексията: когато AI започва да действа сам

В последните 18 месеца виждаме как големите езикови модели удвояват киберспособностите си на всеки шест месеца. Това, което досега беше “vibe hacking” — осезаема помощ на AI към нападатели — вече е еволюирало в нещо много по-мащабно: агенти, които сами изпълняват цялата верига на атаката.

Какво е различното този път

1. AI моделът изпълнява атаката, а не просто съветва как да се изпълни.
2. Човешкото участие беше ограничено до няколко ключови решения.
3. Моделът работи цял  екип, правейки хиляди заявки в секунда — скорост невъзможна за човешки оператори.

Атаката е обхванал около 30 световни организации, сред които технологични компании, финансови институции, химически производители и държавни агенции.

Според разследването, нападателите са успели да манипулират Claude Code — AI инструмент за разработчици — така, че той да се превърне в автономен хакерски екип.

Как протече атаката: новият kill chain в ерата на агентите

Атаката преминава през пет фази, всяка опираща се на три ключови способности, характерни за новото поколение AI: интелигентност, агентност, инструменти.

Фаза 1: Човекът дава идея, AI изпълнява

Операторите:

1. избират целите,
2. създават агентна рамка,
3. “убеждават” модела да извършва дейности, които иначе биха били блокирани от защитите.

Тук се използват класически jailbreak техники:

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

Фаза 2: Автономно разузнаване

Claude Code:

1. обхожда инфраструктурата,
2. идентифицира най-ценните бази данни,
3. картографира системи и потребители,
4. връща синтезиран доклад към оператора.

Прави за минути това, което на човешки екип би отнело дни.

Фаза 3: Намиране на уязвимости и писане на експлойтове

Тук AI:

1. открива пропуски в сигурността,
2. пише експлойт код,
3. тества payload-и,
4. изследва публични и вътрешни системи.

Моделът автоматично генерира код, валидира го и го адаптира — цикъл, който човешки екипи изпълняват ръчно и бавно.

Фаза 4: Ескалация и ексфилтрация

Claude:

1. краде потребителски имена и пароли,
2. ескалира привилегии,
3. създава бекдори,
4. изтегля данни,
5. категоризира ги по “разузнавателна стойност”.

Нивото на структурираност и автоматизация тук е безпрецедентно.

Фаза 5: Документация — за следващата кампания

AI автоматично създава:

1. отчет за пробива,
2. списъци с компрометирани акаунти,
3. карта на системите,
4. инструкции за повторна атака.

Това е първият случай, в който AI сам документира собствената си операция, за да оптимизира бъдещи атаки.

Защо тази атака е различна от всичко видяно досега

1. 80–90% автономност
   Това вече не е “помощник на хакер”. Това е хакерски екип, работещ със свръхчовешка скорост.
2. Скъсяване на цикъла
   Атаки, които изискваха седмици, сега се изпълняват за часове.
3. Демократизация на атаките
   Групи с малко ресурси вече могат да постигат резултати, достъпни по-рано само за държавно-спонсорирани организации.
4. Нова надпревара във въоръжаването
   Същите способности, които превръщат AI в атакуващ инструмент, го правят незаменим за защита:
   1. автоматизация на SOC,
   2. идентифициране на заплахи,
   3. анализ на логове,
   4. реакция при инциденти,
   5. масова обработка на телеметрия.

Този случай показва: без AI в отбраната няма как да се посрещнат AI в нападението.

Какво означава това за бизнеса, държавата и индустрията

1. Техническият дълг става национален риск
   Организации с остарели системи или разпилени данни ще бъдат първите жертви на следващото поколение AI атаки.
2. AI агентите променят kill chain-a
   Откриване – експлойт – ексфилтрация – документация: всичко може да бъде затворено в автономен цикъл.
3. AI-базираните SOC-ове стават задължителни
   Киберзащитата преминава към модели, които:
   1. анализират огромни масиви данни,
   2. откриват аномалии в реално време,
   3. автоматично ограничават щети.
4. Нови регулации и международни стандарти
   Ще видим:
   1. политики за управление на AI-агенти,
   2. сертифициране на модели,
   3. ограничения върху инструментите, достъпни чрез MCP.

Какво означава това за България

1. Българските компании вече са (ин)директни цели
   Глобални вериги за доставки, доставчици на услуги, ИТ аутсорсинг — всички стават входна точка за подобни кампании.
2. Изоставането става все по-лесно и все по-фатално
   Организации с неактуализирани системи и липса на 24/7 SOC са уязвими за автоматизирани атаки от такъв тип.
3. Шанс да реагираме навреме
   AI-базираната защита сега ви дава конкурентно предимство в бъдеще.
4. Образование и кадри
   Този случай подчертава нуждата от:
   1. локални SOC специалисти,
   2. AI-инженери,
   3. политики за безопасно внедряване на агенти в бизнеса.

Пълният доклад на Antropic.ai. прочетете тук.

Microsoft предупреди своите корпоративни и правителствени клиенти за активно експлоатирана уязвимост в локалната версия на SharePoint Server – една от ключовите платформи за вътрешна комуникация и документооборот. Уязвимостта е zero-day, което означава, че е била използвана активно от атакуващи преди да бъде официално открита и коригирана от разработчика.

CVE‑2025‑53770 и CVE‑2025‑53771 са „patch bypasses“ на предишни уязвимости (CVE‑49704 и CVE‑49706), които хакерите вече експлоатират, въпреки че бяха запушени само преди няколко седмици.

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

Засегнати са он-прем клиентите

Уязвимостта засяга конкретно Microsoft SharePoint Server 2019 и 2016, в конфигурации, където функционалността за управление на задачи и документи е активна. Microsoft вече публикува извънреден ъпдейт, а екипът на компанията подчертава, че експлойт кодът вече циркулира в реална среда – с други думи, няма време за отлагане.

Компанията призовава незабавно да се приложaт всички налични ъпдейти за поддръжаните операционни системи:

• Microsoft SharePoint Server 2019 (16.0.10417.20027)
• Microsoft SharePoint Enterprise Server 2016 (16.0.5508.1000)
• Microsoft SharePoint Server Subscription Edition
• Microsoft SharePoint Server 2019 Core
• Microsoft SharePoint Server 2016 (TBD)

Организации, които не могат веднага да ъпдейтнат, трябва да изолират сървърите си от публичен интернет достъп, като временна мярка. Microsoft също така активира разширено предупреждение към Defender for Endpoint и Defender for Identity, за да помага на администраторите да засекат ранни признаци на компрометиране.

Втора атака за 3 месеца

Важно е да се подчертае, че това е втори сериозен zero-day, насочен към on-prem Microsoft сървърен софтуер в рамките на три месеца – показател за нарастващия интерес на атакуващите към локално хоствани платформи, особено в организации с чувствителни данни или ограничен контрол над обновленията.

За българските организации, които все още използват локални инсталации на SharePoint, това е момент за действие. Независимо дали става дума за държавна администрация, университет, болница или частна компания – ъпдейтът трябва да бъде приоритет в следващите часове.

 

 

 

Ask ChatGPT

Паролите са навсякъде – на входа към социалните мрежи, имейла, онлайн банкирането, здравния портал и дори при поръчка на пица. Но те също са най-слабото звено в дигиталната сигурност. Лесни за отгатване, често повтаряни и масово изтичащи при пробиви – паролите са проблем, който интернет индустрията се опитва да реши от години. Днес имаме реално и широко поддържано решение: passkey.

Passkey е модерен, криптографски метод за удостоверяване

Той напълно заменя нуждата от традиционна парола. Вместо да въвеждате текст, системата използва криптирана двойка ключове: публичен, запазен от сайта, и частен, който остава защитен на вашето устройство. Самоличността ви се потвърждава чрез биометрия (пръстов отпечатък, Face ID) или PIN код, без да изпращате чувствителна информация онлайн.

Това означава:

• Няма как паролата ви да бъде фишната;
• Няма как да бъде използвана повторно при пробив;
• Няма нужда да я помните.

Passkeys не са просто „по-удобни от паролите“ – те елиминират основните им уязвимости.

Каква е разликата между парола и passkey?

Парола	Passkey
Запомня се и се въвежда ръчно	Потвърждава се с биометрия или PIN
Може да бъде фишната или изтекла	Невъзможно за кражба чрез фишинг
Използва се често повторно	Уникален за всеки сайт
Уязвима към guess & brute force атаки	Използва криптография с частен ключ

Когато създавате passkey

• Вашето устройство генерира криптографска двойка ключове;
• Публичният ключ се съхранява от уебсайта;
• Частният ключ остава при вас – заключен с биометрични данни или PIN.

Когато влизате:

• Сайтът изпраща challenge към устройството ви;
• Вие потвърждавате самоличността си;
• Устройството подписва challenge-a с частния ключ;
• Сайтът го проверява и ви допуска – без да се предава парола.

Миграцията към passkeys е изненадващо лесна

Особено ако използвате модерни устройства и синхронизирани профили. Ето няколко препоръчители стъпки, които да следвате:

1. Започнете с основните си акаунти

Платформи като Google, Apple, Microsoft, PayPal, eBay и TikTok вече поддържат passkeys. Влезте в настройките им и потърсете „Passkey“, „Security Key“ или „Passwordless Login“.

2. Използвайте подходящо устройство

Passkeys работят най-добре, когато:

• Имате смартфон или компютър с Touch ID, Face ID, Windows Hello или Biometric Prompt;
• Операционната ви система е актуална: iOS 17+, Android 14+, Windows 11+, macOS Ventura+.

3. Синхронизирайте ключовете си

Passkeys се съхраняват локално, но за удобен достъп на всички устройства се използва облачна синхронизация:

• Apple устройства → iCloud Keychain
• Android/Chrome → Google Password Manager

Може също да използвате външни мениджъри на пароли, които поддържат passkeys:

• 1Password
• Bitwarden
• Dashlane, Keeper и др.

Тези решения работят дори при смесена среда – например Android телефон и macOS лаптоп.

4. Изпробвайте вход с QR код

При липса на биометрия на компютъра можете да сканирате QR код със смартфона си – така влизате в акаунта сигурно, чрез Bluetooth и криптографски handshake.

5. Настройте поне две устройства с достъп

За по-голяма устойчивост при загуба на телефон/лаптоп, уверете се, че passkey е достъпна от поне две устройства, които синхронизират помежду си.

6. Изтествайте login процеса

Влезте от различни браузъри и устройства, за да усетите как работи passkey – в повечето случаи влизането е моментално, без писане.

Отговори на най-често задаваните въпроси за passkeys

Мога ли да използвам passkey на няколко устройства?

Да. Ако използвате синхронизираща услуга (напр. iCloud Keychain или Google Password Manager), passkey автоматично се прехвърля на други ваши устройства. Ако използвате външен мениджър (1Password, Bitwarden), синхронизацията зависи от неговите възможности.

Кой има достъп до passkey-а ми?

Само вие, чрез удостоверяване на устройството (биометрия/PIN). Частният ключ никога не напуска устройството. Дори ако хакер пробие уебсайта, той не може да получи вашия ключ или достъп до акаунта ви.

Мога ли да вляза от друго устройство?

Да. Повечето сайтове, поддържащи passkeys, предлагат вход чрез QR код – примерно, ако отваряте сайта на компютър без биометрия, можете да използвате телефона си за удостоверяване. Така пак използвате вашия passkey, без да го прехвърляте физически.

Какво става, ако загубя телефона или лаптопа си?

Ако passkey-те ви са синхронизирани през облачна услуга (Google, iCloud, 1Password и др.), ще ги възстановите лесно при влизане в ново устройство с профила си. Ако не използвате облак – трябва да имате резервно устройство или да настроите повторно достъп чрез акаунта си (при някои сайтове това значи fallback с имейл или телефон).

Последен ъпдейт на 5 май 2025 в 06:45 ч.

Microsoft прави важна крачка към решаването на един от най-големите проблеми в киберсигурността: как да осигурим едновременно удобен и труден за пробив достъп до дигитални акаунти.

Компанията започва поетапно да активира passkeys като метод за удостоверяване по подразбиране в своите акаунти – включително за Outlook, OneDrive и Windows. Първоначално промяната засяга новите потребители, а впоследствие ще обхване и съществуващите. Това отбелязва ключов завой в дългогодишната битка с уязвимите пароли.

Passkeys заместват паролата и MFA с двойка ключове

Passkeys са криптографски удостоверения, които заменят както паролите, така и допълнителните фактори (като SMS кодове). Работят с двойка ключове – публичен и частен – като частният остава защитен на устройството, а удостоверяването става чрез биометрия или PIN. Така се елиминират основни рискове като фишинг и повторна употреба на идентичности.

Технологията е базирана на отворените стандарти FIDO2 и WebAuthn, разработвани съвместно с Apple и Google. Microsoft вече поддържа синхронизация на passkeys през акаунти, а Windows Hello е съвместим с този метод и на мобилни устройства, и чрез хардуерни ключове.

Как работи и какво да направим

Passkeys се съхраняват в защитени среди като iCloud Keychain (при Apple), Google Password Manager или локално в TPM/secure enclave на устройства с Windows и Android. Те се синхронизират между устройствата през криптирана връзка и никога не напускат потребителския контрол.

За по-лесен преход Microsoft препоръчва първоначално добавяне на passkey към съществуващ акаунт (чрез „Sign-in options“) и използването му паралелно с традиционната парола, преди да се премине изцяло към новия метод.

Промяна и за бизнеса

Новата система засяга и за бизнес потребители: администраторите на Microsoft Entra ID (бивш Azure AD) могат да разрешат използване на passkeys в служебни акаунти. Това поставя основа за трансформация и в корпоративния свят, където досега се залагаше основно на сложни пароли и многофакторна автентикация.

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

Причината за тази трансформация, според Microsoft, е системният срив на доверието към паролите като защитен механизъм. Всяка година милиони акаунти на потребители като вас, които четете този текст, биват компрометирани именно заради слаби, повторно използвани или откраднати пароли.

Passkeys са замислени като дългосрочен отговор на този структурен проблем – по-лесни за използване, но фундаментално по-сигурни.

 

 

 

 

Deepfake технологията вече не е запазена само за лаборатории и изследователи. В ръцете на недобросъвестни лица тя се превърна в инструмент за измама и злоупотреба с доверието в медицинските професии. Кампания, открита от изследователи на ESET в Латинска Америка, разкрива как генерирани с изкуствен интелект „лекари“ използват TikTok и Instagram, за да промотират съмнителни хранителни добавки и „чудодейни“ терапии.

Видеоклиповете следват предвидим сценарий: привидно реалистичен лекарски аватар, поднесен с авторитетен тон, предлага съвети за здраве или красота, които завършват с препоръка за покупка на конкретен продукт. В един от случаите deepfake „лекар“ препоръчва „натурален екстракт“ като алтернатива на одобреното лекарство Ozempic за отслабване. Скрити зад професионален облик, тези видеа насочват потребителите към онлайн магазини, където се предлагат продукти без доказани ефекти или безопасност.

Технологията зад тези кампании е достъпна и законна – платформи за създаване на аватари, които позволяват качване на кратко видео и автоматично генериране на „реалистичен“ говорител. Тези инструменти лесно се използват за създаване на подвеждащо съдържание, което нарушава условията за ползване, но трудно се спира на практика. Изследователите идентифицират над 20 профила в TikTok и Instagram, използващи такива deepfake лекари за реклама на продукти, като понякога дори се имитира идентичността на реални медицински лица.

Подобни тактики вече се засичат и в България, включително фалшиви видеа с „лекари“, журналисти, известни личности и дори политици. Българските потребители трябва да бъдат особено бдителни, тъй като deepfake съдържанието става все по-убедително и често се използва за реклама на съмнителни продукти или политическо влияние. Разпознаването на измами е трудно, но критично – симптоми за deepfake са несинхронизирани устни, неестествено поведение, генерализирани послания и прекалено обещаващи твърдения.

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

Лични данни на над 100 хил. потребители на услугата за състоянието на републиканската пътна мрежа LIMA, както и на над 1 000 служители на Агенция „Пътна инфраструктура“ (АПИ), са източени. Това твърдят неизвестни хакери, които са споделили извадка от данните с екипа на NOVA NEWS.

Според предоставената информация, изтеклите данни включват имена, телефонни номера, имейл адреси и информация за превозни средства.

АПИ отрича да е имало пробив в системата LIMA и уточнява, че мобилното приложение към нея не функционира от над пет години. По данни на агенцията, дори когато е било активно, приложението не е изисквало въвеждане на лични данни. В момента системата е достъпна единствено чрез уеб браузър и не изисква регистрация.

Въпреки това, проверка на NOVA NEWS установява, че част от предоставените от хакерите данни принадлежат на реални лица.

Засега няма официално потвърждение за мащаба на евентуалния пробив, но случаят подчертава необходимостта от засилена киберсигурност и повишена бдителност при съхранение на лична информация. ГДБОП вече води разследване.