WordPress 7.1.2 закрывае захоп сайта — выпраўленне дайшло нават да 4.7

Паводле нататкі WordPress пра выпуск, 22 верасня 2026 года выйшла версія 7.1.2, якая закрывае CVE-2026-87902; выпраўленне перанеслі ў галінкі аж да 4.7. Памылка дазваляе нападніку без уліковага запісу падключыць лакальны PHP-файл па-за каталогамі актыўнай тэмы. Калі супадуць умовы на серверы і ў тэме, гэта можа прывесці да выканання кода і захопу сайта.

Пагроза ўжо выйшла за межы апісання ўразлівасці: паводле назіранняў Patchstack, першы падазроны запыт дасягнуў яе ахоўнага трафіку 22 верасня ў 11:49 UTC, а ў 15:34 з’явілася спроба запісаць файл праз pearcmd.php. У абнаўленні ад 23 верасня кампанія апісала далейшыя спробы запісу PHP-файлаў. Гэтыя назіранні паказваюць актыўныя атакі, але асобны падазроны запыт у журнале яшчэ не даказвае захоп канкрэтнага сайта.

Калі абыход шляху дазваляе выканаць код

Праблема ўзнікае пры выбары шаблону старонкі: WordPress можа выйсці за межы каталогаў актыўнай тэмы і падключыць іншы лакальны PHP-файл. Афіцыйнае апісанне ўразлівасці называе неабходную ўмову ў тэме: у актыўнай бацькоўскай або даччынай тэме павінен быць каталог верхняга ўзроўню, назва якога пачынаецца з page-, напрыклад page-templates. Сярод тэм з такой структурай названыя Twenty Twelve, Twenty Fourteen, Neve, Hestia і Sydney.

Для наступнага кроку нападніку патрэбны прыдатны лакальны PHP-файл, які існуе на серверы і даступны для чытання ўліковаму запісу вэб-сервера. Адзін з апісаных сцэнароў выкарыстоўвае pearcmd.php пры ўключанай наладзе PHP register_argc_argv: тады аргументы з запыту могуць трапіць у падключаны скрыпт. Такім чынам, наяўнасць уразлівага ядра сама па сабе яшчэ не азначае, што на дадзеным серверы ўдалося выканаць код.

Наяўнасць патрэбнага каталога ў тэме таксама не даказвае паспяховай атакі. Аднак ацэньваць рызыку толькі па назве тэмы нельга: важныя і фактычная структура актыўнай тэмы, і файлы ды налады канкрэтнага сервера. Патч закрывае памылку ў ядры, таму абнаўленне патрэбнае і тады, калі вядомы сцэнар з pearcmd.php на сайце не спрацоўвае.

Якія галінкі атрымалі патч

Для сайта на старой галінцы не абавязкова спачатку пераходзіць на найноўшую асноўную версію: для ўразлівасці выпушчаны асобныя выпраўленыя версіі. Афіцыйны пералік ахоплівае галінкі ад 7.1 да 4.7; ніжэй паказана мінімальная выпраўленая версія для кожнай з іх. Параўноўваць трэба поўны нумар усталяванага ядра, бо дзве першыя лічбы не адрозніваюць уразлівы выпуск ад выпраўленага.

• 7.1 → 7.1.2; 7.0 → 7.0.6.
• 6.9 → 6.9.9; 6.8 → 6.8.10; 6.7 → 6.7.9; 6.6 → 6.6.9; 6.5 → 6.5.12; 6.4 → 6.4.12; 6.3 → 6.3.12; 6.2 → 6.2.13; 6.1 → 6.1.14; 6.0 → 6.0.16.
• 5.9 → 5.9.18; 5.8 → 5.8.17; 5.7 → 5.7.19; 5.6 → 5.6.21; 5.5 → 5.5.22; 5.4 → 5.4.23; 5.3 → 5.3.25; 5.2 → 5.2.28; 5.1 → 5.1.26; 5.0 → 5.0.29.
• 4.9 → 4.9.33; 4.8 → 4.8.32; 4.7 → 4.7.37.

