tag

서버

이 태그가 달린 문서 15건

2026-11-01

Linux 커널 CVE-2026-98432: 네트워크로 유발되는 TCP use-after-free(CVSS 9.8). 수정된 커널을 설치하고 재부팅하며 MPTCP도 확인하세요

CVE-2026-98432는 2026년 10월 15일에 공개된 Linux 커널 IPv4 TCP 코드의 use-after-free입니다. 커널 프로젝트의 CNA는 CVSS v3.1 9.8(네트워크, 권한 불필요, 사용자 조작 불필요)로 평가했습니다. 한 AI 기업의 연구자들이 자체 보고에서, 실험실 환경에서 Multipath TCP(MPTCP) 리스너가 있는 서버에 대해 root 권한의 원격 코드 실행을 시연했다고 알려졌습니다. BleepingComputer는 일반 TCP 서버에 대한 원격 코드 실행은 공개적으로 시연되지 않았고 실제 악용도 확인되지 않았다고 전하며, 이 사이트는 11월 1일에 이 CVE가 CISA의 KEV 카탈로그에 없음을 확인했습니다. 업스트림 수정은 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 이후에 들어 있습니다. 11월 1일 기준 Debian은 수정된 커널이 있고, SUSE는 일부가 있으며, Ubuntu와 Red Hat은 수정을 진행 중으로 표시합니다. MPTCP를 끄는 것만으로는 완전한 수정이 아닙니다. 이 사이트의 결론: 인터넷에 노출된 Linux 서버는 수정이 나오는 대로 업데이트하고 재부팅하며, 그때까지만 업체의 임시 완화책을 쓰세요.

2026-11-01

긴급 PHP 업데이트 후 확인할 사항: 웹 PHP와 명령줄 PHP 비교, set -e와 diff 종료 코드, 침입 재점검

2026년 10월 치명적인 PHP 취약점 대응 중, 이 사이트 운영자가 관리하는 한 사이트는 웹 PHP는 업데이트했지만 cron이 사용하는 명령줄 PHP는 여전히 이전 버전을 가리키고 있었습니다. 웹과 CLI를 따로 확인하세요. set -e 환경에서 diff와 grep은 '차이 발견' 또는 '일치 없음'을 뜻하는 종료 상태 1을 반환하며, 이때 스크립트가 중단됩니다. 0, 1, 2를 각각 구분해 처리하세요. 패치 후에는 모든 서버에 같은 침입 점검 목록을 적용하고, 의심스러운 로그 항목은 실시간 파일을 알려진 정상 배포본과 비교해 판단하세요.

2026-10-30

VMware ESX CVE-2026-41709(CVSS 2.7): CISA가 낮은 심각도의 로깅 결함을 악용 중으로 등재; VMSA-2026-0006 전체를 패치하고 호스트를 점검하세요

CVE-2026-41709는 VMware ESX의 불충분한 로깅 결함(CVSS 2.7, Low)입니다. 이미 관리자 권한을 가진 공격자가 특정 작업을 수행해도 로그에 기록되지 않을 수 있습니다. Broadcom은 2026년 7월 29일 권고 VMSA-2026-0006에서 이를 수정했으며 우회 방법은 없습니다. 2026년 10월 28일(미국 시간) CISA는 이를 Known Exploited Vulnerabilities(KEV) 카탈로그에 추가했고, 미국 연방 기관의 기한은 11월 11일입니다. 한 보안 업체의 위협 보고서에 따르면 중국과 연계된 그룹이 2026년 초까지 미국 조직에 대한 여러 침입에서 이를 제로데이로 사용했으며, SecurityWeek은 그 목적을 감사 추적의 가시성을 줄이는 것이라고 설명합니다. 이 사이트는 그 보고서를 독자적으로 검증하지 않았습니다. 이 결함만으로는 침입할 수 없지만, 영향을 받는 호스트의 로그에 침입자의 행동이 나타나지 않을 수 있다는 뜻입니다. 같은 권고에는 9.8로 평가된 두 개의 vCenter 결함이 포함되어 있고, 그중 하나(CVE-2026-59310)는 CISA가 8월 18일 악용 중으로 등재했으므로, ESX 결함만 패치하면 침입 경로는 열려 있습니다. 이 사이트의 결론: 권고 전체에 대해 ESX와 vCenter를 수정 빌드로 업데이트하고, 호스트 로그를 별도 서버로 보내며, 로그만 믿지 말고 침해 징후를 찾으세요.

