스카이티켓 개인정보 유출 사건: 구멍은 3개였고, 피해를 키운 건 지우지 않고 남겨 둔 옛 기록이었습니다

한눈에 보기

일본 여행 예약 사이트 스카이티켓(skyticket)을 운영하는 주식회사 어드벤처(株式会社アドベンチャー)가 2026년 10월, 고객 정보 유출을 세 번에 나눠 발표했습니다. 서로 다른 구멍 3개로 정보가 나갔고, 첫 발표에서만 등록·입력 고객 約1,464万件이 유출됐다고 밝혔어요. 그런데 발표를 세 번으로 늘린 건, 지웠어야 할 옛 결제 기록과 필요 없어졌는데도 지우지 않은 데이터베이스 백업이었습니다. 오래된 데이터를 정리하지 않고 두는 회사라면, 이 일을 남의 일로 볼 수 없습니다.

언제

• 구멍이 열려 있던 기간: 버스 예약완료 페이지 2026년 8월 3일~10월 1일 / 업무관리시스템 9월 20일(9월 28일 발각) / 회사 서버 10월 2일~4일(10월 5일 발각).
• 발표: 1보 10월 9일, 2보 10월 16일, 3보 10월 28일(공시)·10월 30일(사이트 게시).

누가

• 회사: 주식회사 어드벤처. 도쿄증권거래소 그로스 시장 상장(코드 6030).
• 서비스: 항공권·호텔·렌터카·고속버스·페리를 비교하고 예약하는 skyticket.

무엇이 몇 건 나갔나 (단위가 서로 달라 더하지 않습니다)

• 경로① 회사 서버, 1보: 등록·입력 고객 約1,464万件(이름, 생년월일, 메일, 전화, 주소 등). 그중 約413万件에는 해시(원래 글자를 알아보지 못하게 바꿔 둔 값) 상태의 로그인 비밀번호가 들어 있었습니다.
• 경로① 2보: 옛 유료 회원 회비 결제 기록에서 카드번호·명의·유효기한 最大6,140名.
• 경로① 3보: 지우지 않은 백업에서 환불 계좌 32,341件 유출(외부 송신 확인). 카드 일부 約93.6万件(約41.4万人), 여행보험 約11.8万件(約11.9万人)은 "유출 우려".
• 경로② 업무관리시스템: 이름·전화·환불 계좌 등 17,780件(중복 포함, 이 밖에 건수 조사 중인 것 있음).
• 경로③ 버스 예약완료 페이지: 예약 約12,000件(동행자를 포함한 사람 수는 미공표).
• 실제 악용: 회원 1명의 계정에 부정 로그인. 회사가 확인했다고 밝힌 악용은 이 1건입니다(2차 피해 없음은 1·2보에만 적혀 있고, 3보에는 그 항목이 없습니다).

왜 뚫렸나 (공식 발표만)

• 경로①: 일부 관리 기능이 부정하게 조작됐고, 거기서 다른 서버와 클라우드 데이터에 접근됐습니다. 이때 빼낸 인증정보(서버에 들어가는 열쇠 같은 정보)로 백업까지 읽혔습니다.
• 경로②: 업무관리시스템의 취약점(보안상 약점)이 악용됐습니다.
• 경로③: 예약완료 페이지가 로그인 없이 보이는 상태였고, 제3자가 기계적으로 열람했습니다.
• 관리 기능을 어떻게 조작했는지, 인증정보를 어떻게 얻었는지는 공표되지 않았습니다.

지금 상황 (11월 4일 기준)

• 발표가 두 번 정정됐습니다. 1보의 "카드 정보는 유출되지 않았다"는 2보에서, 2보의 "베네피트 스테이션 ID·비밀번호 유출"은 3보 사이트판에서 고쳐졌습니다.
• 외부 포렌식(전문 업체의 침해 조사)은 3보 시점에 "실시 준비 중"입니다. 실적 영향은 세 번 모두 "精査中(정밀 조사 중)"입니다.
• 3보 뒤로 새 공지는 없습니다.

