에이전트 워크플로 주입(CVE-2026-44246)에 대한 재현 가능한 취약 및 수정된 GitHub Actions 픽스처로, 측정된 탐지기 커버리지와 완화 지침을 제공합니다.

이것은 템플릿 주입이 아니다. 어떤 것도 셸로 평가되지 않는다. 페이로드는 산문이며, 인터프리터는 모델이다. 그래서 일반적인 조언 — 변수를 인용하고 eval하지 말라 — 이 적용되지 않으며, 아래의 수정이 입력 이스케이프가 아니라 에이전트가 무엇에 도달할 수 있는지에 관한 것인 이유이다.

알아둘 가치가 있는 부분: 수정 커밋이 수정이 아니다

nnU-Net은 이 워크플로를 두 개의 커밋으로 강화했으며, "이전"과 "이후"를 이진으로 취급하는 탐지기는 중간 것을 잘못 판단한다.

누구나 수정이라고 부를 커밋 — 그 메시지는 "hardened issue and PR agents" — 은 gh issue edit를 제거하고 라벨을 .github/scripts/safe-label.sh를 통해 라우팅했지만, Bash(gh issue comment:*)를 에이전트에게 남겨두었다. 에이전트는 여전히 댓글을 달도록 조종될 수 있었고, 허용 목록 패턴 gh issue comment:*는 트리거한 이슈로 범위가 한정되지 않으므로 대상은 모델이 선택하는 것이었다. 세 번째 커밋만이 그것을 닫았다: 이제 에이전트는 /tmp/issue-comment.md를 작성하고, 이후의 비에이전트 단계가 이벤트에서 가져온 ISSUE: ${{ github.event.issue.number }}로 그것을 게시한다.

두 가지가 따라오며, 이것이 이 저장소가 단지 두 개의 파일이 아닌 이유이다:

"수정됨"은 버전이 아니라 리비전에 대한 주장이다. v2.4.1이 수정된 릴리스로 인용되지만, 그 .github/workflows/에는 codespell.yml만 들어 있다 — 에이전트 워크플로는 그 태그에 전혀 없다. 태그로는 수정을 검증할 수 없다; 커밋을 고정해야 한다.

권한 블록은 절대 변하지 않는다. issues: write는 세 리비전 모두에, 마지막 것을 포함하여 존재하고 올바르다, 왜냐하면 이후 단계가 그것을 필요로 하기 때문이다. permissions만을 기준으로 삼는 탐지기는 리비전 1과 리비전 3을 구분할 수 없다. 그것들을 구분하는 것은 에이전트가 무엇을 호출할 수 있는가이다.

측정된 커버리지

세 가지 탐지기, 두 픽스처와 세 개의 실제 리비전 모두에 대해 실행. 전체 원시 출력과 도구 버전은 results.md에 있다.

여기서 어떤 탐지기도 단순히 "틀린" 것이 아니다 — 그것들은 서로 다른 질문에 답한다:

• zizmor는 범용 Actions 감사기이다. 세 리비전 모두에 대해 고정된 액션과 자격 증명 지속성 위생을 동일하게 보고한다. 설계상 이 클래스의 범위 밖이며, "잘 알려진 린터가 취약한 파일에서 깨끗했다"는 것이 쉽게 건강 증명서로 오인되기 때문에 포함되었다.
• sisakulint는 목적에 맞게 만들어진 AI 규칙을 가지고 있으며, 여기서 CVE 자체의 메커니즘을 명명하는 유일한 도구이다: ai-action-prompt-injection은 이슈 본문이 prompt:에 보간되는 취약 리비전에서 발동하고, 보간이 사라지면 멈춘다. 정확하다. 이후 리비전에 대한 그 발견들은 그것에 따라 행동하기 전에 읽어볼 가치가 있다 — ai-action-excessive-tools는 Write를 지적하는데, 이 워크플로는 이후 단계가 게시하는 파일을 작성하기 위해 의도적으로 그것을 사용한다; 그리고 ai-action-execution-order는 에이전트를 마지막에 두기를 원하는데, 이는 이 설계가 정확히 피하는 것이다, 왜냐하면 권한 있는 단계들이 모델의 차례가 끝난 뒤에 오기 때문이다.
• agentbound는 작업의 permissions가 아니라 에이전트의 도구 허용 목록을 읽음으로써 리비전 2와 리비전 3을 구분하는 유일한 도구이다. 그 ci-agent-missing-author-association 발견은 이후 리비전에서 critical로 보고되며, 자체 README는 그것을 거짓이 아니라 과도하게 심각한 것으로 설명한다: auto-triage는 누구나 도달할 수 있도록 의도된 것이다.

