기술 분석 · Apache DolphinScheduler
Task Group API의 프로젝트 권한 확인 누락
CVE-2026-57590에서 확인된 Apache DolphinScheduler Task Group의 프로젝트 권한 경계와 공개된 수정 권고를 설명합니다.
Task Group 권한이 적용돼야 하는 범위
인증된 DolphinScheduler 사용자가 해당 API에서 연관된 프로젝트에 대한 권한을 제대로 확인하지 않는 상태로 Task Group 작업을 수행할 수 있었습니다. Apache는 2026년 9월 24일 이 인가 오류를 CVE-2026-57590으로 공개했습니다. 출발점은 관련 Task Group 기능을 사용할 수 있는 계정이며, 빠진 판단은 그 작업이 영향을 미치는 프로젝트에 접근할 권한이 있는지에 관한 것입니다. Apache 권고문.
제가 확인하려던 것은 그 권한의 범위였습니다. Task Group 기능을 사용할 권한이 있다고 해서 그 작업에 연관된 특정 프로젝트에 대한 권한까지 생길까요? 한 프로젝트를 운영하는 Alice와 유효한 계정은 있지만 Alice의 프로젝트에는 접근할 수 없는 Mallory를 생각해 보겠습니다. 인증은 Mallory가 누구인지 확인할 뿐, Alice의 프로젝트가 Mallory의 권한 범위 안에 있다는 사실까지 확인하지는 않습니다.
당시 조사에서는 소스 검토와 서비스 수준 검사를 로컬 3.4.2 애플리케이션 검증과 함께 진행했습니다. 서비스 검사는 그보다 이른 개발 스냅샷을 사용했으므로 배포된 3.4.2 패키지에 대한 검사로 취급해서는 안 됩니다. 애플리케이션 관찰은 로컬 3.4.2 환경에서 얻었습니다. 이 글을 준비하면서는 해당 기록과 공개 소스를 검토했으며, 취약점을 새로 재현하거나 수정 릴리스의 런타임을 시험하지 않았습니다.
프로젝트 관계를 따라가기
DolphinScheduler 3.4.2 소스는 Task Group을 프로젝트와 연결하고 프로젝트를 고려한 인가 검사도 포함합니다. 따라서 프로젝트 접근 권한은 화면만 보고 추정한 제한이 아니라 이 구성요소 안에서도 의미 있는 경계였습니다.
기존 requireProjectPerm 보조 함수는 방어 방식의 기준을 보여줍니다. dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/service/impl/TaskGroupServiceImpl.java에서 이 함수는 프로젝트와 로그인한 사용자의 관계를 조회합니다. 관리자와 프로젝트 소유자에 대한 경우를 처리한 뒤, 관계가 없으면 접근을 거부합니다.
ProjectUser projectUser = projectUserDao.queryProjectRelation(project.getId(), loginUser.getId());
if (projectUser == null) {
log.warn("User {} does not have operation permission for project {}", loginUser.getUserName(),
project.getCode());
throw new ServiceException(Status.USER_NO_OPERATION_PROJECT_PERM, loginUser.getUserName(),
project.getCode());
}
이는 공개된 수정 코드가 아니라 3.4.2에 이미 존재하던 코드입니다. 보조 함수의 전체 구현은 프로젝트 접근 권한과 쓰기 권한도 구별합니다. 이 구별이 중요한 이유는 프로젝트와 관계가 있다는 사실만으로 그 안의 리소스에 대한 모든 작업이 허용되는 것은 아니기 때문입니다.
이제 두 판단을 나눠 볼 수 있습니다. 기능 인가는 Mallory가 특정 종류의 작업을 사용할 수 있는지를 묻습니다. 프로젝트 인가는 그 작업을 실제 Task Group과 연결된 프로젝트에 적용할 수 있는지를 묻습니다. 이 보조 함수는 작업이 올바른 프로젝트와 필요한 권한을 전달해 호출할 때에만 두 번째 질문에 답합니다. 같은 서비스의 다른 부분에 이 함수가 있다는 사실만으로 모든 Task Group 작업이 이 경계를 적용한다고 볼 수는 없습니다.
과거 소스와 로컬 관찰은 이 프로젝트 경계가 일관되게 유지되지 않는다는 우려를 뒷받침했습니다. 위 코드는 기존 권한 모델을 설명하며, Apache 권고문은 문제가 있는 Task Group API에서 필요한 프로젝트 권한 확인이 빠졌다는 공개된 판단을 제공합니다. 다만 권고문이 영향을 받는 모든 작업 경로를 하나씩 설명하는 것은 아닙니다.
더 넓은 권한이 의도된 것인지 검토
검토할 만한 다른 설명은 Task Group 권한이 의도적으로 프로젝트 전반에 적용된다는 것이었습니다. 그런 정책이라면 인가 검사 간 차이를 취약점으로 판단하기 전에 설명할 수 있어야 합니다. 프로젝트 연결과 보조 함수만으로는 의도한 정책이 확정되지 않습니다. 실제로 전역 관리자에게는 프로젝트를 넘나드는 작업이 허용될 수 있기 때문입니다.
핵심은 Alice와 Mallory가 서로 다른 계정이라는 사실이 아니라, Mallory에게 Alice의 프로젝트에 대한 권한이 없다는 점입니다. 당시 로컬 검증은 이 경계에 대한 우려를 뒷받침했지만, 로컬 동작만으로 벤더가 의도한 권한 정책까지 확정할 수는 없었습니다. Apache의 CVE 기록은 프로젝트 권한 확인 누락을 잘못된 인가(CWE-863)로 분류합니다. 이 공개된 평가는 문제가 있는 작업에 프로젝트 경계가 적용돼야 했음을 확인해 줍니다.
확인된 영향의 범위
근거가 뒷받침하는 결과는 인증된 사용자가 프로젝트 경계를 넘어 허가되지 않은 Task Group 작업을 수행할 수 있다는 것입니다. 당시 로컬 조사로는 배포 환경에서 관련 권한이 얼마나 흔히 부여되는지 측정하지 못했고, 실제 운영 환경의 다양한 구성에서 같은 동작을 확인하지도 못했습니다. 인증되지 않은 접근, 원격 코드 실행, 시스템 전체 장악으로 영향을 확대할 근거도 없습니다.
심각도 평가의 출처도 구분해야 합니다. Apache는 수치 점수 없이 낮음(Low)으로 평가했고, CISA-ADP는 높음 8.1(CVSS 3.1)을 부여했습니다. 두 평가는 모두 공개된 CVE 데이터에 기록돼 있습니다. 8.1은 CISA-ADP의 평가이지, 당시 로컬 관찰에서 확인된 영향의 범위를 넓히는 근거는 아닙니다.
프로젝트 권한 검사 복원
Apache는 3.4.3 이전 버전이 영향받는다고 밝히고, 문제를 해결한다고 설명한 3.4.3으로 업그레이드할 것을 권고합니다. 이는 벤더의 공개된 수정 권고입니다. 이 글은 독립적으로 확인한 수정 차이나 수정 릴리스의 런타임 검증 결과를 제시하지 않습니다.
방어에 필요한 것은 실제 대상과 연결된 프로젝트를 확인하고 작업을 마치기 전에 호출자에게 적용되는 프로젝트 권한을 검사하는 일입니다. 기능 권한과 프로젝트 권한이 모두 충족돼야 합니다. 거부된 작업은 보호해야 할 상태도 바꾸지 않아야 합니다. 상태가 바뀐 뒤 오류만 반환한다면 경계가 복원됐다고 볼 수 없습니다.
이 요건을 점검하려면 다음 회귀 테스트가 유용합니다. 이는 제안하는 테스트이지 실행 결과나 업스트림 테스트 범위에 대한 설명이 아닙니다.
| 제안하는 테스트 | 기대되는 동작 |
|---|---|
| 기능 권한과 프로젝트 권한이 모두 작업을 허용 | 정상적인 Task Group 작업이 유지돼야 합니다. |
| 기능 권한은 있지만 프로젝트 권한은 없음 | 접근을 거부하고 대상 프로젝트의 상태를 바꾸지 않아야 합니다. |
| 프로젝트 접근 권한은 있지만 작업에 더 강한 권한이 필요 | 필요한 권한이 없다면 작업을 거부해야 합니다. |
| 대상 프로젝트를 확인할 수 없음 | 보호해야 할 상태를 바꾸기 전에 작업을 거부해야 합니다. |
이 글에서 릴리스별로 검토한 근거는 3.4.2에 관한 것입니다. 최초로 영향받은 버전을 독립적으로 확인하거나 문제를 도입한 변경 사항을 특정하지는 않습니다. 더 넓은 영향 버전 범위와 수정 버전은 Apache의 설명에 따릅니다. 권고된 릴리스에서 제안한 검사들을 실행하는 일은 별도의 검증 과제로 남아 있습니다.