github·2026년 7월 22일·3분 읽기큐레이션 요약

다음 장: GitHub 버그 바운티 프로그램 개편

GitHub은 버그 바운티 프로그램을 대량 제출보다 고품질·고영향 보안 연구 중심으로 재편한다. 이를 위해 우수 연구자 대상의 영구 VIP 프로그램을 도입하고, 공개 프로그램의 보상 체계와 제출 요건을 변경한다. 새 기준은 2026년 7월 27일 이후 제출된 보고서부터 적용된다. ## 프로그램 개편 배경 - 신규 연구자와 기존 연구자의 제출량 증가로 보고서 처리 대기열이 길어졌다. - 저품질 보고서와 AI로 생성된 보고서가 늘어나면서 중요한 취약점에 집중하기 어려워졌다. - GitHub은 “더 많이 제출할수록 더 많은 보상”이 아니라 “더 나은 취약점을 제출할수록 더 많은 보상”을 제공하는 방향을 택했다. ## 영구 VIP 프로그램 도입 - 지속적으로 고품질·고영향 취약점을 제보한 연구자를 위한 비공개 초대형 프로그램이다. - VIP 연구자에게는 다음 혜택이 제공된다. - 더 높은 보상금 - 더 빠른 응답 - GitHub 보안 엔지니어링 팀과의 긴밀한 협업 - VIP 보상 기준: - Low: **1,000달러** - Medium: **7,500달러** - High: **20,000달러** - Critical: **30,000달러 이상** - 다음 조건 중 하나 이상을 달성하면 VIP 자격을 얻을 수 있다. - Critical 취약점 1건 - High 취약점 2건 - Medium 취약점 4건 - Low 취약점 7건 - 구체적인 자격 기준은 GitHub의 공개 HackerOne 페이지에 게시될 예정이다. ## 공개 버그 바운티 보상 변경 - 공개 프로그램의 보상금은 다음과 같이 고정 금액으로 변경된다. - Low: **250달러** - Medium: **2,000달러** - High: **5,000달러** - Critical: **10,000달러** - 기존의 보상 범위 대신 심각도별 단일 금액을 사용한다. - 고정 금액은 연구자에게 예상 가능한 보상을 제공하고, GitHub의 내부 검토 부담과 불확실성을 줄이기 위한 조치다. - 기대 이상의 연구에는 별도의 재량 보너스가 지급될 수 있다. - 공개 프로그램은 신규 연구자가 탐색하고 실적을 쌓은 뒤 VIP 프로그램으로 진입하는 역할을 계속한다. ## 공개 제출에 신호 요건 적용 - 공개 프로그램에 HackerOne의 신호(signal) 요건이 도입된다. - 아직 충분한 실적이 없는 연구자는 제출 횟수가 제한된다. - HackerOne은 기준 미달 연구자에게 최대 **4회의 초기 제출 기회**를 제공한다. - 이는 신규 연구자를 배제하기 위한 장벽이 아니라, 실제 보안 연구 역량을 확인하고 저노력·AI 생성 보고서를 줄이기 위한 최소 기준이다. ## 유지되는 원칙과 적용 시점 - GitHub은 실제 보안 연구에 대한 신속한 보상과 명확한 커뮤니케이션을 계속 유지한다고 밝혔다. - 변경 시행 전에 제출된 보고서는 기존 보상 체계로 처리된다. - **2026년 7월 27일 이후 제출된 보고서**부터 새로운 보상 및 운영 구조가 적용된다. - 향후에는 응답 속도 개선, 심각도 판정 근거 명확화, 보안 커뮤니티와의 소통 확대도 추진한다. 이번 개편에 참여하려는 연구자는 단순히 보고서 수를 늘리기보다 재현 가능한 검증 절차, 명확한 영향 분석, 높은 심각도의 독창적인 취약점에 집중하는 것이 유리하다. 신규 연구자는 제한된 초기 제출 기회를 활용해 정확하고 완성도 높은 보고서를 제출하는 전략이 중요하다.

원문 읽기(새 탭에서 열림)

bug-bountyvulnerability-managementapplication-securityhackerone+2

discord·2026년 5월 18일·3분 읽기큐레이션 요약

디스코드의 모든 음성 및 영상 통화가 이제 종단 간 암호화됩니다

