PostgreSQL JDBC 42.7.14 보안 업데이트: CVE 2건의 영향 버전과 Java 프로젝트 대응 방법

PostgreSQL 데이터베이스를 사용하는 Java 서비스라면 서버 버전만 확인하고 끝내기 쉽습니다. 하지만 이번 보안 업데이트의 대상은 PostgreSQL 서버 자체가 아니라 JDBC 드라이버인 org.postgresql:postgresql입니다. 특히 Spring Boot처럼 의존성 관리 기능을 쓰는 프로젝트에서는 build.gradle이나 pom.xml에 명시한 버전과 실제 빌드에 들어간 버전이 다를 수 있으므로, 최종 해결된 의존성을 확인해야 합니다.

42.7.14에서 수정한 문제는 무엇인가?

pgJDBC의 공식 릴리스 노트는 2026년 10월 7일 드라이버 릴리스를 다루고 있습니다. PostgreSQL 커뮤니티 소식에 게시된 날짜(10월 9일)와는 구분해야 합니다.

두 문제의 영향 범위는 다릅니다. 각각의 발생 조건을 분리해 평가해야 하며, 영향을 받는 드라이버를 사용했다는 사실만으로 정보가 유출됐다고 단정할 수 없습니다.

CVE-2026-107314: requireAuth 설정이 무력화되는 경우

requireAuth는 드라이버가 허용할 인증 방식을 제한하는 연결 속성입니다. 이전 일부 버전에서는 다음처럼 모든 인증 방식을 배제한 값을 설정했을 때 제한을 적용하지 않는 문제가 있었습니다.

# 취약한 버전에서 문제가 되는 설정의 예시 — 사용하지 마세요.
requireAuth=!password,!md5,!gss,!sspi,!scram-sha-256,!none

이 상태에서는 서버가 요구한 인증 방식이 허용될 수 있습니다. 공격자가 애플리케이션과 서버 사이에서 인증 흐름에 관여한다면 평문 비밀번호 인증을 유도할 위험이 있습니다. 반대로 requireAuth를 아예 설정하지 않은 배포는 이 특정 취약점의 영향 대상이 아닙니다. 일부 방식만 배제했거나 긍정 목록으로 허용 방식을 선언한 값은 공식 권고상 올바르게 처리됐습니다.

42.7.14 이후에는 모든 방식을 제외하는 구성에서 접속이 거부될 수 있습니다. 이는 새 버전이 고장 난 것이 아니라 이전에 묵인했던 잘못된 구성을 더 이상 허용하지 않는 동작입니다. 운영 서버에서 지원하는 방식을 확인한 뒤 예를 들어 requireAuth=scram-sha-256 같은 실제 환경에 맞는 허용 목록으로 전환해야 합니다. TLS를 사용하는 서비스라면 서버 인증서를 검증하는 sslmode=verify-full 설정도 함께 검토해야 합니다.

CVE-2026-107315: 이전 쿼리 내용이 저장될 수 있는 조건

두 번째 문제는 인증과 관계없습니다. 애플리케이션이 전송할 바이트 길이를 실제 값보다 크게 선언하는 일부 API 호출에서, 드라이버가 빈 공간을 0이 아닌 같은 연결에서 이전에 송신한 데이터로 채울 수 있었습니다. 그 결과 앞선 SQL 문자열이나 파라미터가 데이터베이스에 저장되는 문제가 생길 수 있습니다.

공식 권고에서 지목한 경로에는 ByteStreamWriter를 사용하는 PreparedStatement.setObject나 Copy API, 길이 인자를 받는 일부 Large Object·Blob 쓰기 작업이 포함됩니다. 커넥션 풀을 사용하면 과거의 다른 요청에 속한 데이터가 섞일 가능성도 있으므로 민감 데이터 저장 경로를 우선 확인해야 합니다.

중요한 예외가 있습니다. 선언한 길이가 실제 전송 길이와 항상 일치하는 애플리케이션은 이 문제의 영향을 받지 않습니다. 또한 패치 후 새 데이터 쓰기 동작은 수정되지만, 이전 취약 버전에서 이미 기록한 데이터가 자동 정리되지는 않습니다.

Spring Boot·Gradle·Maven 프로젝트에서 버전 확인하는 법

패치 여부 판단은 pom.xml에 버전이 적혀 있는지만 보는 것으로 충분하지 않습니다. Spring Boot의 의존성 관리 또는 하위 모듈이 실제 드라이버 버전에 영향을 줄 수 있기 때문입니다.

