프록시 비밀번호 유출 curl, libsoup 및 requests: 확인

프록시 비밀번호는 일반적으로 사람들에게 노출되지 않도록 보호됩니다: 스크린샷에 표시하지 않고, git에 커밋하지 않으며, 환경 변수에 보관합니다. 그러나 2026년에는 HTTP 클라이언트가 이를 유출할 수 있다는 사실이 밝혀졌습니다. 4월부터 7월까지 curl, libcurl 및 libsoup에서 여러 가지 취약점이 발견되어 Proxy-Authorization 헤더가 잘못된 프록시로 전송되거나 심지어 목표 사이트로 직접 전송되는 경우가 발생했습니다. 아래에서는 이러한 상황이 발생하는 조건과 자신의 스택을 점검하는 방법을 단계별로 설명합니다.

무슨 일이 있었나: 4개월 동안의 4가지 유출

이 모든 버그는 동일한 방식으로 작동합니다: 클라이언트는 하나의 프록시에 대한 로그인과 비밀번호를 기억하고 실수로 이를 체인으로 전송합니다.

CVE-2026-6253 (curl 및 libcurl 7.14.1–8.19.0). http://와 https://에 대해 서로 다른 프록시가 설정되어 있고, 첫 번째는 비밀번호를 요구하지만 두 번째는 요구하지 않는 경우, curl은 스킴 변경 시 리디렉션 중 첫 번째 프록시의 자격 증명을 두 번째 프록시로 전송합니다. 데이터는 base64로 전송되므로 사실상 평문으로 전송됩니다. 2026년 4월 29일에 출시된 curl 8.20.0에서 수정되었습니다. 콘솔 curl도 취약합니다, 라이브러리뿐만 아니라.
CVE-2026-8927 (libcurl 7.12.0–8.20.0). 애플리케이션은 여러 요청에 대해 하나의 핸들을 재사용하며, 프록시는 환경 변수에서 가져오고 인증은 Digest 방식으로 진행됩니다. 이 경우 A 프록시의 Proxy-Authorization 헤더가 B 프록시로 전송되어 B 프록시가 자신을 당신으로 가장할 수 있습니다. 2026년 6월 24일에 출시된 curl 8.21.0에서 수정되었습니다. 콘솔 curl은 영향을 받지 않습니다. CVE-2026-7168에서 거의 동일한 버그가 설명되어 있으며, 프록시 선택 방식만 다릅니다.
CVE-2026-12547 (libsoup, SoupAuthManager). libsoup는 프록시 자격 증명을 host:port 주소에 연결하지 않고 캐시합니다. 프록시 설정이 변경될 때(시스템 매개변수, WPAD) 이전 헤더가 새로운 프록시로 전송됩니다. 2026년 7월 21일에 발표되었으며, 평가는 낮습니다.
CVE-2026-66339 (libsoup, CONNECT 터널). HTTP 프록시를 통해 CONNECT 터널을 설정한 후 libsoup는 Proxy-Authorization을 터널 내의 다음 HTTPS 요청에 첨부합니다. 헤더는 이미 목표 서버에 의해 확인됩니다. CVSS 6.5, 2026년 7월 24일에 발표되었습니다.

이 이야기는 새로운 것이 아닙니다. Python 라이브러리 requests의 2.3.0부터 2.31.0까지 (CVE-2023-32681) 리디렉션 시 Proxy-Authorization 헤더가 HTTPS로 전송되었고, 로그인과 비밀번호가 프록시 URL에 직접 입력된 경우에 발생했습니다. urllib3의 1.26.19 및 2.2.2 (CVE-2024-37891)에서는 수동으로 설정된 헤더가 외부 도메인으로 리디렉션될 때 제거되지 않았습니다.

프록시 작업에 왜 이것이 중요한가

유료 프록시의 비밀번호는 돈과 같습니다. 이를 획득한 사람은 당신이 접근을 변경하기 전까지 당신의 트래픽을 소모합니다. 기가바이트에 대해 지불할 때 이는 직접적인 비용이며, 팀 전체가 공유하는 경우에는 다른 사람의 IP로 인한 행동도 포함됩니다.

가장 취약한 시나리오는 다음과 같습니다:

