Zoom отстрани серия от уязвимости във функцията си за анотации, които теоретично биха могли да позволят на участник във видеоконференция да манипулира устройството на друг участник. Изследователската фирма, която откри проблема, казва, че са били необходими по-малко от 20 заявки към публично достъпни ИИ-модели и по-малко от 24 часа работа, за да се изгради работеща демонстрационна версия на експлойта.

Какво точно беше намерено?

Уязвимостите са свързани с три уязвимости в механизма за анотации на Zoom – функцията, която позволява на участниците в срещата да рисуват или оставят текстови маркировки върху показвания екран. Изследователи от A Security установиха, че начинът, по който се обработват данните за такива анотации, съдържа грешки в паметта.

Най-сериозната от трите, CVE-2026-53413, беше класифицирана от Zoom като препълване на буфера с дистанционно изпълнение на код и оценена на 8.3 по скалата на CVSS – ниво „Високо“, а не „Критично“. Другите две уязвимости са по-малко сериозни: CVE-2026-53414 (оценена с 6.5) само позволява на приложението на друга страна да се „срине“, а CVE-2026-53415 е отделен бъг „използване след освобождаване“ (use-after-free) със същото високо ниво от 8.3.

Клиентите на Zoom на всички основни платформи, като Windows, macOS, Linux, Android и iOS бяха установени като уязвими.

„Zero-click“ – твърдение от изследователите, но непотвърдено от самия Zoom

Самата агенция за сигурност нарече откритието „Zoomday“ и го представи като атака, която не изисква никакви действия от страна на жертвата: достатъчно е просто да участва в конферентен разговор. Звучи наистина драматично и именно така историята беше подхваната от множество публикации.

Но тук си струва да се направи уговорка. Официалните технически вектори на CVSS, публикувани от самия Zoom за всичките три уязвимости, посочват взаимодействието с потребителя като необходимо условие (User Interaction: Required), което пряко противоречи на обявения формат „zero-click“. Тоест, колко „незабележима“ би била една реална атака е въпрос, по който оценките на производителя и изследователите се различават. Това не означава, че проблемът не е сериозен: високият резултат в CVSS и самият факт на евентуално изпълнение на код на устройството на някой друг остават реални. Но формулировката „достатъчно е просто да сте на линия“ трябва да се възприема като версия на изследователите, а не като ясно потвърден факт.

Какво теоретично би могъл да направи един нападател?

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

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

Ролята на изкуствения интелект и тук също има нюанс

Това е може би най-интересната част от историята. Според A Security, целият цикъл от анализа на протокола за анотациите до изграждането на работещ код, демонстриращ атаката е отнел по-малко от ден и по-малко от 20 заявки към публично достъпните AI-модели.

Тук си струва да се направи разлика между две версии за това какво точно е направил изкуственият интелект. В собствения си доклад A Security го представя доста смело – сякаш моделите сами са открили уязвимостта. В по-подробни технически обяснения се казва нещо различно: изследователят ръчно е анализирал собствения протокол на Zoom, а моделите на изкуствения интелект са помогнали за ускоряване на отделни етапи, за да се определи кои функции на кода трябва да се проверят първо и по-бързо да се разбере логиката на обработка на данните. Тоест, изкуственият интелект значително е ускорил изследването, вместо самостоятелно да „разбива“ Zoom от началото до края.

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

Zoom вече пусна кръпка

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

Това не е единствената сериозна уязвимост на Zoom това лято

Историята с анотациите не е продължение на друг нашумял проблем, който Zoom затвори месец по-рано. През юли компанията пусна пач за CVE-2026-53412, който представлява наистина критична уязвимост с CVSS резултат от 9.8, която засегна клиентите на Zoom Workplace и VDI Client за Windows и теоретично позволи на неудостоверен нападател да поеме контрола над чужд Zoom акаунт през мрежата без никакви действия от страна на жертвата. Струва си да се уточни, че в преработената версия на бюлетина от 15 юли Zoom премахна Meeting SDK от списъка със засегнати продукти, така че тази уязвимост вече не засяга Meeting SDK, противно на заявеното в първоначалните данни.

Тоест, през лятото на 2026 г. Zoom трябваше да отстрани няколко сериозни проблема от различен тип едновременно – критична уязвимост в акаунта през юли и поредица от проблеми с анотациите през август.

Какво да направите сега, ако имате Zoom?

Най-простото и най-важно нещо, което трябва да направите, е незабавно да актуализирате Zoom до най-новата версия. Това е особено вярно в корпоративните среди, където приложението е инсталирано на голям брой устройства.

Няма причина да се предполага, че всеки потребител на Zoom е бил автоматично засегнат, тъй като това вече е закърпена уязвимост, а не потвърдена масова атака. Основното практическо послание на тази история е различно: ИИ-инструментите вече значително намаляват времето, необходимо за превръщането на техническите проблем в работеща уязвимост, и следователно както компаниите, така и разработчиците трябва да вземат това предвид, когато реагират на подобни сигнали.