В релизе Linux 7.2, вышедшем 16 августа 2026 года, обнаружили около 1500 уязвимостей, тогда как в Linux 7.0 их было примерно 1000, а в Linux 6.0 в 2022 году знали лишь о 500. Для тех, кто привык считать открытый код автоматически более прозрачным и потому более безопасным, это неприятное напоминание: уязвимости Linux копятся не только в новых патчах, но и в старых участках ядра, куда разработчики могут не заглядывать годами.
Как пишет CNews, резкий рост связан не с внезапным ухудшением качества разработки, а с тем, что сообщество начало массово применять нейросети для анализа исходников ядра. Машинные инструменты быстро прогоняют десятки миллионов строк и добираются до кода, который раньше просто не доходили руки проверять. В результате цифра известных проблем растет от релиза к релизу, и уже звучат прогнозы, что к выходу Linux 7.3 счет может перевалить за 2000.
Сам по себе этот скачок выглядит тревожно, но его важно правильно читать. Речь не о том, что за несколько месяцев ядро внезапно стало в полтора раза опаснее. Скорее, ИИ подсветил то, что давно лежало в кодовой базе и не считалось приоритетом для ручной проверки. В 2026 году ядру Linux исполнилось 35 лет, а его объем превысил 40 млн строк кода. Такой проект неизбежно несет исторический багаж: старые драйверы, редко используемые подсистемы, фрагменты, которые когда-то добавлялись под конкретное железо и с тех пор почти не трогались.
Отсюда и главный парадокс этой истории. Нейросети находят проблемы не только там, где код меняли вчера, а как раз в местах, которые десятилетиями жили на периферии внимания. Это ломает удобный миф, что безопасность open source гарантируется самим фактом открытости. Открытый код действительно можно проверить, но это еще не значит, что его кто-то проверял достаточно глубоко и регулярно. Если огромная часть ядра долгое время существовала в режиме «не сломалось и ладно», то уязвимости Linux могли спокойно пережить не один цикл релизов.
При этом паниковать и срочно переписывать инфраструктуру под другую ОС причин пока нет. В материале подчеркивается, что многие найденные проблемы относятся к низкому приоритету, нередко сидят в малоизвестных драйверах и иногда оказываются ложными срабатываниями самих ИИ-инструментов. И это, пожалуй, самая приземленная часть всей истории. Нейросеть умеет находить подозрительные места быстрее человека, но не умеет снять с команды обязанность разбирать результаты, отсекать галлюцинации и решать, что действительно несет риск эксплуатации, а что останется лишь шумом в очереди багов.
Для мейнтейнеров ядра это уже не академический спор, а вполне операционная перегрузка. Один из разработчиков, Якуб Кичинский, прямо заявил, что команда «полностью перегружена». Для Linux 7.3 из 648 предложенных патчей от трети до половины составляют исправления низкого приоритета, доработки и уточнения, инициированные ИИ. Иными словами, автоматизация не только помогает искать проблемы, но и создает новый поток работы: кто-то должен проверять, воспроизводить, обсуждать и либо принимать, либо отклонять этот вал предложений. Для крупных open source-проектов это уже новая статья расходов, даже если формально речь не о деньгах, а о времени и внимании людей.
Отдельный эффект история дала в споре о поддержке старого железа. Именно устаревшие драйверы и древние сетевые куски кода оказались особенно удобной добычей для ИИ-сканеров. В апреле 2026 года разработчик Эндрю Ланн предложил удалить почти 28 тыс. строк старого сетевого кода, связанного с оборудованием эпохи ISA и PCMCIA. Логика проста: если этими интерфейсами почти никто не пользуется, а сопровождение тянет на себя ресурсы и приносит новые поводы для исправлений, то совместимость начинает стоить слишком дорого. На этом фоне из Linux 7.3 уже собираются убрать старые драйверы SGI, IBM и ряд других устаревших компонентов.
Для российских ИТ-команд тут есть вполне практический вывод. Если компания строит продукты, инфраструктуру или устройства вокруг Linux, ей придется внимательнее смотреть не только на CVE-карточки и стабильность релизов, но и на состав собственного ядра, драйверов и модулей. Уязвимости Linux в старом, малоиспользуемом коде особенно неприятны для тех, кто тянет за собой длинный хвост совместимости: промышленное оборудование, встраиваемые системы, сетевые решения, кастомные сборки под специфическое железо. Чем больше в такой сборке исторического наследия, тем выше шанс, что ИИ найдет там проблему раньше, чем команда успеет ее хотя бы заметить.
Следующий вопрос уже не в том, сможет ли ИИ найти еще больше дыр, а в том, как сообщество и вендоры научатся жить с этим потоком. Если автоматический анализ продолжит вытаскивать старые ошибки быстрее, чем люди успевают разбирать отчеты, ядро Linux придется не только латать, но и упрощать: вырезать мертвый код, сокращать зоопарк устаревших драйверов и пересматривать саму цену обратной совместимости.