Discord는 2026년 3월부터 Stage 채널을 제외한 모든 음성·영상 통화에 종단간 암호화(E2EE)를 기본 적용했다. 이를 위해 DAVE 프로토콜을 데스크톱·모바일·웹·콘솔·봇·Social SDK 등 모든 플랫폼에 적용했으며, 사용자가 별도로 설정하지 않아도 암호화가 작동한다. Discord는 통화 품질과 지연 시간을 유지하면서도 공개 프로토콜, 오픈소스 구현, 외부 감사를 통해 검증 가능한 개인정보 보호를 제공하는 것을 목표로 했다. ## DAVE 프로토콜 도입과 전면 적용 - Discord는 2023년 음성·영상 통화 E2EE 실험을 시작했다. - 2024년 DAVE 프로토콜을 공개했다. - 오디오·비디오 통화를 위한 공개 E2EE 프로토콜 - 외부 보안 기업 Trail of Bits의 설계·구현 감사 진행 - 오픈소스 구현체 공개 - 버그 바운티 프로그램에 프로토콜 포함 - 2025년 웹 브라우저, PlayStation·Xbox 같은 게임 콘솔, Discord 봇·앱, Social SDK까지 지원 범위를 확대했다. - 2026년 3월 초 마이그레이션을 완료해 다음 통화가 기본적으로 암호화된다. - 개인 메시지 통화 - 그룹 DM 통화 - 음성 채널 - Go Live 스트림 ## 다양한 플랫폼을 동시에 지원한 설계 - Discord 통화에는 노트북, 스마트폰, 웹 브라우저, PlayStation, Xbox 사용자가 함께 참여할 수 있다. - 각 플랫폼의 암호화 구현이 서로 호환되면서도 낮은 지연 시간과 높은 통화 품질을 유지해야 했다. - Discord는 플랫폼 다양성 때문에 DAVE를 인터넷에서 가장 폭넓은 플랫폼을 지원하는 음성·영상 E2EE 구현 중 하나로 설명한다. - 모든 클라이언트가 DAVE를 지원해야 통화에 참여할 수 있도록 변경했다. - 현재는 암호화되지 않은 연결로 되돌아가는 폴백 코드를 제거하는 중이며, 제거가 끝나면 비암호화 연결은 불가능해진다. ## 공개 검증과 외부 협업 - DAVE의 설계와 구현을 공개해 커뮤니티가 직접 검토할 수 있도록 했다. - 외부 감사를 통해 보안성을 검증하고, 버그 바운티로 추가적인 취약점 제보를 유도했다. - 웹 지원 과정에서는 Firefox의 문제로 DAVE가 실제 통화에서 정상 작동하지 않는 사례가 발견됐다. - Discord는 우회책을 적용하는 대신 Mozilla와 Firefox 코드베이스를 함께 조사해 근본 원인을 수정하고 패치를 반영했다. - 이는 자체 코드뿐 아니라 관련 플랫폼과 생태계까지 개선하는 방식으로 프로젝트를 진행했음을 보여준다. ## 사용자 경험과 Stage 채널 예외 - E2EE 적용 이후에도 통화 품질과 성능은 기존 수준을 유지하도록 설계했다. - 사용자가 별도로 opt-in할 필요 없이 암호화가 투명하게 적용된다. - 유일한 예외는 대규모 방송을 위한 Stage 채널이다. - 라이브 이벤트, AMA, 커뮤니티 타운홀 등에 사용되는 방송형 구조 - 개인적인 대화 보호를 목적으로 하는 일반 통화와 설계 목적이 다름 - 따라서 현재는 E2EE 대상에서 제외된다. ## 텍스트 메시지 암호화 계획 - Discord는 현재 텍스트 메시지까지 E2EE를 확장할 계획이 없다고 밝혔다. - Discord의 다양한 텍스트 기능이 비암호화 환경을 전제로 구축되어 있기 때문이다. - E2EE를 도입하려면 검색, 관리, 신고, moderation 등 기존 기능을 대규모로 재설계해야 한다. - Discord는 음성·영상 암호화를 완료했지만 개인정보 보호 강화는 계속 진행되는 작업이라고 강조한다. 이번 변화로 Discord 사용자는 별도 설정 없이 개인 음성·영상 대화에 구조적이고 검증 가능한 보호를 받을 수 있게 됐다. 다만 Stage 채널과 텍스트 메시지는 적용 범위에서 제외되므로, 민감한 대화에는 일반 음성 채널이나 DM 통화를 사용하는 것이 적절하다.