2026-10-29

Linux 커널 Fragnesia(CVE-2026-46300): CISA가 악용된 것으로 등재하고 10월 31일을 기한으로 지정. PHP와 커널을 패치하고 재부팅하십시오

별칭 Fragnesia인 CVE-2026-46300은 권한이 낮은 로컬 사용자가 root 권한을 얻을 수 있는 Linux 커널의 결함입니다(CVSS v3.1 7.8, 로컬 공격 벡터). 커널이 네트워크 버퍼 사이에서 데이터 조각을 옮길 때 데이터가 메모리 속 파일과 공유되고 있음을 나타내는 표식이 사라질 수 있고, 그러면 IPsec ESP 코드가 읽기 전용 파일의 캐시된 사본 위에 복호화할 수 있습니다. 커널 프로젝트는 2026년 5월 23일 CVE를 공개했으며, 수정은 커널 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33, 7.0.10 이후에 포함되어 있습니다. 2026년 10월 28일(미국 시간) CISA는 실제 악용 증거를 근거로 이를 KEV(Known Exploited Vulnerabilities) 카탈로그에 추가했으며, 미국 연방 기관의 기한은 10월 31일입니다. CISA의 설명은 PHP 취약점 CVE-2026-109618, CVE-2026-109619와 연계하여 PHP 웹셸을 심고 root 권한으로 명령을 실행할 수 있다고 밝힙니다. 한 보안 기업은 이 연계가 서버 25대(대부분 방화벽)에 사용되었다고 보고했고 SecurityWeek이 이 보고를 되풀이했습니다. 이 사이트는 해당 수치를 독자적으로 검증하지 않았습니다. Ubuntu, Red Hat, Debian은 수정된 커널을 배포했으며, 커널 업데이트는 재부팅한 뒤에야 적용됩니다. 이 사이트의 결론: Linux에서 PHP 사이트를 운영한다면 PHP와 커널을 업데이트하고 재부팅한 뒤 웹셸이 있는지 확인하십시오.

2026-10-25

Nextcloud 내장 Collabora CODE 서버 CVE-2026-110447 악용: 영향 범위와 대응 방법

2026년 10월 14일 Collabora Online 개발자들은 Nextcloud 앱 Collabora Online - Built-in CODE Server(앱 ID richdocumentscode)의 인증되지 않은 OS 명령 주입 취약점 CVE-2026-110447을 공개했습니다. 앱의 proxy.php를 통해 웹 서버 사용자 권한으로 명령이 실행될 수 있습니다. 내장 CODE 서버가 실행 중이 아닐 때 조건이 성립하며, 이는 컨테이너 재시작, 업그레이드 또는 충돌 후에 발생할 수 있습니다. 26.4.303 이전 버전이 영향을 받으며, 26.4.303은 9월 11일에 출시되었습니다. 개발자들은 앱을 비활성화해도 문제가 방지되지 않는다고 말하며 업데이트 또는 제거를 요청했습니다. 지원이 종료된 Nextcloud 29 이하에서는 Nextcloud를 업데이트하거나 앱을 제거하십시오. 개발자들은 독립형 Collabora Online 서버, Docker 이미지, RPM/DEB 패키지, Nextcloud All-in-One은 영향을 받지 않는다고 말합니다. CVSS v4.0 점수는 9.2입니다. CISA는 10월 23일 이 취약점을 Known Exploited Vulnerabilities(KEV) 카탈로그에 추가했으며 기한은 10월 26일입니다. 사용자들은 개발자 저장소에서 약 9월 10일부터 공격이 있었다고 보고했고, 언론 보도에 따르면 웹 셸이 심어졌습니다. 이 사이트의 결론: 내장 CODE 앱이 설치되어 있다면, 비활성화된 상태라도 오늘 버전을 확인하고, 업데이트 또는 제거한 뒤, 9월 10일 이후의 흔적을 점검하십시오.

