Tomcat Attachment Error

2025-06-18 工作雜記 tomcat tomcat 9.0.106

這幾天在公司測試環境頻繁的出現下面的錯誤訊息:

Caused by: org.springframework.web.multipart.MultipartException: Could not parse multipart servlet request; nested exception is org.apache.tomcat.util.http.fileupload.impl.FileCountLimitExceededException: attachment

這條訊息是這樣說的: 檔案數量限制 (Could not parse multipart servlet request) 。

我苦思了兩天，回想這一個禮拜我都沒有任何維護測試環境的紀錄，為什麼卻在這兩天開發的工程師頻頻像我反應類似的錯誤訊息，而且他們都說自己的本機環境不會上道測試機反而會出錯。最終我實在忍不住到處詢問期胎維護工程師。我們大約找了半天左右才發現是 tomcat 9.0.106 新增對 multi-part request 的限制，預設是 10。

我的天呀！小版本號不修復 bug 給我新增個 API 限制！這違反 「語義化版本控制、向下相容性和最少驚訝原則」。我只能說: 「我好驚訝！好險！這是發生在測試環境！」。

另外，我還認真的尋找原始需求出處: Refactor TaskQueue to use RetryableQueue interface #861，其中的 需求敘述並未提到 新增 maxPartCount 的限制，實在不清楚為什麼新增。或許開發者在開發過程中靈光一閃加了過去被提出的需求也說不定。

以下是 doc 文件的原文

<tr id="Attributes_Common Attributes_maxPartCount"><td><code class="attributeName">maxPartCount</code></td><td>
      <p>The maximum total number of parts permitted in a request where the
      content type is <code>multipart/form-data</code>. This limit is in
      addition to <code>maxParameterCount</code>. Requests that exceed this
      limit will be rejected. A value of less than 0 means no limit. If not
      specified, a default of 10 is used.</p>
</td></tr>

問題排除方式 新增: maxPartCount="-1"

<!-- 省略 -->
<Connector
    maxPartCount="-1"
/>
<!-- 省略 -->

好吧～抱怨也就到這了，幸好是發生在測試機，發生在正式環境後果不堪而想。另外，經過這次也有發現人機溝通的重要性。因為tomcat更新得很頻繁，過去維運團隊採用了tomcat 小本號更新，雖然運作了好幾年都沒有問題但是缺少更新的日誌與通知，花費了數天尋找問題。也許可以加強這一小快，讓未來出現類似的狀況可以更快被發現。

2025-06-19 07:36 更新

後來我尋找信件紀錄發現新增 maxPartCount 參數是因為要解決 CVE-2025-48988 漏洞。

以下是信件內容

[SECURITY] CVE-2025-48988 Apache Tomcat - DoS in multipart upload
CVE-2025-48988 Apache Tomcat - DoS in multipart upload

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.7
Apache Tomcat 10.1.0-M1 to 10.1.41
Apache Tomcat 9.0.0.M1 to 9.0.105

Description:
Tomcat used the same limit for both request parameters and parts in a
multipart request. Since uploaded parts also include headers which must
be retained, processing multipart requests can result in significantly
more memory usage. A specially crafted request that used a large number
of parts could trigger excessive memory usage leading to a DoS. The
maximum number of parts is now configurable (maxPartCount on the
Connector) with a default of 10 parts.

Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.8 or later
- Upgrade to Apache Tomcat 10.1.42 or later
- Upgrade to Apache Tomcat 9.0.106 or later

Credit:
The vulnerability was identified by the TERASOLUNA Framework Security
Team of NTT DATA Group Corporation

History:
2025-06-16 Original advisory

References:
[1] https://tomcat.apache.org/security-11.html
[2] https://tomcat.apache.org/security-10.html
[3] https://tomcat.apache.org/security-9.html

信件連結: https://lists.apache.org/thread/nzkqsok8t42qofgqfmck536mtyzygp18

Relevant Topics


Recent Posts