자동으로 리디렉션을 수행하는 파서 및 모니터링. 목표 사이트나 중간 리디렉션이 요청을 헤더를 수집하는 도메인으로 유도할 수 있습니다.
여러 프록시를 사용하는 스크립트: 서로 다른 스킴에 대해 서로 다른 프록시를 사용하고, 동일한 연결에서 요청 간 프록시를 전환하며, "비밀번호가 있는 프록시"와 "비밀번호가 없는 프록시"를 혼합합니다.
Linux 서버에서 장기 실행 프로세스, 여기서 libcurl 및 libsoup는 시스템 패키지와 함께 제공되며 배포판과 함께 업데이트되며, 귀하의 코드와는 별개입니다.
WPAD 및 PAC 파일이 있는 기업 네트워크: 프록시가 애플리케이션의 개입 없이 변경되며, 이 경우가 CVE-2026-12547에서 설명됩니다.

스택을 점검하는 방법: 단계별

실제 libcurl 버전을 확인하세요, 콘솔 curl만이 아닙니다. curl -V 명령은 둘 다 보여주지만, 애플리케이션은 자신의 라이브러리 복사본으로 빌드될 수 있습니다. Python의 경우 pycurl을 사용하여 python -c "import pycurl; print(pycurl.version)"를 실행하고, PHP의 경우 curl_version()을 호출하세요. 안전한 경계: 8.21.0 이상 또는 수정된 브랜치 8.20.1+, 8.16.1+ 및 8.14.2+입니다.
Python 종속성을 확인하세요. pip show requests urllib3를 실행하세요. requests는 2.31.0 이상, urllib3는 1.26.19 (1.x 브랜치) 또는 2.2.2 (2.x 브랜치) 이상이 필요합니다. 종속성이 전이적으로 도착하는 경우, 파서가 작동하는 동일한 환경 내에서 pip list를 확인하세요.
Linux에서 libsoup를 확인하세요. 이는 GNOME 애플리케이션, WebKitGTK 및 이 스택으로 빌드된 모든 것에 해당합니다. 배포판의 패키지를 업데이트하고 보안 공지를 확인하세요: Red Hat의 CVE 카드에서 영향을 받은 것은 RHEL 6–10으로 표시됩니다.
코드에서 수동으로 헤더를 설정하는 부분을 찾으세요. 전체 리포지토리에서 Proxy-Authorization를 검색하세요. 헤더가 수동으로 설정되고 클라이언트의 기본 프록시 메커니즘을 통해 설정되지 않는 경우 (proxies= in requests, ProxyManager in urllib3, CURLOPT_PROXYUSERPWD in libcurl), 이는 리디렉션 시 유출 후보입니다.
프록시 변경 시 연결 재사용을 찾으세요. 하나의 libcurl 핸들, 하나의 requests 세션 또는 하나의 HTTP 에이전트를 통해 서로 다른 프록시로 요청이 순차적으로 진행됩니다. 가장 간단한 수정 방법: 각 프록시마다 별도의 세션을 사용하세요.
필요하지 않은 곳에서는 자동 리디렉션을 비활성화하세요. requests에서는 allow_redirects=False, urllib3에서는 redirect=False, curl에서는 -L 및 CURLOPT_FOLLOWLOCATION을 설정하지 마세요. 그러면 3xx는 수동으로 처리되며, 다음에 어디로 갈지 스스로 결정할 수 있습니다. 바로 이 우회 방법을 requests와 urllib3의 저자들이 제공합니다.
함정 테스트를 수행하세요. 모든 수신 헤더를 출력하는 간단한 HTTP 서버를 설정하고, 두 번째 동일한 서버로 리디렉션을 만드세요. 프록시와 함께 실제 시나리오를 통해 파서를 실행하세요, http에서 https로 스킴 변경을 포함하여. 서버 중 하나라도 Proxy-Authorization을 감지했다면, 유출이 귀하의 코드에서 확인된 것입니다, 이론이 아닙니다.

주의할 점