Для галінак 4.6 і старэйшых такога патча ў пераліку няма. Выпраўленне для 4.7 таксама не азначае, што старая галінка зноў атрымала поўную падтрымку: актыўна падтрымліваецца апошняя версія WordPress. Таму абнаўленне ў межах старой галінкі закрывае гэтую канкрэтную памылку, а пераход на актуальную версію ядра патрабуе асобнага планавання.

Як абнавіць сайт і праверыць аўтаабнаўленне

Дазволенае фонавае аўтаабнаўленне яшчэ не гарантуе, што патч ужо ўсталяваны. Спачатку паглядзіце поўны нумар версіі ў панэлі WordPress і супастаўце яго з выпраўленай версіяй сваёй галінкі. Калі нумар стары, абнаўленне трэба запусціць; калі доступам да ядра кіруе хостынг-правайдар, удакладніце ў яго фактычную версію ўстаноўкі.

1. Стварыце рэзервовую копію базы даных і файлаў сайта, у тым ліку актыўнай тэмы і загружаных медыяфайлаў. Захоўвайце яе так, каб яна заставалася даступнай, калі сам сайт перастане адкрывацца.
2. У раздзеле «Абнаўленні» праверце, ці ўжо змянілася версія пасля аўтаматычнай устаноўкі. Калі не, запусціце абнаўленне ядра праз панэль WordPress або працэдуру свайго хостынгу.
3. Пасля ўстаноўкі яшчэ раз праверце поўны нумар версіі. Адкрыйце галоўную і некалькі ўнутраных старонак, якія выкарыстоўваюць шаблоны актыўнай тэмы, каб заўважыць магчымыя праблемы сумяшчальнасці.

Копія дапамагае аднавіць працаздольнасць сайта, калі абнаўленне выкліча збой, але не вырашае пытанне папярэдняга ўзлому. Калі нападнік ужо змяніў файлы або ўліковыя запісы, адно ўсталяванне новага ядра не прыбярэ гэтыя змены. Таму пасля тэхнічнай праверкі абнаўлення патрэбны асобны агляд слядоў атакі за час, калі сайт працаваў без патча.

Што шукаць у журналах і файлах пасля абнаўлення

У журналах доступу найбольш карысна шукаць спалучэнне параметраў pagename і page_id, а таксама кадзіраваныя паслядоўнасці пераходу ў бацькоўскі каталог у значэнні pagename. Падазронымі будуць звароты да pearcmd.php і аргументы config-show або config-create. Варта ўлічыць запыты POST: патрэбныя параметры могуць знаходзіцца ў целе запыту, таму аднаго прагляду адрасоў у журнале бывае недастаткова.

Адказ з незвычайным змесцівам PHP-файла паказвае больш, чым проста спробу звароту: ён можа сведчыць, што падключэнне файла спрацавала. Сама наяўнасць параметраў у запыце паказвае толькі намер нападніка. Захавайце адпаведныя журналы перад зменамі на серверы, каб можна было звязаць час запытаў з магчымым з’яўленнем файлаў або зменай налад.

• Параўнайце файлы актыўнай тэмы з даверанай копіяй і звярніце ўвагу на нечаканыя PHP-файлы. Асобна праверце часовыя каталогі /tmp і /var/tmp, дзе назіраліся спробы запісу.
• Праглядзіце адміністратараў і іншыя ўліковыя запісы з шырокімі правамі. Невядомы ўліковы запіс, змена пароля або правоў пасля падазронага запыту патрабуюць расследавання.
• Калі выявіце старонні файл, спачатку захавайце яго і звязаныя журналы для аналізу. Выдаленне без фіксацыі можа знішчыць сведчанні таго, што адбылося на сайце.

Калі выяўлены запіс старонняга PHP-файла або несанкцыянаваныя змены, сайт трэба разглядаць як магчымы інцыдэнт: вызначыць межы доступу нападніка і аднаўляць файлы ды ўліковыя запісы з даверанага стану. Абноўленае ядро закрывае вядомы шлях для новых спроб, але стан сайта пасля ранейшай атакі вызначаецца вынікамі гэтай праверкі.