스카이티켓을 쓴 적이 있다면 (자세한 안내는 아래 「스카이티켓을 쓴 적이 있으면 무엇을 확인해야 하나요?」)

• skyticket 비밀번호를 바꾸고, 같은 비밀번호를 쓰는 다른 서비스도 바꾸세요.
• 카드 명세서에 모르는 결제가 없는지 확인하세요.
• 회사 통지 메일은 info@skyticket.com에서 오고, 비밀번호 입력 링크는 넣지 않는다고 했습니다. 버스 운행회사를 사칭한 연락에도 주의하세요.

우리 회사가 지금 확인할 것

1. 지웠어야 할 데이터: 옛 결제 기록, 쓰지 않는 DB 백업·복사본이 서버나 클라우드에 남아 있지 않은지.
2. 관리 화면: 관리 기능에 누가 어디서 들어올 수 있는지, 그 안에 다른 서버·클라우드로 가는 열쇠가 보관돼 있지 않은지.
3. 로그인 없이 열리는 페이지: 예약완료·주문완료·영수증 페이지가 주소만 알면 남의 정보를 보여 주지 않는지.
4. 암호화: 암호화하기로 한 항목(계좌, 이름 등)이 실제로 암호화돼 있는지, 그 열쇠를 같은 곳에 두지 않았는지.
5. 발표와 문의 대비: 조사 전에 "이건 안 나갔다"고 단정하지 않을 것, 문의가 몰릴 때 메일·전화 창구가 버티는지.

정확히 어떤 일이 있었던 건가요?

날짜순으로 보면 이렇습니다.

• 2017년 2월~2018년 6월: 유료 회원 서비스 "skyticketプレミアム(스카이티켓 프리미엄)"의 회비를 카드로 낸 기록(로그)이 서버에 쌓였습니다. 이 시기에는 카드 정보를 회사 서버에 보관했어요.
• 2018년 7월: 카드 정보를 회사에 보관하지 않는 방식으로 바꿨습니다. 카드 정보는 지웠지만, 회비 결제 로그는 지우지 않았습니다.
• 2021년 5월~2024년 5월: 나중에 읽힌 DB 백업에 이 기간의 결제·환불 계좌·여행보험 정보가 들어 있었습니다. 회사는 필요 없어진 백업을 지우지 않고 클라우드에 두었어요.
• 2026년 8월 3일: 고속버스 예약완료 페이지가 로그인 없이 보이는 상태가 시작됐습니다. 제3자가 이것을 기계적으로 열람했습니다.
• 9월 20일: 업무관리시스템의 취약점이 악용됐습니다. 9월 28일에 발각됐어요.
• 10월 1일: 버스 페이지 문제가 발각돼 같은 날 수정됐습니다.
• 10월 2일~4일: 일부 관리 기능이 부정 조작됐고, 거기서 다른 서버와 클라우드 데이터에 접근됐습니다. 10월 3일에 옛 프리미엄 회비 로그가 빠져나갔고, 10월 5일에 발각됐습니다.
• 10월 7일 18시경: 저장된 카드로 결제하는 기능과 카드를 저장하는 기능을 멈췄습니다.
• 10월 8일 19시경: 대상 고객에게 통지 메일을 보내기 시작했습니다(공지¹).
• 10월 9일: 1보 발표(사이트², TDnet 공시³).
• 10월 16일: 2보 발표. 1보의 "카드 정보 유출 없음"을 정정했습니다(사이트⁴, TDnet 공시⁵).
• 10월 28일: 3보를 TDnet(도쿄증권거래소의 적시 공시 시스템)에 공시했습니다(TDnet 공시⁶).
• 10월 30일: 3보를 skyticket 사이트와 회사 사이트에 올렸습니다(사이트⁷).

여기에 회원 1명의 계정 부정 로그인이 있습니다. 1보는 이 건을 경로②(업무관리시스템) 항목 아래에 넣었는데, 1보에 적힌 부정 로그인 날짜(9월 9일)가 경로② 발생일(9월 20일)보다 앞섭니다. 두 날짜의 관계를 설명한 공지나 기사는 찾지 못했어요. 그래서 이 글에서는 이 건을 날짜순 흐름에 넣지 않았습니다.