원문 읽기(새 탭에서 열림)

bug-bounty오픈 소스end-to-end-encryptioncross-platform+3

github·2026년 5월 15일·4분 읽기큐레이션 요약

기준을 높이다: 품질, 공동의 책임, 그리고 GitHub 버그 바운티 프로그램의 미래

GitHub는 버그 바운티 프로그램을 유지하되, 제출량 증가와 검증되지 않은 보고서 확산에 대응해 심사 기준을 강화하겠다고 밝혔다. AI·스캐너 사용 자체는 환영하지만, 연구자가 실제 영향을 재현하고 검증할 책임이 있다는 점을 강조한다. 또한 사용자가 악성 콘텐츠를 직접 선택·실행하는 경우에는 GitHub의 보안 경계를 우회한 취약점이 아니라 공유 책임 영역으로 보는 원칙을 설명한다. ## 제출량 증가와 품질 문제 - AI와 새로운 보안 도구로 보안 연구 진입 장벽이 낮아지면서 업계 전반의 버그 바운티 제출량이 크게 증가했다. - 정당한 취약점이 늘어난 긍정적 효과도 있지만, 다음과 같은 저품질 보고서도 급증했다. - 실제 동작하는 개념 증명(PoC)이 없음 - 검증되지 않은 이론적 공격 시나리오 - GitHub가 이미 공개한 부적격 항목에 해당 - 보안 영향이 구체적으로 입증되지 않음 - GitHub는 프로그램을 중단하는 대신 제출 품질을 높이는 방향으로 대응한다. ## 강력한 취약점 보고서의 조건 - **작동하는 PoC와 실제 보안 영향** - 단순히 “이론적으로 가능하다”고 설명하는 데 그치지 않아야 한다. - 공격자가 실제로 무엇을 할 수 있는지 재현해야 한다. - 보안 경계를 넘을 수 있다는 사실과 구체적인 결과를 보여줘야 한다. - **범위와 부적격 항목 확인** - 제출 전에 GitHub의 버그 바운티 범위와 부적격 목록을 검토해야 한다. - DMARC/SPF/DKIM 설정 문제, 사용자 열거, 공격 경로가 입증되지 않은 보안 헤더 누락 등은 부적격 사례다. - 이런 보고서는 “해당 없음(Not Applicable)”으로 종료될 수 있으며 HackerOne Signal과 평판에 영향을 줄 수 있다. - **제출 전 직접 검증** - 스캐너, 정적 분석 도구, AI가 발견한 결과라도 사람이 재현하고 확인해야 한다. - 검증되지 않은 오탐은 트리아지 리소스를 낭비하는 잡음에 불과하다. ## AI 활용은 허용되지만 책임은 연구자에게 있음 - GitHub는 AI를 보안 연구에 사용하는 것을 금지하지 않는다. - AI는 공격 표면을 탐색하고 후보 취약점을 찾는 생산성 도구로 활용될 수 있다. - 다만 AI가 생성한 결과도 다음 조건을 충족해야 한다. - 실제 환경에서 검증 - 재현 가능성 확인 - 작동하는 PoC 제공 - 구체적인 보안 영향 설명 - AI뿐 아니라 스캐너와 정적 분석 도구의 결과에도 동일한 기준이 적용된다. - 도구가 아니라 결과물의 정확성과 품질이 평가 대상이며, 보고서의 정확성에 대한 최종 책임은 연구자에게 있다. ## 간결하고 구조화된 보고서 작성 강한 보고서는 다음 세 요소를 포함해야 한다. - **짧은 문제 요약** - **명확한 재현 절차와 증거** - 스크린샷 - HTTP 요청 - 터미널 출력 등 - **영향 설명** - 공격자가 실제로 달성할 수 있는 결과를 구체적으로 기술 반대로 긴 이론적 서술, 이미 알려진 배경의 반복, AI가 생성한 불필요한 문장은 핵심 취약점을 묻히게 해 처리 속도를 늦춘다. ## GitHub의 공유 책임 보안 모델 GitHub는 악성 콘텐츠를 탐지하고 처리하기 위해 자동 스캐닝과 수동 검토 등 다양한 방어 체계를 운영한다. 그러나 모든 콘텐츠를 사전에 신뢰할 수 있는 것은 아니므로, 사용자와 GitHub가 보안을 함께 책임지는 공유 책임 모델을 적용한다. 사용자에게 기대되는 책임은 다음과 같다. - 신뢰할 저장소, 이슈, 코드를 신중하게 선택 - 코드·스크립트·워크플로 등 실행 가능한 콘텐츠를 실행하기 전 검토 - 저장소를 클론하는 행위가 해당 코드에 대한 신뢰를 선택하는 것임을 이해 - 토큰, 자격 증명, 로컬 보안 설정을 안전하게 관리 사용자가 악성 저장소를 직접 클론하거나, 악성 파일을 열거나, 신뢰하지 않는 코드를 AI 도구에 분석하도록 제공해야만 문제가 발생한다면, 이는 대체로 GitHub의 보안 통제를 우회한 사례로 간주되지 않는다. ## 공유 책임 영역의 대표 사례 - 사용자가 직접 AI 도구에 제공한 콘텐츠를 이용한 프롬프트 인젝션 - 사용자가 체크아웃한 저장소에서 Git 훅이나 필터가 코드 실행 - 사용자가 클론한 저장소에 포함된 악성 콘텐츠 - 사용자가 제공한 신뢰할 수 없는 입력을 처리하는 LLM의 예기치 않은 출력 이러한 연구도 가치가 있지만, 실제 보안 통제를 우회해 사용자가 악성 콘텐츠를 적극적으로 신뢰하지 않아도 피해가 발생하는지 입증해야 의미 있는 취약점 보고서가 된다. 실무적으로는 AI나 자동화 도구를 적극 활용하되, 제출 전 반드시 수동 재현과 영향 검증을 수행하는 것이 좋다. 보고서는 “요약-재현 절차-실제 영향” 중심으로 간결하게 작성하고, GitHub의 범위·부적격 목록과 사용자 신뢰가 전제된 보안 모델을 먼저 확인해야 한다.