2026-10-25

GitLab CVE-2026-110264(CVSS 10.0)와 악용되는 CVE-2026-97229: 셀프 호스팅 GitLab 확인 및 업데이트 방법

2026년 10월 21일 GitLab은 Community Edition(CE)과 Enterprise Edition(EE)용 긴급 패치 버전 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13을 공개했습니다. 가장 심각한 취약점인 CVE-2026-110264(CVSS 10.0)는 특수하게 조작된 정규식을 컴파일할 때 발생하는 정수 오버플로우입니다. 특정 조건에서 인증되지 않은 사용자가 GitLab 서버에서 임의의 코드를 실행할 수 있게 할 수 있습니다. 7.0 이후 거의 모든 버전이 영향을 받습니다. 10월 29일 CISA는 자매 취약점 CVE-2026-97229(CVSS 10.0, CWE-190)를 KEV(Known Exploited Vulnerabilities) 카탈로그에 추가했으며 기한은 11월 1일입니다. 같은 종류의 버그(CI/CD 정규식 컴파일러의 정수 오버플로우, 인증되지 않은 사용자가 도달 가능)로, GitLab은 10월 12일 19.4.2, 19.3.5, 19.2.8에서 먼저 수정했으며 영향받는 범위는 19.2.0부터 19.2.7, 19.3.0부터 19.3.4, 19.4.0부터 19.4.1뿐입니다. 아직 19.4.2, 19.3.5, 19.2.8 미만이라면 악용되는 취약점에 노출된 상태입니다. 여기서 권장하는 버전(19.5.1, 19.4.3, 19.3.6, 19.2.9)으로 업그레이드하면 CVE-2026-97229도 함께 수정됩니다. GitLab.com은 이미 패치되었으며, 셀프 호스팅 설치는 업그레이드해야 합니다. 10월 21일 릴리스는 심각도 High인 취약점 2건(CVSS 8.2와 7.5)과 기타 취약점도 수정하지만, 해당 수정은 19.3.6, 19.4.3, 19.5.1 라인에서만 제공됩니다. 근본 원인은 Ruby의 정규식 엔진(Onigmo)에 있으며, Ruby는 10월 23일 4.0.9, 3.4.12, 3.3.13을 공개했습니다. 공격자가 제어하는 문자열로 정규식을 컴파일하는 애플리케이션이 영향을 받으며, Regexp.timeout은 이 버그들로부터 보호하지 못합니다. GitLab의 공지는 CVE-2026-110264가 악용되었다고 밝히지 않았고, 10월 30일 기준 KEV에도 없습니다. Alpine Linux는 10월 20일과 21일 자사 GitLab에 CVE-2026-97229를 통한 공격 시도가 있었고, GitLab만 (19.3.6으로) 업그레이드해서는 수정에 Ruby 패치도 필요했기 때문에 취약점이 막히지 않았으며, 인스턴스를 재구축했고 공격자의 코드가 실행된 증거는 찾지 못했다고 밝혔습니다. 이 사이트의 결론: 필수 업그레이드 중간 단계를 확인한 뒤 셀프 호스팅 GitLab을 오늘 업그레이드하고, 최종적으로 19.3.6 이상에 도달하며, GitLab을 직접 빌드하거나 자체 Ruby를 쓴다면 Ruby도 3.3.13, 3.4.12 또는 4.0.9 이상인지 확인하십시오. Ruby 애플리케이션은 수정된 Ruby로 옮기고, 사용자 입력으로 정규식을 만드는 방식을 중단해야 합니다.

