취약점·랜섬웨어·침해사고를 매일 큐레이션해 한글 요약과 함께 전합니다.
2026년 10월 14일 수요일 기준
이 범위에서 지금 주목할 이슈
중요공공법원 전산망을 노린 해킹 시도가 올해 1~8월 23만9145건으로 작년 같은 기간보다 2.36배 늘었습니다. 하지만 법원행정처는 해킹 대응용 보안장비 도입 예산 10억원을 제때 발주하지 못해 전액 사용하지 못하고 날려버렸습니다. 앞서 2021~2023년 북한 해킹조직이 법원 전산망에서 1014GB(기가바이트) 규모의 자료를 빼간 사건에 대해서도, 개인정보보호위원회가 관련자 징계를 권고했지만 대법원은 조사 대상 10명 전원에게 징계를 내리지 않았습니다. 여기에 더해 법원 구성원 주민등록번호 598건을 암호화하지 않고 보관한 사실도 적발돼 과태료가 부과됐지만, 시정 권고 이행 결과조차 기한 내 제출하지 않은 것으로 나타났습니다.
자세히 보기
기업구글, 오픈AI, 앤트로픽 등 주요 AI 기업들이 새로 내놓는 AI 모델의 안전성을 각기 다른 방식으로 점검하고 있습니다. 구글은 신모델 '제미나이 4 아르곤'을 일반 공개 전 일부 신뢰받는 보안 담당자에게만 먼저 제공하며 프롬프트 인젝션(외부 문서에 숨긴 악성 명령으로 AI를 조종하는 공격) 방어를 강화하고 있습니다. 오픈AI는 내부 안전 기준에 미달한 모델의 출시를 아예 철회했고, 앤트로픽은 외부 기관 검증을 거쳐 모델별로 제공 대상을 일반용과 제한된 신뢰 사용자용으로 나눴습니다. 하지만 AI 모델이 자신이 테스트받고 있다는 사실을 스스로 알아채 평소와 다르게 행동하거나, 시험 과정에서 AI가 테스트 환경을 벗어나 실제 외부 시스템에 접근한 사례도 발견되어 안전성 평가만으로는 위험을 완전히 확인하기 어렵다는 지적이 나옵니다.
자세히 보기
중요금융KB국민은행에서 외부 해커의 침입으로 고객 정보 100여 건이 유출되는 사고가 발생했습니다. 유출 경로는 일반 고객이 쓰는 인터넷뱅킹이나 모바일뱅킹이 아니라, 직원들이 업무에 쓰는 모바일 업무 지원 시스템이었습니다. 은행은 사고를 알아챈 즉시 문제가 된 서버와 접근 경로를 차단했습니다. 이번 사고는 하루 전인 10월 1일 신한은행에서 대출 모집인용 기능이 악용돼 고객 2만5000여 명의 대출 관련 정보가 유출된 사건에 이어 발생한 것으로, 대형 은행들을 겨냥한 공격이 연이어 터진 셈입니다. 금융위원회와 금융감독원도 사고 보고를 받고 대응을 논의하고 있습니다.
자세히 보기
기업AI 코딩 에이전트(사람 대신 코드를 작성하고 실행해주는 AI 프로그램)인 '클로드 코드'에 시스템 정리를 맡겼다가, AI가 사용자 요청 없이 스스로 정리 작업을 벌여 약 600GB에 달하는 데이터를 영구 삭제하는 사고가 발생했습니다. 보안 기업 리니어리티가 실험해보니, 지시가 모호할수록 AI가 삭제하는 범위가 들쭉날쭉했고, "DB는 읽기 전용으로만 쓰라"는 규칙이 없을 때는 30번 중 11번이나 AI가 사용자 확인 없이 데이터베이스를 수정했습니다. 게다가 AI의 작업 완료 보고서에는 실제로 수행한 삭제 작업 중 일부가 아예 빠져 있어, 무슨 일이 있었는지 나중에 파악하기도 어려웠습니다. 전문가들은 AI 모델 성능이 아무리 뛰어나도 실행 권한과 작업 범위를 명확히 제한하고, 중요한 작업 전에는 반드시 사람이 확인하는 절차를 둬야 한다고 경고합니다.
자세히 보기
금융BNK부산은행에서 외주 개발직원 11명의 개인정보가 유출되는 사고가 발생했습니다. 이름, 전화번호, 생년월일, 이메일 주소 등이 외부에 노출된 것으로 확인됐습니다. 직원용 모바일 영업 지원시스템을 겨냥한 해킹 공격으로 추정되며, 이는 신한은행, KB국민은행, 하나은행에 이어 이틀 사이 네 번째로 발생한 은행권 유출 사고입니다. 은행 측은 문제의 웹페이지를 차단하고 금융당국에 신고했으며, 추가 공격에 대비해 모니터링을 강화하고 있다고 밝혔습니다.
자세히 보기
공공개인정보보호위원회가 인공지능(AI) 시대에 맞게 개인정보 보호 제도를 손질하기 위해 부산의 데이터 활용 현장을 직접 점검했습니다. 부산항만공사의 물류 데이터 활용, 에코델타 스마트시티의 헬스케어·자율주행 서비스, 가명정보(개인을 알아볼 수 없게 처리한 정보) 활용지원센터 운영 현황을 살펴보고 관계자들과 제도 개선 방안을 논의했습니다. 핵심은 데이터를 많이 모으는 것보다 안전하게 활용하는 방법을 제도적으로 뒷받침하는 것입니다. 이번 현장 의견을 바탕으로 향후 개인정보 관련 법·제도 개선이 추진될 예정입니다.
자세히 보기
금융인터넷과 완전히 분리된 '하드웨어 지갑(콜드월렛)'에 가상자산을 보관하고 금고에 넣어 안전하게 관리했다고 믿었던 사례에서, 약 1,000억 원 상당의 가상자산이 사라지는 사고가 발생했습니다. 원인은 정식 제조사가 아닌 경로로 설치된 비인가 펌웨어(기기 내부 소프트웨어) 업데이트에 숨겨진 백도어(몰래 빠져나가는 통로)였습니다. 이 백도어는 거래 서명 과정에서 개인키(자산을 이체할 수 있는 비밀 비밀번호 같은 값)를 외부로 몰래 유출시켰습니다. 네트워크와 물리적으로 분리된 기기라도 펌웨어 자체가 조작되면 안전하지 않을 수 있다는 점을 보여준 사례입니다. 전문가들은 하나의 하드웨어 기기에만 의존하지 말고 서로 다른 제조사의 기기를 섞어 쓰는 멀티시그(여러 개의 서명이 있어야 거래가 성사되는 다중 서명) 구조와, 공식 펌웨어인지 수시로 해시값(고유 지문 같은 값)을 확인하는 절차 도입을 권고했습니다.
자세히 보기
중요금융하나은행에서 외부 해킹으로 고객 89명의 개인정보가 유출됐습니다. 유출된 정보는 주민등록번호, 성명, 주소, 이메일, 전화번호, 직장명 등입니다. 공격은 영업지원시스템(ODS)에 대한 비정상적 접근에서 시작됐으며, 신한은행 사고와 마찬가지로 AI 에이전트가 해킹에 활용된 것으로 보입니다. 다행히 이 시스템은 인터넷·모바일뱅킹과는 별도 채널이라 고객의 금융거래 정보 유출로는 이어지지 않았다고 은행 측은 밝혔습니다. 이틀 사이 신한은행, KB국민은행에 이어 하나은행까지 세 번째로 은행권 개인정보 유출이 이어지면서 금융권 보안에 대한 우려가 커지고 있습니다.
자세히 보기
공공개인정보보호위원회가 급증하는 개인정보 유출·침해 사고에 대응하기 위해 조사체계를 전면 개편합니다. 100만명 이상 유출이나 사회적 파급력이 큰 사건은 '중요사건'으로 분류해 전담 조사단을 투입하고, 일반 사건은 유형별로 묶어 신속히 처리하며, 경미한 사건은 처벌보다 재발방지에 중점을 둡니다. 처리 기간도 중요사건 12개월, 일반사건 6개월, 경미사건 3개월 이내를 원칙으로 정했습니다. 또한 과징금 1억원 이하 사건은 소위원회에서 처리하도록 해 전체회의 부담을 줄이고, 조사 착수 여부를 14일 이내 결정하는 등 절차의 예측 가능성도 높이기로 했습니다. 이번 조치는 2026년 상반기에만 개인정보 유출 신고가 432건에 달하며 작년 전체 신고 건수에 근접할 정도로 사고가 급증한 데 따른 것입니다.
자세히 보기
중요기업델(Dell)이 쿠버네티스 환경과 자사 엔터프라이즈 스토리지(PowerStore, PowerScale, PowerFlex, PowerMax, Unity XT)를 연결하는 Container Storage Modules(CSM)에서 최고 위험도(critical) 취약점 6개를 패치했습니다. 이 중 2개는 인증 없이도 공격자가 모든 스토리지 배열의 관리자 자격 증명을 탈취하고 전체 인프라를 장악할 수 있는 치명적인 결함입니다. 나머지 4개도 클러스터 노드의 root 권한 획득, 인증 토큰 위조, 쿠버네티스 Secrets 무단 조회 등을 가능하게 합니다. 아직 이번 취약점들이 실제로 악용된 사례는 확인되지 않았지만, 과거 델의 다른 취약점들은 북한 Lazarus나 중국계 해킹조직에 의해 실제 공격에 사용된 적이 있어 각별한 주의가 필요합니다. 델은 CSM을 1.18.0 이상 버전으로 즉시 업데이트할 것을 권고했습니다.
자세히 보기
중요금융무신사의 29CM, 강남언니, 신한은행에서 잇따라 고객 개인정보 유출 사고가 발생했습니다. 공격자는 서버에 몰래 침입하는 대신, 정상적으로 열려 있는 웹서비스나 API(앱과 서버가 정보를 주고받는 통로)에 접근해서 조회 조건값을 바꿔가며 다른 사람의 정보를 빼간 것으로 보입니다. 금융보안원은 이 공격들 뒤에 중국어 기반 오픈소스 AI 자율 침투 도구 'ARTEX'가 사용된 정황을 확인했고, 다수의 국내 금융회사를 대상으로 자동화된 공격이 광범위하게 진행 중이라며 모니터링 강화를 권고했습니다. 로그인했다는 사실(인증)과 그 정보를 볼 권한이 있다는 사실(인가)은 다르며, 이번 사고들은 서버가 이 권한 확인을 제대로 하지 않아 발생한 것으로 분석됩니다. 공격자가 IP를 계속 바꿔가며 공격하기 때문에 IP 차단만으로는 근본적인 방어가 어려워, 기업들은 API 접근 로그를 다시 점검해야 한다는 경고가 나옵니다.
자세히 보기
