DEVNURION · 보안 소식
Zammad 취약점 2건, 버전과 공격 조건을 나눠 대응해야 하는 이유
7.0 이상에 대한 설명은 첫 취약점의 런타임 조건에 한정되며, 로컬 권한상승 문제는 별도 검토 중입니다.
- Zammad는 10월 5일 CVE-2026-102489와 CVE-2026-102490에 대한 공식 평가를 발표했다.
- 제조사는 첫 취약점의 실제 악용이 6.5 이하에서 가능하고 7.0 이상은 런타임 조건상 영향받지 않는다고 설명한다.
- 두 번째 문제는 사전에 서버 접근이 필요한 로컬 권한상승이다. 모든 취약점이 해결됐다고 단정할 수 없다.

취약점 번호가 함께 발표돼도 같은 업데이트 판단으로 묶을 수 있는 것은 아니다. 애플리케이션의 버전과 서버에 접근할 수 있는 주체, 실제 실행 환경을 따로 확인해야 대응 범위를 정할 수 있다.
이번 Zammad 보안 권고를 읽는 핵심도 두 문제의 조건을 구분하는 데 있다. 첫 문제의 비영향 버전 설명을 전체 서버의 안전 보장으로 받아들이거나, 로컬 문제를 독립적인 원격 공격으로 소개하면 관리자가 필요한 조치를 잘못 판단할 수 있다.
CVE-2026-102489는 런타임 조건을 본다
제조사 권고는 Zammad 6.5 이하의 런타임 환경에서 악용이 가능하다고 설명한다. 이 버전들은 지원이 종료돼 더 이상 보안 업데이트를 받지 않는다고 안내됐다. 해당 설치를 계속 운영 중이라면 업데이트를 즉시 진행하라는 권고를 우선 검토해야 한다.
7.0 이상은 실제 런타임 조건에서 이 문제가 악용되지 않는다는 것이 제조사의 평가다. 추가적인 강화 조치로 관련 코드를 변경했고, 그 변경은 Zammad 7.2.0에 포함됐다고 설명한다. 코드 강화 사실과 이전 환경에서 악용이 가능한지 여부는 서로 다른 정보를 담는다.
CVE-2026-102490은 사전 서버 접근이 필요
두 번째 권한상승 취약점은 제조사 평가상 단독으로 원격 악용할 수 없는 로컬 문제다. 공격자는 먼저 기반 서버에 접근해야 하고, 이후 권한을 높이는 조건으로 설명돼 있다. 따라서 서버 접근을 신뢰할 수 있는 관리자에게 제한하라는 공식 권고가 함께 제시된다.
Zammad는 packager.io의 확인된 취약점과 관련돼 있고 해결 작업을 진행 중이라고 밝혔다. 이 발표만으로 두 번째 문제의 수정 버전이나 모든 배포 방식의 해결 완료를 선언할 수 없다. Zammad 패치 상태는 후속 권고와 실제 설치 방식의 업데이트 기록을 함께 확인해야 한다.
KEV 등재 날짜는 대응 우선순위의 신호
NVD의 CVE-2026-102489 기록에는 CISA KEV 등재일 2026년 10월 2일, 조치기한 10월 5일이 표시돼 있다. 알려진 악용 취약점 목록에 포함됐다는 정보와 자신의 서버가 침해됐다는 결론은 같지 않다. 실제 공격 사례나 침해지표를 확보했다고 표현해서도 안 된다.
해당 날짜를 국내 모든 조직에 적용되는 일률적인 법정 마감일로 읽는 것은 부정확하다. 관리자는 소속 조직의 의무와 노출 범위를 확인하면서도, 이미 알려진 위험에 대응을 미루지 않도록 우선순위를 정할 수 있다. 제조사 권고와 자산 목록이 판단의 기본 자료다.
| 문제 | 공식 평가와 대응 초점 |
|---|---|
| CVE-2026-102489 | 구버전 런타임 영향·즉시 업데이트 권고 |
| 7.0 이상 설명 | 첫 문제의 실제 악용 조건에 한정 |
| CVE-2026-102490 | 사전 서버 접근·로컬 권한상승 |
| 공통 점검 | 버전·접근 주체·후속 수정 공지 |

업데이트 후에는 업무 흐름도 확인
운영팀은 Zammad 설치 버전과 배포 형태, 서버 접근 계정을 먼저 정리할 수 있다. 업데이트 전에는 현재 지원되는 업그레이드 경로와 복구 수단을 확인하고, 적용 후에는 로그인·티켓 조회·메일 처리 같은 업무 흐름을 점검하는 방식이 도움이 된다. 구체적인 실행 명령은 설치 방식에 맞는 공식 문서를 따라야 한다. 점검 기록에는 확인 시각과 버전, 수행한 변경, 재현한 업무 동작을 함께 남기는 편이 좋다.
권고를 읽은 기록과 실제 적용 결과를 함께 남기면 다음 공지가 나왔을 때 다시 확인할 대상을 좁힐 수 있다. 버전 번호만 바꾸고 끝내기보다 이번 두 취약점의 조건, 서버 접근 제한, 후속 수정 상태를 각각 확인하는 것이 대응을 완결하는 방법이다.