원문 읽기(새 탭에서 열림)

bug-bountygithubGitai-security+4

gitlab·2026년 4월 22일원문

GitLab 패치 릴리스: 18.11.1, 18.10.4, 18.9.6 | GitLab 문서 (새 탭에서 열림)

GitLab은 2026년 4월 22일, 다수의 보안 취약점과 버그를 해결하기 위해 GitLab Community Edition(CE) 및 Enterprise Edition(EE)의 패치 버전인 18.11.1, 18.10.4, 18.9.6을 출시했습니다. 이번 업데이트는 GraphQL API의 CSRF 문제와 Web IDE 내 임의 자바스크립트 실행 등 심각도가 높은 보안 결함을 포함하여 총 10건 이상의 취약점을 해결하는 것을 핵심으로 합니다. 시스템의 안전한 운영을 위해 자체 호스팅(Self-managed) 환경을 사용하는 모든 관리자는 최신 패치 버전으로 즉시 업그레이드할 것을 강력히 권고합니다. ### 고위험 보안 취약점 해결 * **CVE-2026-4922 (GraphQL API CSRF):** GraphQL API의 CSRF 보호가 불충분하여 인증되지 않은 사용자가 인증된 사용자를 대신해 뮤테이션(Mutation)을 실행할 수 있는 문제를 해결했습니다. (CVSS 점수 8.1) * **CVE-2026-5816 (Web IDE 경로 검증 오류):** 특정 조건에서 웹 IDE 자산의 경로 검증이 부적절하게 이루어져, 인증되지 않은 사용자가 사용자의 브라우저 세션에서 임의의 자바스크립트를 실행할 수 있는 취약점을 수정했습니다. (CVSS 점수 8.0) * **CVE-2026-5262 (Storybook XSS):** Storybook 개발 환경에서 입력값 검증 미흡으로 인해 인증되지 않은 사용자가 토큰에 접근할 수 있는 교차 사이트 스크립팅(XSS) 이슈를 해결했습니다. (CVSS 점수 8.0) ### 서비스 거부(DoS) 취약점 보완 * **리소스 고갈 방지:** 토론(Discussions) 엔드포인트(CVE-2025-0186), 노트(Notes) 엔드포인트(CVE-2025-6016), GraphQL API(CVE-2025-3922)에서 리소스 할당 제한이 미흡하여 서버 자원을 고갈시킬 수 있는 DoS 문제를 수정했습니다. * **Jira 가져오기 오류(CVE-2026-1660):** 이슈를 가져오는 과정에서 부적절한 입력값 검증으로 인해 인증된 사용자가 DoS를 유발할 수 있는 취약점을 해결했습니다. ### 접근 제어 및 세션 관리 개선 * **가상 레지스트리 세션(CVE-2026-6515):** 만료되거나 잘못된 범위의 인증 정보를 사용하여 가상 레지스트리에 접근할 수 있었던 세션 만료 관련 이슈를 수정했습니다. * **비공개 정보 노출 차단(CVE-2026-5377):** 이슈 설명 렌더링 과정의 접근 제어 오류로 인해, 공개 프로젝트 내에서 비공개 이슈의 제목이 노출될 수 있는 문제를 해결했습니다. * **UI 레이어 및 API 보안:** Mermaid 샌드박스 내 입력값 검증 오류(CVE-2026-3254)와 프로젝트 포크(Fork) 관계 API의 부적절한 접근 제어 문제를 수정했습니다. 현재 GitLab.com은 이미 패치된 버전이 적용되어 있으며, GitLab Dedicated 고객은 별도의 조치가 필요하지 않습니다. 그러나 Omnibus, Helm Chart, 소스 코드 설치 등 모든 유형의 자체 호스팅 설치 환경은 이번 취약점의 영향을 받으므로, 관리자는 보안 하이진 유지를 위해 지원되는 최신 패치 버전으로 즉시 업그레이드해야 합니다. 상세한 취약점 정보는 패치 릴리스 30일 후에 GitLab 이슈 트래커를 통해 공개될 예정입니다.