구멍이 3개였다는 건 무슨 뜻인가요?

한 번 뚫린 게 아니라, 서로 다른 입구 세 곳이 따로 열렸다는 뜻입니다.

• 경로① 회사 서버 (10월 2일~4일): 가장 큰 구멍입니다. 일부 관리 기능이 부정하게 조작됐고, 거기서 다른 서버와 클라우드로 들어갔어요. 관리 기능 하나가 다른 서버와 클라우드 데이터로 들어가는 문이 된 셈입니다.
• 경로② 업무관리시스템 (9월 20일): 직원이 쓰는 업무 시스템의 취약점이 악용됐습니다.
• 경로③ 버스 예약완료 페이지 (8월 3일~10월 1일): 침입이라기보다 "열려 있던" 문제입니다. 예약을 끝낸 뒤 보이는 완료 페이지가 로그인 없이 보였고, 약 두 달 동안 기계적으로 열람됐습니다.

어떤 수법으로 관리 기능을 조작했는지는 공표되지 않았습니다(1보²).

어떤 정보가, 얼마나 나갔나요?

단위(件·名·人)가 서로 다릅니다. 그대로 옮기고, 더하지 않겠습니다.

경로① 1보 (1보²)

• 등록·입력 고객 約1,464万件: 이름(여권 표기 포함), 생년월일, 메일, 전화번호, 우편번호·주소, 송금할 때의 의뢰인 명의.
• 그중 約413万件: 해시 상태의 회원 로그인 비밀번호.
• 여권번호는 유출되지 않았음을 확인했다고 밝혔습니다.

경로① 2보 (2보⁴)

• 2017~2018년 프리미엄 회비 로그에서 最大6,140名: 카드번호, 명의, 유효기한(일부는 카드번호만). 보안코드는 들어 있지 않았습니다.
• 로그는 암호화돼 있었지만, 암호화에 쓰는 정보도 함께 빼앗겼습니다.

경로① 3보 (3보⁷)

• 환불 계좌 32,341件 (유출, 외부 송신 확인): 금융기관명, 계좌 종류, 계좌번호, 명의(가나). 한자 이름, 주소, 메일, 전화, 계좌 비밀번호(暗証番号), 인터넷뱅킹 ID·비밀번호는 들어 있지 않다고 했습니다.
• 카드 결제 고객 일부 約93.6万件(約41.4万人) (유출 우려): 명의, 일부를 가린 카드번호(끝 4자리, 또는 앞 6자리+끝 4자리), 브라우저 정보. 이 중 12件은 고객이 명의 칸에 카드번호를 넣어서 번호 전체가 기록돼 있었습니다.
• 여행보험 約11.8万件(約11.9万人) (유출 우려): 계약자와 피보험자의 이름(가나), 생년월일, 성별. 계약자는 휴대전화, 메일, 회원 ID, 예약 내용(편명, 탑승일, 구간, 여행대금)까지.
• 카드와 보험은 외부로 보낸 흔적은 없지만 가능성을 부정할 수 없어 "유출 우려"로 발표했습니다.

경로② (1보²)

• 17,780件(중복 포함, 이 밖에 건수 조사 중인 것 있음): 이름, 전화번호, 환불 계좌(금융기관명, 지점명, 계좌 종류, 계좌번호, 명의) 등. 일부는 메일·생년월일(68件), 주소(18件)도.
• 여권번호는 "현시점에서 유출 사실은 확인되지 않았으나 계속 확인 중"이라고 했고, 2보·3보에 갱신이 없습니다.

경로③ (1보²)

• 예약 約12,000件: 예약자 이름(가나), 나이, 성별, 생년월일(등록한 경우), 메일, 전화, 회원 ID, 단말 종류, 결제 방법·금액, 예약 일시, 승차편(일시, 승하차지, 운행회사, 편명, 운행회사 예약번호), 동행자 이름·나이·성별.

지우지 않은 옛 기록이 왜 문제가 됐나요?

