Starmanで遅いHTTP本文がワーカーを占有｜0.4019への更新と受信期限の確認

PerlのPSGI/Plack向けWebサーバーStarmanで、HTTPリクエストを処理する前の段階に複数のセキュリティ修正が入りました。2026年10月24日に公開された0.4019では、遅い本文送信によるワーカー占有、chunked本文によるメモリー・CPU消費、HEADなどの応答本文の扱いを修正しています。Starmanを使うWebアプリの担当者は、アプリのコードだけでなく、実行環境のStarmanを更新し、前段プロキシとタイムアウト設定を確認してください。

本稿は10月26日に一次資料を確認した更新情報と運用上の判断材料です。主にCVE-2026-115817の本文受信タイムアウトを扱い、同じ版で直った関連問題も整理します。攻撃を再現して実測した記事ではなく、公式の変更履歴・修正コードから確認できる事実と、本サイトの確認提案を区別します。資料に記載された試験や攻撃条件は、実環境での悪用確認とは別です。

少ない接続でもワーカーを占有できる条件

Starmanは、あらかじめ起動したワーカープロセスが要求を処理するprefork方式のサーバーです。Starman公式ドキュメント：構成と前段サーバーの推奨は、遅い要求を送るクライアントを考慮し、インターネットから直接要求を受けず、nginxなどの前段サーバーの後ろに置く構成を推奨しています。今回の主な対象は、更新前のStarmanへ未信頼のHTTP本文が届く構成です。

CVE-2026-115817では、従来のread_timeoutがヘッダーの受信を対象とし、本文の読み取りには期限がありませんでした。送信側がヘッダーを完了させた後、本文の送信を止める、または少しずつ送り続けると、処理担当のワーカーを待機させられます。アプリのログイン処理や入力検証へ進む前に資源を使わせるため、アプリで認証を必須にしているだけでは、この受信経路の防御になりません。

本サイトの分析として、リクエスト数が急増していないのに応答が遅くなる場合にも注意が必要です。少数の長い接続で空きワーカーが減ると、後から来る正規利用者の要求が待たされます。ワーカー数を増やす判断だけでは、攻撃者が占有できる資源を増やす結果にもなります。まず外部から本文がどの経路でStarmanへ渡るかを確認し、受信を打ち切る境界を設けることが優先です。

0.4019では待機時間と総時間を別々に制限

Starman公式修正：本文の読み取りごとにread_timeoutを適用では、read_timeoutの既定値5秒を、本文の続きを待つ各読み取りにも適用しています。加えてbody_timeoutは本文全体を受け取る総時間を制限し、既定値は300秒です。片方は「次のデータが来ない時間」、もう片方は「本文を受け取り終えるまでの時間」を扱います。期限に達すると408を返して接続を閉じ、アプリは実行しない設計です。

この二つは代用関係ではありません。無通信の待機だけを制限すると、期限前に少量のデータを送る相手が接続を維持できます。総時間だけなら、完全に止まった接続も長い期限まで残ります。公式の修正は、各読み取りで先に到達する期限を使い、アプリの処理時間は本文受信の制限に含めません。「300秒以内ならアプリの重い処理も止まる」という設定ではありません。

Starman公式修正：本文受信の総時間制限を追加には、総時間制限を0にすると無効化されることも記載されています。低速回線から大きなアップロードを直接受けるために値を上げる場合は、許容する最大の受信時間と同時接続数を業務要件から決める必要があります。本サイトは一律の短縮値を勧めません。既定値へ戻す前にも、起動スクリプトやサービス設定に残る上書き値を確認してください。

同時に直った資源消費と応答の境界

Starman公式変更履歴：0.4019のセキュリティ修正と動作変更には、本文受信の制限以外にも複数の変更があります。CVE-2026-115824ではchunked本文をチャンク全体がそろうまでメモリーへ保持する扱いを改め、一時バッファーへ流します。CVE-2026-115822ではチャンクサイズ行の解析を線形時間へ変え、4 KiBの長さ制限と厳格な構文検査を加えています。本文を読み終えるまで待たせる問題と、読みながら資源を使い切る問題を分けて捉える必要があります。

CVE-2026-115823では、HEAD要求と1xx・204・304応答に本文を送らない修正が入りました。持続接続では、次の応答の先頭だと扱われる位置に余計なデータが残ることが、応答の対応関係へ影響します。また0.4019には、Transfer-EncodingとContent-Lengthの併存時の接続終了など、既報CVE-2026-40560の修正を補完する変更も含まれています。個々のCVEを別々に直すより、版全体の更新とHTTP境界の検証を一組にして進めるのが実務的です。

