로그인 안 한 손님이 '편집' 버튼을 눌러버렸다 — Joomlack Page Builder 접근제어 결함(CVE-2026-56290) 뜯어보기

이미지 출처: CISA KEV

홈페이지 관리자 페이지를 만들다 보면 이런 착각을 하기 쉽다. "이 기능은 관리자 메뉴 안에만 있으니까 아무나 못 건드리겠지." 그런데 웹은 메뉴로 접근을 막는 게 아니다. 주소(엔드포인트)로 접근한다. 메뉴에 버튼이 안 보여도, 그 버튼이 부르는 주소를 손으로 쳐 넣으면 서버는 순순히 응답한다 — 서버 쪽에서 "너 이거 할 권한 있어?"를 따로 되묻지 않는다면 말이다. 이번에 공개된 CVE-2026-56290, Joomla용 페이지 빌더 확장인 Joomlack Page Builder의 부적절한 접근제어(Improper Access Control) 결함이 딱 그 착각을 파고든다.

핵심 요약

• Joomlack Page Builder에서 권한 확인이 빠진 기능이 발견됨 — 낮은 권한 사용자나 인증되지 않은 요청이 원래 접근하면 안 되는 동작을 수행할 수 있음.
• 공격 재현은 어렵지 않음. 새 취약점이 아니라 '서버가 권한을 안 물어보는' 고전적 설계 실수임.
• 방어는 세 겹 — 확장 업데이트, 웹 서버·WAF에서 해당 요청 통제, 그리고 로그로 무단 접근 흔적 탐지.

부적절한 접근제어가 뭐길래

접근제어(Access Control)는 "누가 무엇을 할 수 있는가"를 정하는 규칙임. 부적절한 접근제어란 이 규칙 자체가 없거나, 있어도 엉뚱한 자리에 있는 상태를 말함. 웹 확장에서 흔히 나오는 형태는 대략 이런 식임.

• 기능 단위 권한 누락: 관리자만 써야 할 저장·삭제·업로드 같은 동작에 대해 서버가 요청자의 권한을 검증하지 않음. 화면(UI)에서만 버튼을 숨겨두고 정작 처리 로직에는 문지기가 없는 경우.
• 객체 단위 권한 누락(IDOR류): 자기 것이 아닌 페이지·레이아웃의 식별자(ID)를 요청에 끼워 넣으면 남의 자원이 열림.
• 토큰·논스 미검증: Joomla는 요청 위조를 막는 토큰 체계가 있는데, 특정 진입점이 이 검증을 건너뛰면 외부에서 임의로 호출 가능해짐.

CVE-2026-56290은 이 계열의 문제로 보임. 정확한 영향 버전과 심각도 점수는 벤더 권고문과 NVD 항목이 최종 확정하는 값이니 숫자를 외워두기보다, "권한 검증이 빠진 엔드포인트가 하나 열려 있었다"는 구조를 이해하는 게 실무엔 더 쓸모 있음.

왜 페이지 빌더에서 이런 게 반복될까

페이지 빌더는 드래그로 레이아웃을 짜고, 블록을 저장하고, 이미지를 올리고, 때로는 임포트·익스포트까지 지원함. 즉 서버에 상태를 바꾸는 진입점(핸들러)이 유난히 많음. 진입점이 많다는 건 그중 하나쯤 권한 검사를 빼먹기 쉽다는 뜻이기도 함. 개발 중엔 관리자 계정으로만 테스트하다 보니 "권한 없는 사람이 이걸 직접 부르면?"이라는 시나리오가 검증 밖으로 빠지는 것. 앞서 나온 Joomla 계열 SP Page Builder 업로드 취약점과 뿌리가 닮아 있음 — 기능이 화려한 확장일수록 접근제어 면적이 넓어짐.

방어자 관점의 점검 순서

공격을 어떻게 하느냐보다, 우리 사이트가 이 결함에 노출됐는지, 그리고 이미 건드려졌는지를 확인하는 게 먼저임. 순서대로 보자.

• 1) 자산 파악: 우리 Joomla에 Joomlack Page Builder가 깔려 있는지, 버전이 몇인지부터 확인. 확장 관리자 목록과 administrator/manifests 경로의 매니페스트로 설치 버전을 대조함.
• 2) 패치 적용: 벤더가 배포한 최신 버전으로 업데이트. 접근제어 결함은 코드 한 줄(권한 검사)로 막는 경우가 많아, 업데이트가 가장 확실하고 값싼 방어임.
• 3) 임시 완화: 당장 업데이트가 어렵다면, 웹 서버나 WAF에서 문제 되는 요청(특정 option/task 파라미터를 부르는 비인증 요청)을 관리자 IP 외엔 차단. 관리자 영역 자체를 IP 화이트리스트·기본인증으로 한 겹 더 감싸두면 노출 면이 크게 줌.
• 4) 흔적 탐지: 접근 로그에서 로그인 세션 없이 관리자·컴포넌트 엔드포인트를 반복 호출한 IP, 평소 없던 대량 POST, 알 수 없는 레이아웃·페이지가 갑자기 생성·수정된 정황을 뒤짐.

로그에서 무엇을 봐야 하나

탐지의 핵심은 "인증 없이 상태를 바꾸는 요청"을 골라내는 것임. 개념 수준에서 이런 신호들을 눈여겨봄.

• 정상 사용자라면 관리자 로그인 뒤에야 나올 컴포넌트 호출이, 세션 쿠키 없이 단독으로 찍힌 경우.
• 같은 URL로 ID 값만 1씩 바꿔가며 순회한 흔적 — 남의 자원을 훑는 전형적 패턴.
• User-Agent가 비어 있거나 스크립트성인데 저장·삭제 계열 동작을 호출한 요청.
• 파일 시스템 감시로 웹 루트에 예상치 못한 파일이 새로 생겼는지 병행 점검(빌더가 업로드 기능까지 가진 경우 대비).

이런 규칙은 완벽한 탐지가 아니라 '이상함을 빨리 눈치채기 위한 그물'임. 하나만 믿지 말고 패치·차단·로그를 겹쳐 쌓는 게 실전에서 통함.

정리하며

이번 건에서 배울 교훈은 화려한 익스플로잇이 아니라 단순함임. 화면에서 버튼을 숨기는 건 보안이 아니다. 진짜 문지기는 요청을 받아 처리하는 서버 코드 안에 있어야 하고, 그 문지기가 "너 누구고, 이걸 할 권한이 있냐"를 매번 되물어야 함. 우리가 운영자로서 할 일은 그 문지기가 빠진 확장을 빨리 갈아 끼우고, 갈아 끼우기 전까진 앞단에서 요청을 막고, 그동안 로그로 이상 신호를 지켜보는 것. 개인적으로는 사이트에 확장을 하나 더 붙일 때마다 "이건 상태를 바꾸는 진입점을 몇 개 늘리는 걸까"를 한 번씩 되뇌길 추천함. 여러분 사이트의 확장 목록, 오늘 한 번 열어보는 건 어떨까요. 점검하다 막히는 부분 있으면 댓글로 같이 풀어봐요.