이 사건의 핵심입니다. 침입은 경로①에서 한 번이었는데, 피해 발표는 세 번으로 늘었어요. 남아 있던 옛 데이터 때문입니다.

2보: 옛 결제 로그. 회사는 2018년 7월에 카드 정보를 자사에 보관하지 않는 방식으로 바꾸면서 카드 정보를 지웠습니다. 그런데 2017년 2월~2018년 6월 프리미엄 회비를 낸 결제 로그(변경 이력)는 남아 있었어요. 이 로그가 10월 3일에 빠져나갔고, 10월 15일에 카드 정보가 들어 있다는 게 판명됐습니다. 로그는 암호화돼 있었지만 암호화에 쓰는 정보도 같이 빼앗겼습니다(2보⁴). 자물쇠와 열쇠를 같은 서랍에 넣어 둔 것과 비슷합니다.

3보: 지우지 않은 DB 백업. 회사는 필요 없어진 데이터베이스 복사본(백업)을 클라우드에 그대로 두었습니다. 10월 2일~4일 침입 때 빼낸 인증정보로 이 백업 일부가 읽혔어요. 그 결과 환불 계좌 32,341件은 유출이 확정됐고, 카드 일부 約93.6万件(約41.4万人)과 여행보험 約11.8万件(約11.9万人)은 유출 우려 대상이 됐습니다. 회사는 은행계좌와 보험 이름 항목을 "본래 암호화해 저장해야 했지만 암호화하지 않았다"고 직접 밝혔습니다(3보⁷).

제가 보기에 이건 결국 남겨 둔 데이터, 특히 백업 데이터의 관리 소홀입니다. "쓰지 않는다"는 이유로 그냥 둔 거예요. 그런데 오래된 기록에도 카드번호, 환불 계좌, 이름 같은 고객 개인정보가 그대로 들어 있었습니다. 데이터는 오래돼도 보안상 가치가 떨어지지 않습니다. 빼앗기면 몇 년 전 데이터도 오늘의 피해가 됩니다. 저는 이것을 이 사건의 가장 중요한 교훈으로 봅니다.

누가 피해를 봤나요?

고객

• skyticket에 정보를 등록·입력한 고객 約1,464万件. 그중 約413万件은 해시 비밀번호까지.
• 환불 계좌를 등록한 고객: 경로②에서 17,780件, 경로① 백업에서 32,341件. 다른 경로, 다른 기간의 숫자이고 겹치는지는 발표되지 않았습니다.
• 계정에 부정 로그인을 당한 회원 1명.
• 고속버스 이용자와 동행자: 예약 約12,000件.
• 2017~2018년 프리미엄 회원: 카드 정보 最大6,140名.
• 2021~2024년 카드 결제 고객 일부: 約41.4万人(約93.6万件). 그중 12件은 카드번호 전체.
• 2023~2024년 여행보험 계약자와 피보험자: 約11.9万人(約11.8万件). 피보험자는 함께 여행한 사람이라 skyticket 고객이 아닐 수도 있습니다.

거래처

• 버스 운행회사(회사명 비공개): 운행회사 예약번호가 열람됐고, 회사는 운행회사를 사칭한 연락에 주의하라고 했습니다(1보²). 운행회사 쪽 공지는 찾지 못했습니다.
• 결제대행사·카드사(회사명 비공개): 보고를 받았고, 부정이용 모니터링을 의뢰받았습니다.
• 여행보험 인수 보험사(회사명 비공개): 보고를 받았습니다(3보⁷).
• 주식회사 베네피트 원(株式会社ベネフィット・ワン): skyticket이 보고한 곳입니다. 다만 베네피트 원의 공지 목록⁸에는 11월 4일 기준 skyticket 관련 공지가 없습니다. 10월 28일 베네피트 원 공지(PDF⁹)는 다른 위탁처 건이라 이 사건과는 별개입니다.

발표 내용이 왜 두 번이나 고쳐졌나요?

정정 1: 카드 정보. 1보는 "카드 정보는 결제대행사가 보관하므로 유출되지 않았다"고 했습니다. 2보에서 옛 회비 로그에 카드 정보가 남아 있었다고 정정했어요(2보 TDnet 공시⁵). 1보만 인용한 자료는 지금 보면 틀린 내용입니다.