2026-10-24

SiteGuard Server Edition CVE-2026-106931 악용 확인: 영향 대상과 대응 방법

2026년 10월 14일 EG Secure Solutions는 호스트형 웹 애플리케이션 방화벽(WAF)인 SiteGuard Server Edition의 통계 기능에 OS 명령 인젝션 취약점 CVE-2026-106931이 있다고 공표했으며, 이미 악용이 확인되었다고 밝혔습니다. 악용되면 제품이 동작하는 서버에서 root 또는 SYSTEM 권한으로 임의의 OS 명령이 실행될 수 있습니다. 영향 대상은 통계 기능이 활성화된 Ver2.20 이후 버전입니다(통계 기능은 기본적으로 활성화되어 있습니다). 구체적으로 Apache, Nginx, IIS 에디션은 Ver8.00 Update5 이전, FreeBSD Apache 및 Nginx 에디션은 Ver7.00 Update6 이전입니다. IIS 에디션 Ver3.10부터 Ver4.00 Update4까지는 영향이 없습니다. 수정 버전은 Ver8.00 Update5와 Ver7.00 Update6이며, 업그레이드가 어려운 환경을 위해 지원 종료 버전을 포함한 패치가 제공됩니다. 벤더는 이 취약점을 로컬 공격, 낮은 권한 필요로 평가했습니다(CVSS v3.0 7.8, v4.0 8.5). JPCERT/CC는 이 제품이 일본에서 널리 사용되고 있음을 확인했다며 주의 환기를 발표했고, 통계 기능을 비활성화하면 문제를 피할 수 있다고 밝혔습니다. CISA는 10월 20일 이 취약점을 알려진 악용 취약점(KEV) 카탈로그에 추가했으며 조치 기한은 10월 23일입니다. 이 사이트의 결론: Server Edition을 사용 중이라면 오늘 버전과 통계 기능을 확인하고, 업데이트 전에 진단 정보를 저장한 다음 수정 버전 또는 패치를 적용하십시오.

2026-10-21

[속보] PHP 취약점 CVE-2026-109618과 CVE-2026-109619 악용 확인, CISA KEV 카탈로그에 추가: 지금 8.5.12, 8.4.27, 8.3.36 또는 8.2.35로 업데이트