一方、これらの記載から、任意コード実行や情報窃取が実際に発生したとは判断できません。本稿で確認した一次資料は修正内容と試験を示すもので、運用中のサイトでの攻撃成功件数を示していません。サービス停止、応答の異常、侵害の有無は、それぞれ自社の記録から調べてください。

前段プロキシがある場合も本文の転送方法を見る

nginxが置かれているという構成名だけで安全性を判断しないでください。NGINX公式：proxy_request_bufferingの動作によると、proxy_request_bufferingが有効ならクライアントの本文全体を読み取ってから転送し、無効なら受信した本文を順に転送します。後者では遅い送信の影響が上流へ渡るため、Starmanの受信期限を確認する意味が特に大きくなります。

本サイトでは、公開入口からアプリまでの経路図に、本文をためる場所、接続を維持する場所、時間・容量制限を記入する方法を提案します。通常のAPIとアップロード用のlocationで設定が違う場合や、ヘルスチェック・内部用ポートが別経路で公開されている場合も対象です。nginxの設定例だけでなく、実際の稼働設定とネットワーク到達性を確認します。

バッファリングは更新の代わりにはなりません。要求解析や応答の扱いも同じ版で変わっているためです。また本文を前段へためれば、前段側のメモリー、ディスク、接続時間を管理する必要があります。Starmanへの直接到達を制限しつつ、正規の大容量送信を受け付ける条件と、使わせてよい前段資源を別々に決めてください。

更新は配布先と実行中プロセスを対応付ける

以下は本サイトの運用提案です。最初に、Webアプリの依存定義、コンテナのビルド手順、サーバー上のPerl環境、サービスの起動コマンドを照合します。開発端末で確認した版が本番と同じとは限りません。複数のPerlやローカルのライブラリを使う構成では、サービスがどの実行ファイル・読み込み先を使うかまで確認します。

更新対象はStarman 0.4019です。ディストリビューションが独自に修正をバックポートする場合は、見かけの版だけで除外せず、その提供元の修正情報で今回の変更を含むか確認してください。直接CPANで管理する構成とOSパッケージで管理する構成を混在させると、更新した場所と稼働する場所がずれやすいため、既存の配布方式に沿って適用します。

段階配備では、更新済みの新しいプロセスが正規要求を処理できることを確認してから切り替えます。ファイルを上書きしただけで旧ワーカーが入れ替わったとは判断せず、再起動・再配備の記録と起動時刻を残します。ロールバックが必要になった場合も、脆弱な版を外部へ戻す前に、到達制限や代替の受付方法を決めておく必要があります。

検証は拒否される要求と正規利用を組み合わせる

検証環境では、本文を途中で止めた要求と、少量ずつ送り続ける要求を分け、読み取り待機と総時間の両方が打ち切られるか確認します。本番へ大量接続を送る必要はありません。許可された隔離環境で接続数を抑え、408、接続終了、アプリへ未到達であること、終了後に別の正規要求が処理できることを記録する方法を提案します。

正常系では、実際に利用するアップロードの大きさと回線条件に合わせ、タイムアウトで業務を切っていないか確かめます。加えてHEAD応答、本文なしの応答、持続接続を使うクライアントを確認します。変更履歴には古いHTTP::Tinyが送るchunked終端との互換性変更もあるため、社内スクリプトや定期ジョブを含め、利用するHTTPクライアントも試験対象にしてください。

試験結果には、前段経由とバックエンド直結のどちらを通ったかも残します。前段が先に切断した結果だけではStarman自身の期限を検証できず、直結試験だけでは公開経路の動作を説明できません。運用上許された二つの経路を区別し、実際に制限した層と返した応答を対応付けます。

監視では、408の件数だけで攻撃と断定せず、送信元、経路、要求時間、受信量、ワーカーの稼働状況、CPU・メモリーの変化を同じ時間帯で照合します。低速回線の正規利用や、前段プロキシの設定不整合でも失敗は起こります。逆にアプリのアクセスログに残らない受信途中の接続があり得るため、前段とサーバー側の記録も必要です。

今回の完了条件は、修正版の取得だけでなく、稼働中の全配布先が修正を含み、直接到達の範囲と本文転送の設定を説明でき、拒否と正常利用の試験を終えていることです。更新作業を優先しながら、異常なプロセスやファイル変更など別の侵害兆候がある場合は、Webサーバーの証拠保全と再構築ランブックに沿った調査を切り分けて進めてください。DoSの修正だけを根拠に侵入済みとも無被害とも判定しないことが重要です。