여기 모든 도구는 작성자가 이미 그 정확한 조건에 대해 숙고한 리비전에 대해 보고하는 발견을 가지고 있다. 그것이 휴리스틱의 정상 상태이며, 커버리지 표가 통과/실패 열보다 더 유용한 이유이다.

사용하기

benchmark.sh는 누락된 탐지기를 조용히 건너뛰는 대신 누락으로 보고한다, 왜냐하면 도구를 조용히 생략하는 커버리지 표는 그것에 대해 아무것도 증명하지 못하기 때문이다.

픽스처는 축소된 형태이며, 이 저장소를 위해 작성되었고 나머지와 마찬가지로 MIT 라이선스이다. 그것들은 복사본이 아니라 메커니즘에 충실하다: fixtures/vulnerable.yml은 네 가지 조건과 그 외 아무것도 담고 있지 않으며, fixtures/fixed.yml은 중요한 여섯 가지 변경이 각각 주석 처리된 같은 파일이다. 규칙을 추가한다면, 그 두 파일이 그것이 올바르게 처리해야 하는 가장 작은 입력이다.

두 가지 인터페이스 특이점, 스크립트에서 처리되지만 알아둘 가치가 있다:

• sisakulint는 git 저장소 밖의 파일을 분석하지 않는다. 하나를 넘기면 not found를 출력하고 3으로 종료한다. 주시하지 않으면, 그것은 깨끗한 스캔과 동일하게 보인다.
• agentbound의 JSON path는 basename이다, 따라서 같은 이름의 파일들에 대한 디렉터리 스캔은 모호하다.

수정하기

탐지는 쉬운 절반이다. **docs/mitigations.md**는 나머지 절반을 다룬다: 에이전트의 권한을 어떻게 제한할 것인가, 계층을 한 가지 질문으로 순위 매기며 — 이 통제는 모델이 따르기로 선택하는 것에 의존하는가?

그 순위 매김이 핵심이다. 프롬프트 내의 지시는 입력이지 가드 절이 아니다; 대상을 명명하는 도구 패턴, 또는 에이전트가 결코 보유하지 않는 토큰은 경계이다. 이 가이드는 "모델이 잘못된 일을 할 수 없다"에서 "모델에게 하지 말라고 요청했다"로 내려가며, 체크리스트와 nnU-Net의 진화를 실제 예시로 제시한다.

fixtures/fixed.yml은 여섯 가지 변경 각각에 그것이 구현하는 계층을 그리고 그것이 하중을 지탱하는지 여부를 태그한다 — 그중 둘은 그렇지 않으며, 독자가 그 파일을 과대평가하지 않도록 그렇게 표시되어 있다.

출처

런타임에 커밋 SHA로 가져오며, 절대 벤더링하지 않는다:

nnU-Net 구성의 어떤 사본도 여기에서 재배포되지 않는다; 가져오기를 다시 실행하고 위의 blob들과 바이트를 직접 비교하라.

범위

이것은 탐지 엔지니어링 산출물이다. 익스플로잇을 포함하지 않으며, 여기의 어떤 것도 실제 워크플로에 대해 테스트되지 않았다 — 취약 리비전은 정적 파일이며, 이미 nnU-Net의 이력에 공개되어 있고 공개된 권고에 의해 참조된다. 픽스처는 do not deploy로 표시되어 있는데, 그것들은 복사되기 위해서가 아니라 탐지되기 위해 존재하기 때문이다.

이 클래스에 대한 탐지기를 유지 관리하며 표에 행을 추가하고 싶다면, 벤치마크 스크립트가 인터페이스이다: targets에 대해 도구를 실행하고 그 발견을 출력하는 섹션을 추가하면, 픽스처와 고정된 리비전이 나머지를 해준다.

MIT.