プロキシのパスワードは通常、人々から隠されます：スクリーンショットに表示せず、gitにコミットせず、環境変数に保持します。しかし、2026年には、HTTPクライアント自体がそれを漏らす可能性があることが判明しました。4月から7月にかけて、curl、libcurl、libsoupにいくつかの脆弱性が発表され、Proxy-Authorizationヘッダーが誤ってプロキシではなく、ターゲットサイトに送信されることがありました。以下では、これが発生する条件と、自分のスタックを確認するためのステップバイステップの手順を説明します。
何が起こったのか：4ヶ月での4つの漏洩
これらのバグはすべて同じように機能します：クライアントは1つのプロキシのログインとパスワードを記憶し、誤ってそれを次のリンクに送信します。
- CVE-2026-6253 (curlおよびlibcurl 7.14.1–8.19.0).
http://とhttps://に異なるプロキシが設定されている場合、最初のプロキシはパスワードを要求し、2番目は要求しないと、curlはリダイレクト時に最初のプロキシの認証情報を2番目のプロキシに送信します。データはbase64で送信されるため、実質的に平文で送信されます。2026年4月29日にリリースされたcurl 8.20.0で修正されました。コンソールのcurlも影響を受けます。 - CVE-2026-8927 (libcurl 7.12.0–8.20.0). アプリケーションは複数のリクエストに対して1つのハンドルを再利用し、プロキシは環境変数から取得され、認証はDigestで行われます。この場合、プロキシAのProxy-AuthorizationヘッダーがプロキシBに送信され、Bはそれを再送信してあなたになりすますことができます。2026年6月24日のcurl 8.21.0で修正されました。コンソールのcurlは影響を受けません。ほぼ同様のバグがCVE-2026-7168で説明されており、違いはプロキシの選択方法だけです。
- CVE-2026-12547 (libsoup, SoupAuthManager). libsoupはプロキシの認証情報をホスト:ポートのアドレスに結びつけずにキャッシュします。プロキシの設定が変更されると（システムパラメータ、WPAD）、古いヘッダーが新しいプロキシに送信されます。2026年7月21日に公開され、評価は低いです。
- CVE-2026-66339 (libsoup, CONNECTトンネル). HTTPプロキシを介してCONNECTトンネルを設定した後、libsoupはトンネル内の次のHTTPSリクエストにProxy-Authorizationを添付します。ヘッダーはターゲットサーバーに見えます。CVSS 6.5、2026年7月24日に公開されました。
この問題は新しいものではありません。Pythonライブラリrequestsのバージョン2.3.0から2.31.0（CVE-2023-32681）では、HTTPSへのリダイレクト時にProxy-Authorizationヘッダーがターゲットサーバーに送信されていました。プロキシの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を検索します。ヘッダーが手動で設定されている場合、プロキシクライアントの標準メカニズムを介して設定されていない場合（requestsのproxies=、urllib3のProxyManager、libcurlのCURLOPT_PROXYUSERPWD）、これはリダイレクト時の漏洩の候補です。 - プロキシを切り替える際の接続の再利用を探します。 libcurlの1つのハンドル、requestsの1つのセッション、または異なるプロキシを使用して順番にリクエストが行われる1つの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が発表されるでしょう。したがって、1回の漏洩のコストがどれほど重要かが重要です。
- 1つのプロジェクト、1つのアクセス。 すべてのパーサーに共通のログインを保持しないでください。ProxyCoveでは、購入した各プロキシに対して別々のログインとパスワードのペアが提供されるため、1つのスクリプトの漏洩したアクセスは他のトラフィックを開放しません。
- 1つのアクセスに必要以上のトラフィックを保持しないでください。 タスクに応じて少しずつ補充し、半年先に用意しないでください。
- 消費を監視してください。 タスク数の増加なしにトラフィックが急増することは、誰かがあなたのアクセスを使用している最初の兆候です。
- 疑いがある場合はすぐにパスワードを変更し、スケジュールに従って変更してください。 停止なしにこれを構築する方法は、プロキシのパスワードローテーションに関するガイドで説明されています。
どのタイプのプロキシを選ぶべきか、そしてそれが何に関係するのか
漏洩はプロキシのタイプに依存しません：バグはクライアントに存在します。しかし、漏洩のコストは異なります。データセンタープロキシはギガバイトあたりのコストが安く、頻繁なリダイレクトを伴う単純なサイトのパースには、貴重なトラフィックとは別に保持するのが理にかなっています。レジデンシャルプロキシは、実際に必要なタスクに割り当て、別々のアクセスを設定し、自動リダイレクトを無効にする必要があります。最も高価なモバイルプロキシは、最小限の外部依存関係でコードに保持し、各ビルド時にライブラリのバージョンを確認することが重要です。
結論
プロキシのパスワードは、ハッキングやウイルス、人的エラーなしに漏洩する可能性があります：古いlibcurl、他のドメインへのリダイレクト、再利用された接続があれば十分です。チェックリストは短いです：curlとlibcurlは8.21.0以上、requestsは2.31.0以上、urllib3は1.26.19または2.2.2以上、最新のlibsoup、各プロキシに対して別々のセッション、リダイレクトは管理下にあり、トラップの実際のテストが1つ。さらに、各プロジェクトに対して別々のアクセスを持ち、1回の漏洩が1つのスクリプトのコストで済むようにしましょう。