정정 2: 베네피트 스테이션. 2보는 프리미엄 회원 특전인 "베네피트 스테이션(ベネフィット・ステーション)"의 회원 ID·이름·비밀번호가 유출됐다고 했습니다. 3보 사이트판에서 이는 skyticket이 프리미엄용으로 내부에서 정한 회원 ID와 이름이었고, 베네피트 스테이션의 ID·비밀번호가 아니었다고 고쳤습니다(3보⁷). 2보만 인용한 기사는 이 부분이 정정 전 내용입니다.

같은 3보인데 판마다 다릅니다. TDnet판(10월 28일)과 사이트판(10월 30일)은 날짜만 다른 게 아닙니다. 은행계좌 통지 방법이 TDnet판은 "연락처와 연결할 수 없어 공표로 대신", 사이트판은 "연락처를 확인한 고객에게 순차 메일"입니다. 베네피트 스테이션 정정은 사이트판에만 있어요(3보 TDnet 공시⁶, 3보 사이트⁷). 2보도 카드사 모니터링 의뢰는 TDnet판에만 적혀 있습니다.

제가 보기에 교훈은 분명합니다. 조사가 끝나기 전에 "이건 안 나갔다"고 단정하면, 정정이 따라옵니다.

기사마다 숫자가 다른 이유는 뭔가요?

• 합계 숫자: 일부 보도는 경로①②③의 숫자를 단순히 더한 합계를 제목에 썼습니다. 경로②는 중복을 포함하고 경로③은 예약 건수라서, 더하면 의미가 맞지 않습니다. 회사는 합계를 발표하지 않았고, 이 글도 합계를 쓰지 않습니다.
• 반올림: 2보의 "最大6,140名"을 NHK는 "6000人余り"(보도¹⁰), INTERNET Watch는 제목에서 "約6000件"(보도¹¹)이라고 썼습니다. 6,140名도 확정 인원이 아니라 상한입니다.
• 件과 人: 3보 카드는 93.6万件에 41.4万人, 보험은 반대로 11.8万件에 11.9万人입니다. 회사가 이 차이를 설명하지는 않았습니다.
• 3보 날짜: TDnet 10월 28일, TRAICY 보도 10월 29일(보도¹²), 사이트 10월 30일. 어디를 봤느냐에 따라 날짜가 다릅니다.
• 정정 전 내용: 1보나 2보만 인용한 기사는 정정 전 내용을 담고 있습니다(ITmedia 보도¹³는 2보 시점의 정정을 다뤘습니다).

회사는 어떻게 대응했나요?

• 침입 경로를 막고 취약점 대책을 했습니다. 버스 페이지는 10월 1일에 수정했어요.
• 10월 7일 18시경 저장 카드 결제와 카드 저장 기능을 멈췄습니다. 회원 계정이 털렸을 때 저장 카드로 부정 구매되는 걸 막기 위해서라고 했습니다.
• 10월 8일부터 info@skyticket.com 주소로 통지 메일을 보냈고, 메일에 비밀번호 입력 링크는 넣지 않는다고 했습니다(공지¹).
• 회원에게 비밀번호 변경을 요청했고, 같은 비밀번호를 다른 곳에서 쓰면 그것도 바꾸라고 했습니다.
• 문의가 몰려 메일 서버에 장애가 났고 10월 10일 복구를 알렸습니다(공지¹⁴). 10월 13일에 전용 전화창구(03-5224-8859, 평일 10~18시)를 열었습니다(공지¹⁵).
• 백업은 인증정보 권한을 지워 읽지 못하게 했고, 조사가 끝나면 삭제할 예정입니다.
• 카드(約41.4万人) 대상자는 연락처와 연결할 수 없어 개별 통지 없이 공지로 대신합니다. 여행보험 계약자 통지는 "후일 발송"입니다.
• 개인정보보호위원회(PPC)에 보고했고, 2보부터는 "관계기관"에도 보고했다고 썼습니다. 경찰 신고는 어느 공지에도 적혀 있지 않습니다.
• 외부 포렌식 조사는 3보 시점에 "실시 준비 중"입니다.
• 보상이나 금전 대응은 1~3보 어디에도 없습니다. 오히려 "보상을 명목으로 송금이나 수수료를 요구하는 연락에 응하지 말라"고 경고했어요(3보⁷).