2026년 10월 21일 PHP 보안팀은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35를 출시해 인증 없이 원격 코드 실행(RCE)이 가능할 수 있는 심각한 취약점 두 가지를 수정했으며, 모든 사용자에게 즉시 업데이트할 것을 촉구했습니다. CVE-2026-109618은 메모리 부족(out-of-memory) 처리, CVE-2026-109619는 요청 사이에 남아 있는 오래된 내부 상태와 관련되며, 둘 다 CVSS v4.0에서 9.2로 평가되었습니다. 웹 요청을 처리하는 모든 PHP 설치 환경(PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed)이 위험에 노출되어 있습니다. PHP 팀은 애플리케이션 코드가 실행되기 전에 인증되지 않은 요청으로 공격이 발생하는 입증된 익스플로잇을 근거로 mod_php를 가장 위험한 것으로 봅니다. PHP 8.1 이하는 공식 업데이트가 제공되지 않으며, 팀은 7.4, 8.0, 8.1에 대한 최소 소스 백포트만 제공했습니다. 리눅스 배포판들은 패치를 사전에 받았습니다. 완전한 완화 방법은 없으며, 업데이트만이 유일하게 안전한 선택입니다. 10월 22일 일본 IPA와 JPCERT/CC가 경보를 발표했고, JVN은 JVNVU#99905564를 공개했습니다. 처음 경보를 발표했을 때 악용을 관찰하지 못했던 CISA는 10월 26일 두 취약점을 Known Exploited Vulnerabilities(KEV) 카탈로그에 추가했으며, 미국 연방 민간 기관의 대응 기한을 10월 29일로 정했습니다. 언론 보도에 따르면 한 보안 연구자가 운영하는, mod_php 환경의 패치되지 않은 PHP 8.4.26 허니팟에서 10월 24일 원격 코드 실행이 성공했습니다. 한 주요 클라우드 제공업체의 허니팟은 공개 4일 전인 10월 17일부터 악용 시도를 포착한 바 있습니다. 이 사이트가 확인한 범위에서는 2026년 10월 27일 기준으로 허니팟 외의 침해 사고는 공개되지 않았습니다. 일본의 주요 공유 호스팅 업체 대부분은 수정이 적용되었다고 발표했지만, KAGOYA 등 일부 업체는 아직 발표하지 않았습니다. 10월 23일 PHP 팀은 10월 21일 릴리스에서 수정되지 않은 세 번째 문제(CVE-2026-115560)를 공개했습니다. 이 문제는 특정 설정과 애플리케이션 코드가 결합된 경우에만 코드 실행으로 이어질 수 있으며, 팀은 실제로는 가능성이 낮다고 평가합니다. 수정 사항과 전체 권고문은 다음 정기 릴리스와 함께 제공될 예정이며, 그때까지 session.upload_progress.enabled=0 설정을 권장합니다. 영향받는 버전과 CVSS 점수는 공개되지 않았으며, 악용 사례도 보고되지 않았습니다. 10월 29일 기준(php.net 확인)으로 이 문제의 수정 릴리스는 아직 나오지 않았습니다. 10월 28일 CISA는 Linux 커널 취약점 CVE-2026-46300도 KEV에 추가하고(미국 연방 기관의 기한 10월 31일), 이 두 취약점과 연쇄되어 PHP 웹셸을 심고 root 권한으로 명령을 실행하는 데 쓰일 수 있다고 밝혔습니다. 이 사이트의 견해: 악용이 확인되었으므로, 사이트별로 본인 또는 호스팅 업체가 PHP를 업데이트하는지 확인하고, 오늘 바로 수정된 버전으로 이동하십시오. 10월 17일 이후의 로그에서 침해 흔적도 확인하십시오. 공유 호스팅을 사용한다면 업체 공식 웹사이트의 완료 공지를 확인하십시오.

2026-10-15

웹사이트 보안은 SEO에 영향을 줄까? 취약점, 해킹된 사이트, HTTPS와 검색 순위를 Google 공식 문서로 정리

Google은 취약점을 순위 요소로 나열하지 않습니다. 피해는 취약점이 악용됐을 때 생깁니다. 해킹으로 스팸 페이지가 생기면 검색 결과에 '이 사이트는 해킹되었을 수 있습니다' 표시가 붙고, 멀웨어나 피싱이 있으면 Chrome에 '위험한 사이트' 경고가 뜨며(다른 브라우저도 각자의 세이프 브라우징 경고를 표시), 스팸 정책을 위반한 사이트는 순위가 낮아지거나 결과에 아예 나오지 않을 수 있습니다. HTTPS는 2014년에 '매우 가벼운' 신호로 발표되었고, Google의 현재 페이지 경험 문서는 Core Web Vitals 외의 페이지 경험 요소가 순위를 직접 올려 주지는 않는다고 설명합니다. 본 사이트의 견해: SEO를 위해서라면 보안 점수를 올리는 데가 아니라, 해킹당하지 않는 것과 해킹됐을 때 빨리 알아차리는 것에 시간을 쓰세요.

2026-10-11

내 웹사이트나 서버가 해킹됐는지 확인하는 법: 공유 호스팅, WordPress, VPS별 점검 순서와 발견했을 때 먼저 할 일

