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

Уязвимости

Орен Йомтов, изследовател по сигурността в Terra Security, започва да проследява дефектните корекции, след като екипът му постоянно се сблъсква с тях в собствената си работа през изминалата година.

„Издава се коригиращо обновяване, открива се начин за заобикаляне и се пуска нова корекция. Притеснени, че това може да е субективно отклонение в извадката, прегледахме всеки публикуван CVE запис и всяко бюлетинно известие в GitHub за един повтарящ се модел: пуска се корекция, а по-късно известие посочва, че тя е непълна или може да бъде заобиколена.“

„Данните потвърдиха нашето предположение“, пише той. „Дефектните корекции бяха докладвани в продължение на години с нисък, постоянен темп до 2026 г., когато делът на корекциите с отворен код в GitHub, по-късно обявени за дефектни, скочи около осем пъти.“

Експлоатираните грешки и защитите с блокиращи списъци се провалят най-често

Корекциите за уязвимости от каталога на CISA за известни експлоатирани уязвимости (KEV) по-късно биват докладвани като неефективни около четири пъти по-често в сравнение с корекции за други грешки от същите доставчици. Вероятната причина според Йомтов е повишеното внимание, тъй като активно експлоатираните грешки привличат повече хора, които анализират корекцията за сигурност и откриват пропуснатото от нея.

Класовете уязвимости, при които обичайното решение е списък с блокирани входни данни — като фалшифициране на заявки от страна на сървъра (SSRF) и замърсяване на прототипа (prototype pollution) — се появяват значително по-често сред непълните корекции, отколкото сред записите за CVE като цяло. Когато блокиращият списък не предвиди всяка възможна форма на зловредни входни данни, на атакуващия му е необходимо само да намери един вариант, който успява да премине, обяснява Йомтов.

Roundcube, софтуерът за уеб поща с отворен код, е показателен пример. През март 2026 г. неговите разработчици отстраниха уязвимост от тип SSRF (CVE-2026-35540) чрез блокиране на връзки към частни адреси, но проверката пропусна други начини за изписване на същия адрес, както и имена на домейни, които водят към него. Затварянето на тези пропуски изискваше още три CVE, публикувани през май, юли и август.

През февруари 2026 г. Microsoft отстрани уязвимост CVE-2026-21510 в Windows Shell, която групата APT28 експлоатираше активно. Впоследствие Akamai установи, че корекцията може да бъде заобиколена чрез манипулиран елемент в Control Panel, принуждаващ Windows да се свърже със сървър на атакуващия и да извлече NTLM хеша на потребителя. Microsoft коригира уязвимостта от заобикаляне през април като CVE-2026-32202, като този недостатък също попадна в списъка на CISA с експлоатирани уязвимости. Новото известие изобщо не споменава по-ранния CVE запис.

Съвети за разработчици и специалисти по киберсигурност

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

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

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