스카이티켓을 쓴 적이 있으면 무엇을 확인해야 하나요?

회사 공지에 나온 안내를 이용자 쪽에서 정리하면 이렇습니다.

1. skyticket 비밀번호를 바꾸세요. 같은 비밀번호를 다른 서비스에서도 쓰고 있다면 그쪽도 바꾸세요.
2. 회사의 통지 메일은 info@skyticket.com에서 오고, 비밀번호를 입력하라는 링크는 넣지 않는다고 했습니다. 그런 링크가 들어 있으면 회사가 보낸 메일이 아닐 수 있습니다.
3. "보상해 주겠다"며 송금이나 수수료를 요구하는 연락에는 응하지 마세요.
4. 2보 공지대로 카드 명세서에 모르는 결제가 없는지 확인하세요. 버스 운행회사를 사칭한 연락에도 주의하라고 했습니다(1보).
5. 궁금한 점은 10월 13일에 연 전용 전화창구(03-5224-8859, 평일 10~18시)로 물어보세요.

이번 공격에 AI가 쓰였나요?

이번 사건에 AI가 쓰였다는 공식 발표나 보도는 없습니다. 침입 수법 자체가 공표되지 않았어요.

그러나 흔히 "AI 해킹"이라고 부르는 일, 즉 AI가 약점을 찾고 공격 방법까지 만드는 일은 이미 가능하다는 것이 확인됐습니다.

• Anthropic은 Claude Mythos Preview 평가에서 주요 OS와 브라우저의 고위험 취약점을 수천 건 찾았다고 밝혔고, 이 모델은 일반에 공개하지 않았습니다(Glasswing¹⁶, 연구 공개¹⁷).
• 보안 회사 Wiz는 PHP 엔진의 원격 실행 취약점 "PHP2Shell"을 AI로 찾았다고 밝혔습니다(Wiz¹⁸). Amazon은 이 취약점이 공개되기 4일 전에 이미 공격 시도를 관측했다고 했습니다(AWS¹⁹).
• 같은 10월, 일본 기업 약 20곳을 노린 공격 인프라에서 AI 침투 테스트 도구 ARTEX가 확인됐다고 GMO 이에라에(GMOイエラエ)가 발표했습니다(GMO 이에라에²⁰).

그래서 저는, 악의를 가진 쪽이 이런 AI를 쓴다고 가정하고 대비해야 한다고 봅니다. 로그인 없이 열리는 페이지나 남겨 둔 관리 화면처럼 "사람이 찾기 귀찮았던 구멍"은, 기계가 훨씬 빨리 찾을 수 있으니까요.

우리는 AI로 보안 구멍을 찾기 쉬운 세상에 살고 있습니다. 그렇다면 지금은 보안 점검에 속도를 내야 할 때입니다. 구멍을 찾는 속도를 공격하는 쪽에만 맡겨 둘 수는 없어요. Mythos Preview는 일반에 공개되지 않았지만, 저는 Glasswing처럼 AI로 자기 서비스를 먼저 점검하는 방식으로라도 모든 회사가 문제가 없는지 확인해야 한다고 생각합니다.

우리 회사와 무슨 상관인가요?

이 사건에서 나간 데이터의 상당 부분은, 회사가 이미 "쓰지 않는다"고 생각한 데이터였습니다. 그래서 큰 회사만의 이야기가 아닙니다.