bug-bountygitlabGraphQLvulnerability-management+4

gitlab·2026년 4월 8일원문

GitLab 패치 릴리스: 18.10.3, 18.9.5, 18.8.9 | GitLab 문서 (새 탭에서 열림)

GitLab은 커뮤니티 에디션(CE) 및 엔터프라이즈 에디션(EE)의 보안 취약점과 버그를 해결하기 위해 최신 패치 버전인 18.10.3, 18.9.5, 18.8.9를 출시했습니다. 이번 업데이트에는 인증된 사용자가 서버 측 메서드를 임의로 호출할 수 있는 고위험군 취약점을 포함하여 서비스 거부(DoS), 정보 유출, 권한 오류 등 다수의 보안 수정 사항이 포함되어 있습니다. 시스템의 안전한 운영을 위해 자체 관리형(Self-managed) GitLab 인스턴스를 운영하는 모든 관리자는 즉시 최신 버전으로 업그레이드할 것을 권고합니다. ### 주요 보안 취약점 수정 및 고위험 이슈 * **웹소켓 연결을 통한 메서드 호출(CVE-2026-5173):** 부적절한 접근 제어로 인해 인증된 사용자가 의도하지 않은 서버 측 메서드를 호출할 수 있는 문제가 수정되었습니다. CVSS 점수 8.5의 고위험 취약점으로, GitLab 16.9.6 이후 모든 버전이 영향을 받습니다. * **Terraform 상태 잠금 API의 DoS(CVE-2026-1092):** JSON 페이로드의 입력값 검증 미흡으로 인해 인증되지 않은 사용자가 서비스 거부 공격을 유발할 수 있는 결함이 해결되었습니다. * **GraphQL 및 CSV 임포트 DoS:** 인증되지 않은 사용자가 반복적인 GraphQL 쿼리를 보내거나(CVE-2025-12664), 인증된 사용자가 구조가 잘못된 CSV 파일을 임포트하여 Sidekiq 워커를 중단시킬 수 있는(CVE-2026-1403) 취약점들이 수정되었습니다. ### 데이터 보호 및 권한 제어 개선 * **정보 유출 방지:** 특정 GraphQL 쿼리를 통해 타인의 이메일 주소가 노출되는 문제(CVE-2025-9484)와 CSV 내보내기 시 타인에게 할당된 기밀 이슈에 접근할 수 있는 권한 확인 미흡 문제를 해결했습니다. * **분석 대시보드 XSS(CVE-2026-4332):** 사용자 정의 가능한 분석 대시보드에서 입력값 정화(Sanitization)가 제대로 이루어지지 않아 타인의 브라우저에서 임의의 JavaScript를 실행할 수 있는 교차 사이트 스크립팅 취약점이 보완되었습니다. * **코드 품질 리포트 코드 주입(CVE-2026-1516):** 특수하게 제작된 리포트 콘텐츠를 통해 이를 열람하는 사용자의 IP 주소를 유출할 수 있는 보안 허점이 수정되었습니다. ### API 및 환경 설정 보안 강화 * **Environments API 권한 오류(CVE-2026-1752):** 개발자 권한을 가진 사용자가 API를 통해 보호된 환경 설정을 부적절하게 수정할 수 있는 권한 검증 로직을 강화했습니다. * **AI 탐지 API 및 SBOM API 안정성:** 취약점 플래그 AI 탐지 API의 권한 오류와 GraphQL SBOM API의 입력값 검증 미흡으로 인한 시스템 불안정 요소를 모두 제거했습니다. GitLab 설치 유형(Omnibus, Source code, Helm chart 등)에 관계없이 해당 버전을 사용하는 모든 환경이 영향 범위에 포함됩니다. GitLab.com은 이미 패치가 완료되었으나, 자체 서버를 운영 중인 고객은 보안 유지를 위해 지원되는 최신 패치 릴리스로 즉시 업그레이드해야 합니다. 각 취약점에 대한 상세한 이슈 내용은 보안 정책에 따라 릴리스 30일 후에 공개될 예정입니다.

