GitHub із 2 грудня обмежить pull_request_target у публічних репозиторіях

Із 2 грудня 2026 року GitHub за замовчуванням блокуватиме запуск GitHub Actions за подією pull_request_target у публічних репозиторіях. Як пише Хабр, командам, яким потрібні такі робочі процеси, доведеться окремо дозволити цю подію в політиках Actions. Спочатку обмеження планували запровадити 2 листопада, але термін перенесли на місяць.

Чому під обмеження потрапила ця подія

pull_request_target використовують для автоматизації роботи із запитами на внесення змін, зокрема тими, що надходять із форків. Робочий процес може, наприклад, призначити мітку або додати коментар. Нове правило стосується не цих дій як таких, а умов, у яких виконується робочий процес.

Він працює в контексті основного репозиторію й може отримати доступ до його секретів. Якщо при цьому робочий процес запускає неперевірений код зі стороннього форку, зловмисник потенційно може викрасти секрети або втрутитися в роботу CI/CD. GitHub обмежує запуск за замовчуванням, але залишає можливість зберегти цю подію для робочих процесів, яким вона справді потрібна.

Сам дозвіл не усуває ризику: важливо й те, які дії виконує робочий процес після запуску.

Терміни переходу й кого торкнеться правило

Зараз політика працює в режимі оцінювання — evaluate: робочі процеси й далі запускаються. Адміністратори вже можуть відкрити Policy insights у налаштуваннях GitHub Actions і побачити, які з них перестануть виконуватися після ввімкнення блокування. Так наслідки зміни можна перевірити заздалегідь, не чекаючи постійного обмеження.

До 2 грудня GitHub двічі тимчасово ввімкне блокування: 9 і 16 листопада 2026 року, щоразу з 16:00 до 18:00 UTC (19:00–21:00 за московським часом). У ці години робочий процес, на який поширюється нове правило, не запуститься. Замість виконання GitHub створить запис про невдалий запуск із повідомленням про помилку. Після кожного такого періоду політика знову перейде в режим оцінювання.

Із 2 грудня блокування стане постійним за замовчуванням. Зміна стосується публічних репозиторіїв на GitHub Free, GitHub Team і GitHub Enterprise Cloud. Приватних і внутрішніх репозиторіїв вона не торкнеться; на GitHub Enterprise Server нове правило також не поширюється. Тому починати перевірку варто з публічних репозиторіїв, де робочі процеси використовують саме pull_request_target.

Що перевірити команді сайту

Якщо сайт розробляють у публічному репозиторії, до 9 листопада варто переглянути Policy insights у налаштуваннях GitHub Actions. Зараз успішний запуск робочого процесу ще не означає, що він працюватиме й після 2 грудня: режим оцінювання показує майбутні обмеження, але поки не зупиняє виконання.

Після перевірки можна розглянути кожен робочий процес, якого торкнеться зміна, з огляду на його завдання:

• Якщо pull_request_target не потрібен, перейти на pull_request там, де це можливо.
• Якщо без цієї події завдання не вирішити, залишити її дозволеною в політиці лише для тих файлів робочих процесів, яким вона справді потрібна.
• Якщо робочий процес запускати не слід, зберегти блокування за замовчуванням.

Для розробників перевірка не закінчується налаштуванням політики. GitHub рекомендує не виконувати неперевірений код зі сторонніх запитів на внесення змін, коли йому доступні секрети репозиторію або привілейований GITHUB_TOKEN. Дозвіл події повертає можливість запуску, але не робить таке поєднання безпечним. Питання захисту секретів важливе й поза межами цієї зміни: у блозі вже розповідали про чинні секрети, виявлені в публічних репозиторіях GitHub.

Власникам сайтів і маркетологам необов’язково розбиратися в синтаксисі робочих процесів. Достатньо запитати команду, чи є в публічному репозиторії запуски за подією pull_request_target і чи перевірено, що з ними станеться 9 і 16 листопада, а потім — із 2 грудня. Якщо така автоматизація бере участь у роботі із запитами на внесення змін, краще дізнатися про необхідність правок до невдалого запуску.

Моя думка: спочатку спростити, потім дозволяти

Я б не вмикав виняток лише заради збереження попередньої поведінки. Спочатку варто з’ясувати, навіщо робочому процесу саме pull_request_target і чи можна обійтися pull_request. З мого досвіду, рішення з меншим рівнем доступу простіше перевіряти й підтримувати, ніж виняток, про причину якого команда з часом може забути.

Якщо подія все-таки потрібна, я б обмежив дозвіл потрібними робочими процесами й окремо переглянув, що вони роблять із кодом зі сторонніх форків. Тут корисно обговорити рішення всередині команди: політика визначає, чи може робочий процес запуститися, а його безпека залежить ще й від того, що він виконує та до чого отримує доступ.

Джерела

Звідки новина. Текст — переказ своїми словами, факти — з джерела, думка — автора.

1. GitHub с 2 декабря начнёт блокировать pull_request_target в публичных репозиториях habr.com

Про автора

Руй Сілва

досвідчений full-stack-розробник

Розробляю вебсервіси й допомагаю командам не ускладнювати архітектуру завчасно. Часто пояснюю молодшим колегам, чому просте рішення іноді надійніше за модне.

Усі публікації автора