Gradle

./gradlew dependencyInsight --dependency org.postgresql:postgresql --configuration runtimeClasspath

직접 버전을 관리하는 프로젝트라면 사용 중인 BOM·의존성 관리 전략을 확인해 안전한 버전으로 업데이트할 수 있습니다.

dependencies {
    runtimeOnly 'org.postgresql:postgresql:42.7.14'
}

Maven

mvn dependency:tree -Dincludes=org.postgresql:postgresql

BOM을 사용하는 경우는 부모 POM 또는 dependencyManagement의 적용 결과를 확인하고, 의도한 버전이 실제 런타임에 포함됐는지 재검증해야 합니다. 위 명령은 점검 예시이며 사용 중인 빌드 환경에서 실행한 결과가 아닙니다.

운영 반영 전에 해야 할 회귀 테스트

1. 버전 식별: 모든 실행 모듈과 컨테이너 이미지 안의 org.postgresql:postgresql 버전, 실제 클래스패스를 확인합니다.
2. 인증 검증: JDBC URL·DataSource 설정에서 requireAuth, channelBinding, TLS 설정을 찾아 정상 인증·잘못된 설정의 실패 동작을 확인합니다.
3. 데이터 무결성 테스트: ByteStreamWriter, Copy, BLOB 등을 사용하는 경로에서 길이 선언과 실제 바이트 수가 일치하는지 검토합니다.
4. 커넥션 풀 점검: 재사용 연결에서 민감 정보가 들어 있는 작업과 바이너리 데이터 쓰기 기능을 함께 검증합니다.
5. 배포 절차: 스테이징에 반영해 회귀 테스트를 거친 후, 배포 아티팩트에서 최종 드라이버 버전을 다시 확인합니다.
6. 사후 조사: 과거 영향을 받는 드라이버로 잘못된 길이의 쓰기를 수행했다면 관련 저장 데이터의 노출 가능성을 별도 조사합니다. 변경된 드라이버를 배포하는 것만으로 기존 데이터의 오염이 제거되지는 않습니다.

자주 묻는 질문

PostgreSQL 서버를 업그레이드해야 하나요?

이 뉴스의 두 CVE는 pgJDBC 드라이버 문제입니다. 이번 수정 사항에 대응할 때 먼저 Java 애플리케이션의 JDBC 의존성을 확인해야 합니다. 서버 자체의 별도 보안 업데이트 여부는 PostgreSQL 서버 보안 공지를 따로 확인하세요.

requireAuth를 쓰지 않아도 CVE-2026-107314가 문제인가요?

아닙니다. 공식 보안 설명에 따르면 해당 설정이 없는 배포는 이 특정 문제의 영향을 받지 않습니다. 다만 이것이 다른 연결 보안 설정을 점검할 필요가 없다는 뜻은 아닙니다.

42.7.14로 올리면 이미 저장된 잘못된 데이터도 복구되나요?

아닙니다. 새로운 패딩 동작이 수정될 뿐 과거에 저장된 데이터는 별도 조사와 정리가 필요할 수 있습니다.

Spring Boot의 버전만 올리면 되나요?

프로젝트별 의존성 관리 결과가 다르므로 보장할 수 없습니다. 가장 중요한 것은 실제 빌드·배포에 포함된 pgJDBC 버전과 해당 서비스의 연결·쓰기 동작입니다.

결론

PostgreSQL JDBC 42.7.14 업데이트는 단순한 버전 교체 이상의 점검이 필요합니다. requireAuth의 예외적 잘못된 설정과 일부 바이너리 쓰기 API의 길이 불일치를 구별해 확인해야 합니다. 먼저 빌드 의존성을 식별하고, 인증 및 데이터 무결성 회귀 테스트를 진행한 뒤 운영에 반영하는 절차가 합리적입니다.

공식 자료

• pgJDBC 42.7.14 릴리스 노트
• pgJDBC 보안 권고 — 두 CVE 영향과 우회·수정
• NVD: CVE-2026-107314
• NVD: CVE-2026-107315

작성 단계: 3차 편집 초안. 실제 프로젝트 테스트, 사이트 중복 확인, 검색량 측정 및 최종 SEO 인수 데이터 검증은 수행되지 않았습니다.

이미지: AI 생성 연출 이미지 1장과 공식 취약점 정보에 근거해 제작한 도해 2장입니다. 생성된 도해는 제품 공식 UI 스크린샷이 아닙니다.