Docker 이미지가 독립적으로 작동합니다. 호스트에서 curl을 업데이트했지만, 파서는 오래된 기본 이미지로 컨테이너에서 실행되고 있습니다. 컨테이너 내부에서 확인해야 합니다: docker exec <컨테이너> curl -V.
콘솔 curl과 libcurl은 다르게 업데이트됩니다. CVE-2026-8927는 콘솔 curl에 영향을 미치지 않지만, CVE-2026-6253는 영향을 미칩니다. 터미널에서 최신 curl -V는 귀하의 PHP 또는 Python이 빌드된 라이브러리에 대한 정보를 제공하지 않습니다.
Digest는 보호하지 않습니다. 예, Digest에서는 비밀번호가 평문으로 전송되지 않습니다. 그러나 CVE-2026-8927에서는 공격자가 비밀번호를 필요로 하지 않습니다: 가로챈 헤더를 nonce가 유효한 동안 반복합니다.
URL에 비밀번호를 포함하는 것은 편리하지만 위험합니다. requests에서 유출은 자격 증명이 user:pass@host:port 형식의 프록시 주소에 입력된 경우에 나타났습니다. 이는 형식을 포기할 이유는 아니지만, 라이브러리를 최신 상태로 유지할 이유는 됩니다.
리디렉션은 목표에서 오지 않을 수 있습니다. CAPTCHA 페이지, 동의 배너, 링크 단축기 및 CDN도 3xx 응답을 보냅니다. 크롤러에서 "링크 따라가기"가 많을수록 공격 표면이 넓어집니다.

비밀번호가 유출될 경우 피해를 제한하는 방법

유출을 완전히 배제할 수는 없습니다: 내일 새로운 CVE가 발표될 것입니다. 따라서 한 번의 유출이 얼마나 비용이 드는지가 중요합니다.

하나의 프로젝트, 하나의 접근. 모든 파서에 대해 공통 로그인 계정을 유지하지 마세요. ProxyCove에서는 구매한 각 프록시가 별도의 로그인과 비밀번호 쌍을 받기 때문에, 하나의 스크립트에서 유출된 접근이 나머지 트래픽을 열어주지 않습니다.
하나의 접근에 대해 필요한 것보다 더 많은 트래픽을 유지하지 마세요. 작업에 맞게 조금씩 보충하고, 반년치 미리 준비하지 마세요.
소비를 모니터링하세요. 작업 수가 증가하지 않고 트래픽이 급증하는 것은 누군가가 귀하의 접근을 사용하고 있다는 첫 번째 신호입니다.
의심이 가는 즉시 비밀번호를 변경하세요 그리고 일정에 따라 변경하세요. 중단 없이 이를 설정하는 방법은 프록시 비밀번호 회전 가이드에서 설명되어 있습니다.

어떤 유형의 프록시를 선택해야 하며, 그와 관련된 사항은 무엇인가

유출은 프록시 유형에 따라 달라지지 않습니다: 버그는 클라이언트에 존재합니다. 그러나 유출의 비용은 다릅니다. 데이터 센터 프록시는 기가바이트당 더 저렴하며, 간단한 사이트를 크롤링할 때 빈번한 리디렉션을 위해 이를 비싼 트래픽과 분리하여 보관하는 것이 합리적입니다. 주거용 프록시는 실제로 필요한 작업에 할당하고, 이를 위해 자동 리디렉션이 비활성화된 별도의 접근을 설정해야 합니다. 기가바이트당 가장 비싼 모바일 프록시는 외부 종속성이 최소화된 코드에서 보관하는 것이 좋으며, 각 빌드 시 라이브러리 버전을 확인해야 합니다.

결론

프록시 비밀번호는 해킹, 바이러스 또는 사람의 실수 없이 유출될 수 있습니다: 구식 libcurl, 외부 도메인으로의 리디렉션 및 재사용된 연결만으로도 충분합니다. 체크리스트는 간단합니다: curl 및 libcurl 8.21.0 이상, requests 2.31.0 이상, urllib3 1.26.19 또는 2.2.2 이상, 최신 libsoup, 각 프록시마다 별도의 세션, 리디렉션을 통제하고 하나의 함정 테스트를 수행하세요. 또한 각 프로젝트에 대해 별도의 접근을 설정하여 하나의 유출이 하나의 스크립트의 비용만 발생하게 하고 전체 잔액을 잃지 않도록 하세요.