• 남은 데이터가 피해 범위를 정합니다. 2018년에 정리했어야 할 결제 로그와 필요 없어진 백업이 그대로 있었습니다. 지금 쓰지 않는 데이터도, 남아 있으면 빼앗길 수 있어요. 오래됐다고 고객 정보의 가치가 줄지는 않습니다.
• 관리 화면 하나가 전체로 가는 문이 됩니다. 관리 기능에서 다른 서버와 클라우드로 들어갔고, 거기서 얻은 열쇠로 백업까지 열렸습니다.
• 완료 페이지도 보호 대상입니다. 예약완료 페이지가 로그인 없이 두 달 가까이 보였습니다.
• 암호화는 열쇠 관리까지 해야 의미가 있습니다. 그리고 암호화하기로 한 항목이 실제로 암호화돼 있는지 확인해야 합니다.
• 손님이 엉뚱한 칸에 넣은 정보도 저장됩니다. 카드 명의 칸에 카드번호를 넣은 12件이 그대로 남았습니다.
• 연락처와 연결되지 않는 데이터는 개별 통지를 할 수 없습니다. 約41.4万人은 공지로만 안내받습니다.
• 거래처도 피해 당사자가 됩니다. 버스 운행회사, 보험사, 결제대행사가 보고 대상이 됐고, 사칭 연락에 이름이 쓰일 수 있습니다.

제 생각은 이렇습니다. 공격은 결국 밖과 맞닿은 곳으로 들어옵니다. 이번에 밖에서 그대로 열려 있던 곳은 예약을 끝낸 뒤 보이는 완료 페이지 하나였어요. 작은 페이지였지만 예약 約12,000件이 나갔습니다. 밖과 맞닿은 공간은 아무리 작아도 하나도 빠뜨리지 말고 철저하게 점검해야 합니다.

실제로 일어난 일 (공식 발표 기준)

• 2017년 2월~2018년 6월: skyticketプレミアム 회비를 카드로 낸 결제 로그가 서버에 쌓였고, 2018년 7월 카드 비보관 방식으로 바꾸면서 카드 정보는 지웠지만 이 로그는 남았다. ⁴
• 2021년 5월~2024년 5월: 이 기간의 결제·환불 계좌·여행보험 정보가 든 DB 백업이 지워지지 않고 클라우드에 남아 있었다. ⁷
• 2026년 8월 3일~10월 1일: 고속버스 예약완료 페이지가 로그인 없이 보이는 상태였고, 제3자가 기계적으로 열람했다. 10월 1일 발각·수정. ²
• 2026년 9월 20일: 업무관리시스템의 취약점이 악용됐다. 9월 28일 발각. ²
• 2026년 10월 2일~4일: 일부 관리 기능이 부정 조작됐고, 다른 서버와 클라우드 데이터에 접근됐다. 10월 5일 발각. ²
• 2026년 10월 3일: 옛 프리미엄 회비 로그가 빠져나갔다. ⁴
• 2026년 10월 7일 18시경: 저장 카드 결제와 카드 저장 기능을 정지했다. ²
• 2026년 10월 8일 19시경: 대상 고객에게 통지 메일 발송을 시작했다(발신 info@skyticket.com). ¹
• 2026년 10월 9일: 1보. 세 경로의 유출과 회원 1명의 계정 부정 로그인을 발표했다. ²
• 2026년 10월 10일: 문의 급증에 따른 메일 서버 장애의 복구를 알렸다. ¹⁴
• 2026년 10월 13일: 전용 전화창구를 열었다. ¹⁵
• 2026년 10월 16일: 2보. 1보의 "카드 정보 유출 없음"을 정정하고, 카드 정보 最大6,140名 유출을 발표했다. ⁴
• 2026년 10월 30일: 3보. 백업에서 환불 계좌·카드 일부·여행보험 정보를 발표하고, 2보의 베네피트 스테이션 기재를 정정했다. ⁷ / 회사 공지 목록²¹
• 2026년 11월 4일 확인 시점: skyticket 공지 목록과 회사 공지 목록에 3보 뒤 새 공지는 없다. skyticket 공지 목록²² / 회사 공지 목록²¹

피해를 공표한 회사와 나간 정보

단위가 서로 달라 합계를 내지 않았습니다. 회사도 합계를 발표하지 않았습니다.

기준일: 2026-11-04. 각 회사 공지는 이후 바뀔 수 있습니다.