사이트의 침입 여부를 확인하려면 밖에서 보이는 징후와 안에 남은 흔적을 둘 다 본다. 징후: Search Console의 보안 문제 보고서, 검색 결과의 '이 사이트는 해킹되었을 수 있습니다' 표시, 호스팅 업체의 알림, 모르는 관리자, 모바일이나 검색에서 들어올 때만 일어나는 리디렉션. 흔적: 관리자 사용자, 변조된 코어 파일(wp core verify-checksums), 로그인 기록, authorized_keys, cron, 리스닝 포트, 최근 변경된 파일. 본 사이트의 견해: 아무것도 찾지 못했다고 깨끗하다는 증거는 아니다. 무언가 발견했다면 정리하기 전에 증거를 보존하고, 깨끗한 기기에서 모든 자격 증명을 교체하고, 침입 이전 백업으로 복원하거나 다시 구축하고, 침입 경로를 막은 다음에 검토를 요청한다.

2026-06-11

공개 디렉터리에 시크릿 파일을 남겨두지 않았나요? 웹루트를 점검하라

웹루트의 모든 것은 누구나 URL로 가져갈 수 있습니다. 남겨진 토큰/자격증명 JSON, .env, 백업은 즉각 노출을 뜻하며 — 공유 템플릿에서 왔다면 모든 사이트가 같은 파일을 갖습니다. 해법: 공개 디렉터리엔 공개해도 되는 것만, 시크릿은 웹루트 밖에 권한 600으로, 하나 찾으면 모든 사이트와 호스트를 점검하기.

2026-06-11

보안 인벤토리: 서버 여러 대를 운영하는 사람이 놓치는 7가지 점검

1인/소규모 운영자에게 사고는 통제의 부재보다 추적되지 않은 상태에서 옵니다. 경계는 키를 쥔 PC입니다. 다른 계정을 복구할 수 있는 계정 순서로(이메일 먼저) 2FA의 우선순위를 정하고, 어느 SSH 키가 어느 서버를 여는지 목록으로 만들어 중복·미사용 키와 남은 등록을 삭제하고, 클라우드의 평문 비밀번호를 제거하고, 한 번에 하나씩 되돌릴 수 있게 조치하고, 시크릿을 대장에 두지 마세요. 도구 추가 전에 인벤토리부터.

2026-06-11

자체 호스팅 Git vs GitHub: 실제로 어느 쪽이 더 안전한가?

Git을 자체 호스팅한다고 '더 안전'해지지 않습니다 — 위험을 옮길 뿐입니다. 실수로 인한 공개 노출 부류는 사라지지만, 서버 패치·백업·커밋 전 시크릿 탐지가 당신에게 넘어옵니다. 그 일을 계속 해낸다면 옳은 선택이고, 방치하면 GitHub보다 나쁩니다. 본 사이트의 견해: 자체 호스팅은 보상 통제와 묶일 때만 작동합니다.

2026-06-11

SSH 키 최소 권한: 침해될 수 있는 임시 환경에 프로덕션 루트 키를 두지 마라

임시·침해 가능한 환경(GPU 파드, CI 러너, 일회용 VM)에서 프로덕션에 루트 키를 등록한다는 것은, 그 환경이 침해되는 순간 공격자가 프로덕션의 루트 권한을 얻는다는 뜻입니다. 해법: 임시 환경에 루트 키 금지; 미사용 시 키 제거; 다시 필요하면 비루트 사용자 + 키를 한 작업으로 제한하는 명령 제한 키. 재사용 키를 가장 중요한 자산으로 다루고, 키 하나가 새면 모든 서버가 열리는 구조를 절대 만들지 마세요.

2026-06-07

공유 호스팅에서 .env를 공개 웹에 노출하지 않기

주된 해법: 앱 본체를 docroot 밖에, public/만 노출. 먼저 .htaccess로 접근을 막고, 재구성으로 영구화한 뒤, 자가 점검. 본 사이트의 견해: 이건 한 사람의 실수가 아니라 업계 전반의 표준이 되어 버린 위험한 배치 — 경계심이 아니라 프로세스로 고치세요. bootstrap-redirect가 심링크를 이깁니다.