DB 소식 · 2026-10-15 · 검토용
PgBouncer 1.26.1 보안 업데이트: SCRAM 인증 우회·DoS 3건과 패치 점검
PgBouncer 1.26.1은 2026년 10월 14일 공개된 보안 업데이트다. 이 글은 세 CVE의 영향 버전과 설정 조건, PostgreSQL 커넥션 풀러 관리자가 점검할 항목을 공식 릴리스와 변경 이력에 근거해 설명한다.
1. PgBouncer 1.26.1 보안 업데이트: 취약점 3건 한눈에 보기
2026년 10월 14일 PgBouncer 프로젝트는 1.26.1을 공개했다. 이번 PgBouncer 1.26.1 보안 업데이트는 인증 우회 1건과 서비스 거부(DoS) 2건을 수정한다. 데이터베이스에 직접 접근하는 PostgreSQL 자체 업데이트가 아니라, 앞단에서 연결을 중개하는 커넥션 풀러의 보안 릴리스라는 점이 핵심이다. 따라서 PostgreSQL 서버 버전만 점검하는 것으로는 충분하지 않다.
CVE-2026-107350은 SCRAM 인증 단계의 상태 처리 문제이며, CVE-2026-107349와 CVE-2026-107348은 서로 다른 입력 처리 경로에서 발생하는 무한 루프 문제다. 둘 다 DoS로 분류되지만 설정과 영향 버전은 동일하지 않다. 공개된 조건을 분리해 평가해야 과도한 공포나 잘못된 안전 판단을 피할 수 있다.
이번 릴리스는 search_path 추적과 ignore_startup_parameters의 우선순위도 조정했다. 보안 수정만 확인하고 운영 환경의 연결·쿼리 동작을 검증하지 않으면 별도의 호환성 이슈를 놓칠 수 있다.
| CVE | 유형 | 영향 버전 |
|---|---|---|
| CVE-2026-107350 | SCRAM 인증 우회 | 1.17.0~1.26.0 |
| CVE-2026-107349 | 조건부 DoS | 1.20.0~1.26.0 |
| CVE-2026-107348 | 조건부 DoS | 1.21.0~1.26.0 |
2. PgBouncer SCRAM 인증 우회와 영향 버전
PgBouncer SCRAM 인증 우회는 CVE-2026-107350으로 추적된다. 공식 변경 이력에 따르면 PgBouncer 1.17.0부터 1.26.0까지에서 특정 조건으로 로그인 사용자 가장이 가능했다. 클라이언트가 존재하지 않는 데이터베이스로 연결을 시도하고 SCRAM 인증 중 두 번째 StartupMessage가 처리되는 경로가 문제의 출발점이다.
중요한 전제는 공격자가 auth_file에 등록된 한 사용자의 비밀번호를 알고 있어야 하며, 그 사용자와 가장 대상 사용자 모두 SCRAM 인증을 사용한다는 점이다. 가장 대상은 auth_file뿐 아니라 auth_query에서 가져온 사용자일 수도 있다. 따라서 임의의 비인증 외부인이 조건 없이 모든 계정에 접근할 수 있다는 식의 표현은 정확하지 않다. 관리 계정과 백엔드 슈퍼유저로 가장할 가능성이 언급되는 만큼, 해당 설정의 운영자는 우선적으로 버전과 인증 구성을 확인해야 한다.
'PgBouncer SCRAM 인증 오류와 취약점 대응 방법'을 찾는 관리자라면 일반적인 로그인 실패와 이 보안 취약점을 구별하는 것이 첫 단계다. 로그인 에러 메시지만으로 취약 여부가 판정되지는 않는다. 실제 배포 버전, auth_file 및 auth_query 설정, SCRAM 사용 여부를 기준으로 확인하고, 추측에 의존한 공격 재현은 운영 서비스에서 시도하지 않는다.
3. CVE-2026-107349·CVE-2026-107348: DoS는 조건이 다르다
CVE-2026-107349는 PgBouncer 1.20.0~1.26.0의 시작 옵션 처리 문제다. 인증되지 않은 클라이언트가 이름이 빈 옵션을 보낼 때 무한 루프를 발생시킬 수 있다. 다만 공식 문서에 따르면 ignore_startup_parameters가 비어 있지 않으면서 options를 포함하지 않는 구성에서 성립한다. 모든 배포가 똑같이 노출된다고 가정해선 안 된다.
CVE-2026-107348은 PgBouncer 1.21.0~1.26.0의 패킷 버퍼 확장 계산에서 발생하는 정수 오버플로 문제다. max_packet_size를 기본값인 2147483647보다 크게, 정확히 2147483649 이상으로 설정한 경우를 공식 변경 이력에서 위험 조건으로 명시한다. 기본 설정은 해당 조건에 해당하지 않는다. 버전만 보고 위험을 확정하지 말고 유효 설정값까지 대조할 필요가 있다.
두 취약점 모두 결과적으로 클라이언트 서비스가 멈출 수 있지만 발생 경로가 다르다. 보안 점검 보고서에는 영향 버전과 함께 startup options 처리 여부, ignore_startup_parameters 내용, max_packet_size 값을 구분해서 기록하는 편이 좋다.
4. PgBouncer 취약점 패치 방법과 운영 점검 순서
PgBouncer 취약점 패치 방법의 출발점은 공식 1.26.1 릴리스를 확인하는 것이다. 직접 설치 환경이라면 사용하는 배포본이 수정 버전인지 확인하고, Linux 배포판이나 관리형 서비스의 패키지라면 공급자가 취약점 수정을 백포트했는지 별도로 확인한다. 패키지 표기 버전만으로 실제 수정 여부를 단정하지 않는다.
PostgreSQL 커넥션 풀러 보안 점검에서는 서비스별 PgBouncer 인스턴스 수, 실제 실행 파일 버전, 설정 파일 경로, 인증 방식, 연결 방식, 서비스 재시작 절차를 기록한다. 변경 전 구성 백업과 연결 복구 계획을 확보한 뒤 스테이징 환경에서 인증·커넥션 풀링·장애 복구를 점검한다. 배포 시에는 신규 연결 성공률, 오류율, 대기 큐와 애플리케이션 연결 회복을 함께 관찰한다.
무중단 교체나 롤링 재시작은 네트워크 구성과 풀 배치에 따라 가능성이 달라진다. 이 기사는 특정 배포판에서의 실기 실행이나 무중단 전환을 검증하지 않았으므로, 운영자는 각 환경의 릴리스 절차와 공급업체 지침을 우선해야 한다.
5. search_path 변경 사항까지 확인해야 하는 이유
PgBouncer 1.26.1은 ignore_startup_parameters가 추적되는 파라미터보다 우선하도록 동작을 조정했다. 1.26.0부터 search_path 추적이 기본 기능으로 확대되면서 ignore_startup_parameters = search_path로 지정하더라도 무시 설정이 기대처럼 작동하지 않는 문제가 있었다. 새 버전에서는 지정한 search_path 무시 정책이 우선 적용되도록 조정됐다.
트랜잭션 풀링을 사용하는 애플리케이션에서는 연결 사이에서 세션 상태가 어떻게 취급되는지가 중요하다. 배포 후 애플리케이션의 스키마 선택, 커넥션 재사용, 로그인 처리, 검색 경로 관련 로그를 확인하는 것이 좋다. 모든 제품과 드라이버 조합에서 동작을 실제 실험한 것은 아니므로, 해당 환경의 회귀 테스트가 필요하다.
결론적으로 1.26.1은 즉시 확인할 가치가 있는 보안 릴리스다. 다만 취약점별 전제 조건과 배포 경로를 확인하는 일이 정확한 위험 평가와 안전한 운영 전환의 핵심이다.
자주 묻는 질문
세 취약점은 무엇을 수정하나요?
SCRAM 인증 우회 1건과 설정에 따라 발생하는 DoS 2건을 수정합니다.
인증 우회는 누구에게 영향이 있나요?
1.17.0~1.26.0 중 특정 SCRAM 자격증명·StartupMessage 조건을 만족하는 환경입니다.
기본 max_packet_size도 CVE-2026-107348에 취약한가요?
공식 변경 이력상 기본값 2147483647은 해당 취약 조건에 포함되지 않습니다.
패치 전 무엇을 확인해야 하나요?
실행 버전, 공급업체 패치, SCRAM 설정, ignore_startup_parameters, max_packet_size와 배포 테스트를 확인합니다.
search_path 변경은 어떤 의미인가요?
ignore_startup_parameters = search_path 지정이 다시 우선 반영되도록 조정됐습니다.