bug-bountygitlabAPIGraphQL+4

cloudflare·2026년 3월 9일원문

Pingora OSS 배포 (새 탭에서 열림)

Cloudflare는 최근 오픈소스 프레임워크인 Pingora에서 발견된 여러 건의 HTTP/1.x 요청 스머글링(Request Smuggling) 취약점을 해결하기 위해 0.8.0 버전을 출시했습니다. 이번 취약점(CVE-2026-2833, 2835, 2836)은 Pingora를 단독 수신 프록시(Ingress Proxy)로 사용할 경우 보안 제어 우회, 세션 하이재킹, 캐시 오염 등을 유발할 수 있는 위험을 내포하고 있습니다. Cloudflare의 자체 CDN 서비스는 내부 아키텍처 구조상 영향을 받지 않았으나, Pingora 프레임워크를 활용하는 외부 사용자들에게는 즉각적인 업데이트가 권고됩니다. ### 101 응답 전 조기 업그레이드 처리 문제 * Pingora는 `Upgrade` 헤더를 포함한 요청을 받을 때, 백엔드로부터 `101 Switching Protocols` 응답을 확인하기 전에도 후속 바이트를 스트림으로 직접 전달하는 결함이 있었습니다. * 공격자는 업그레이드 요청 바로 뒤에 두 번째 HTTP 요청을 붙여서 보냄으로써, Pingora의 보안 필터나 WAF를 통과하지 않은 채 백엔드 서버에 직접 명령을 전달할 수 있었습니다. * 백엔드가 업그레이드를 거부하고 `200 OK`를 반환하더라도 Pingora는 이미 연결을 패스스루 모드로 전환했기 때문에, 프록시와 백엔드 간의 상태 불일치(Desync)가 발생하여 후속 사용자의 요청 데이터가 오염될 위험이 확인되었습니다. * 패치 이후 Pingora는 백엔드로부터 공식적인 101 응답을 받은 경우에만 데이터 해석 방식을 전환하도록 수정되었습니다. ### HTTP/1.0 및 Transfer-Encoding 해석의 불일치 * Pingora의 기존 로직은 `Transfer-Encoding` 헤더 인식 방식이 단순하여, 여러 인코딩이 나열되거나 표준을 벗어난 요청에서 본문 길이를 잘못 판단하는 경우가 있었습니다. * 특정 공격 시나리오에서 Pingora는 `Content-Length`를 기준으로 요청 본문의 끝을 인식했지만, 백엔드 서버(Node.js 등)는 `Transfer-Encoding: chunked`를 우선시하여 요청을 다르게 해석하는 CL.TE 방식의 스머글링이 가능했습니다. * 특히 HTTP/1.0 요청에서 `Transfer-Encoding`을 사용하는 비표준적인 상황에 대해 Pingora가 지나치게 관대하게 처리했던 점이 보안 약점으로 작용했습니다. * 0.8.0 버전에서는 RFC 표준에 따라 마지막 인코딩이 chunked인 경우를 정확히 식별하도록 강화되었으며, 유효하지 않은 인코딩 조합에 대한 검증 로직이 추가되었습니다. **권고 사항** Pingora를 사용하여 수신 프록시나 로드 밸런서를 구축한 운영자는 이러한 취약점으로부터 시스템을 보호하기 위해 즉시 **Pingora 0.8.0** 버전으로 업그레이드해야 합니다. Cloudflare 내부 시스템은 구조적으로 해당 공격 경로가 차단되어 있어 별도의 조치가 필요하지 않으나, 독립적인 배포 환경에서는 보안 사고의 원인이 될 수 있으므로 주의가 필요합니다.

bug-bounty데이터베이스 설계cloudflarenode.js+3

gitlab·2026년 1월 20일원문

GitLab 버그 바운티 프로그램 (새 탭에서 열림)

GitLab은 보안 연구자 커뮤니티와의 협력을 강화하고 더욱 투명한 운영을 위해 HackerOne 버그 바운티 프로그램의 정책을 대대적으로 업데이트했습니다. 이번 개편은 프로덕션 인프라의 안정성을 보호하기 위한 테스트 가이드라인 강화와 최신 보안 위협을 반영한 취약점 범위(Scope) 조정을 골자로 합니다. 연구자들은 더욱 명확해진 기준을 통해 혼선 없이 고영향력 취약점 발굴에 집중할 수 있게 되었습니다. ### 안전한 연구를 위한 테스트 가이드라인 강화 * **로컬 테스트 환경 권장:** 프로덕션 인프라 보호를 위해 GitLab Development Kit(GDK)을 활용한 로컬 테스트를 강력히 권장합니다. 이를 통해 연구자는 최신 기능을 공개 전 미리 확인하고 자유롭게 실험할 수 있습니다. * **DoS 테스트 조건:** 서비스 거부(DoS) 취약점을 증명해야 할 경우, 실제 서비스가 아닌 GitLab 설치 요구 사양을 충족하는 셀프 매니지드(Self-managed) 인스턴스에서 테스트를 진행해야 합니다. * **프로덕션 계정 규칙:** GitLab.com 서비스 환경에서의 테스트가 불가피한 경우, 반드시 HackerOne 이메일 별칭(`[username]@wearehackerone.com`)으로 생성된 테스트 계정만을 사용해야 합니다. ### 보안 환경 변화에 따른 취약점 범위 조정 * **서비스 거부(DoS) 제한:** 일반적인 DoS는 범위에서 제외되나, 인증되지 않은 엔드포인트를 통해 실행 가능하며 지속적이고 완전한 서비스 중단을 초래하는 애플리케이션 계층 DoS(ReDoS, 논리 폭탄 등)는 예외적으로 인정될 수 있습니다. * **AI 프롬프트 인젝션:** 단독 프롬프트 인젝션은 제외 사항입니다. 다만, 이를 초기 벡터로 삼아 보안 경계를 넘어선 실질적인 피해를 입히는 경우에는 유효한 취약점으로 간주될 수 있습니다. * **데이터 노출 기준 명확화:** 단순한 정보 수집이나 열거(Enumeration)는 제외되지만, 기밀 데이터가 노출되는 개인정보 침해 사례는 엄격히 취약점 범위에 포함됩니다. ### 연구자 보호를 위한 전환기 정책 및 원칙 * **7일의 유예 기간 제공:** 정책 변경으로 인한 혼란을 막기 위해 2026년 1월 22일 21:00(PT) 이전에 제출된 DoS 관련 보고서는 이전 정책을 적용하여 평가합니다. * **운영 원칙 준수:** 투명성(모호함 제거), 안전성(인프라 보호), 공정성(일관된 평가 표준)이라는 세 가지 원칙을 바탕으로 연구자들에게 예측 가능한 보상 환경을 제공합니다. 새로운 정책 하에서 활동하려는 보안 연구자들은 GitLab GDK를 설치하여 로컬 테스트 환경을 우선 구축하는 것이 권장됩니다. 또한, 상세한 취약점 평가를 위해 GitLab에서 제공하는 CVSS 계산기를 활용하여 보고서의 객관성을 높일 수 있습니다.

bug-bountygitlabDevSecOpshackerone+3