[Tomcat] FileCountLimitExceededException 이슈 수정

개요

---

회사 업무 중 자바 레거시 버전을 사용하는 서비스의 버전을 업그레이드하는 작업이 있었다. 자바 버전을 올리며 스프링 부트, 톰캣, 아파치 등의 버전도 함께 업그레이드하게 되었는데 그중 톰캣에서 발생한 이슈에 대해 정리한다. 로컬에서 어플리케이션을 구동하여 임베디드 톰캣으로 테스트했을 때는 이상이 없던 multipart 업로드 기능이 개발서버의 톰캣을 통해 구동해서 테스트 하기만 하면 아래와 같은 예외를 던졌다.

그림 1. 톰캣 에러 로그

동일한 버전의 코드로 어플리케이션을 빌드했기 때문에 원인은 임베디드 톰캣 - 설치된 톰캣간의 버전 차이로 추측했고, 그 부분을 중심으로 원인 파악을 해보았다.
 

원인 파악

---

기능 점검

우선 이슈가 어느 기능에 한정되는지를 먼저 정확히 해야 할 필요가 있었다. 이슈가 발생한 기능은 여러 텍스트 입력 값과 이미지 파일 2개를 첨부하여 서버에 요청하는 기능이었다. 그러나 웹 서비스에서 이러한 텍스트 - 파일 조합으로 서버에 요청하는 기능은 적지 않았기 때문에 다른 기능에서도 동일한 이슈가 발생하는지 확인 과정을 거쳤다.
 
비슷한 구조의 다른 기능들을 모두 점검해 보았지만, 결론적으로는 이번 이슈가 발생한 회원정보 변경 기능만 해당함을 알 수 있었다. 

---

톰캣 점검

이슈의 범위를 확정했으니, 다음으로는 근본 원인에 대해 조사를 해보았다. 에러 로그를 보니 tomcat과 관련이 있어 보였고 임베디드 톰캣과 개발 서버에 설치된 톰캣간 차이를 조사해 보니 버전의 차이가 있었고 아래와 같았다.

• 임베디드 톰캣(로컬 구동): 10.1.31 (Spring boot 3.3.5 포함)
• 설치형 톰캣(개발 구동): 10.1.42

기존에는 개발 톰캣도 임베디드 톰캣과 동일한 버전으로 맞추어서 업그레이드를 진행했으나, 최근 해당 버전의 보안 취약점이 발견되어 보안팀으로부터 업그레이드를 권장받아 버전을 올렸다. 마이너 버전만 변경되는 건이라 크게 이상이 없을 줄 알았지만, 이 부분에서 이슈의 원인을 찾을 수 있을 것 같아 톰캣의 릴리즈 노트를 확인해 보았다.

---

이슈 원인 확인

톰캣 공식 릴리즈 노트를 확인해보니 10.1.42 버전에서 개선된 내용 중 multipart upload와 관련된 취약점과 그 개선에 대한 항목을 찾을 수 있었다.

그림 2. 톰캣 릴리즈 노트

해당 취약점 코드는 CVE-2025-48988 이며, 요약하면 아래와 같다.

• 영향 버전
  • Tomcat 9.0.87 이하
  • Tomcat 10.1.39 이하
  • Tomcat 11.0.0.-M15 이하
• 취약점 요약
  • multipart/form-data 요청 처리 시, 각 파트에 대한 수나 크기에 제한이 없다면 과도한 리소스를 소비하게 된다. 공격자가 이 점을 이용하여 매우 많은 파트 혹은 큰 파트를 가진 요청을 보내 CPU, 메모리를 소진시켜 Dos를 유발할 수 있다.
• 개선점
  • multipart 요청에 대한 최대 파트 수의 기본값을 10으로 설정한다.

결국 원인은 업그레이드된 톰캣에서는 multipart 요청의 파트 수를 10개로 제한하는데, 이슈가 된 회원정보 변경의 경우는 약 20개의 필드를 요청에 포함하고 있었고 다른 요청들은 10개 미만의 파트를 포함하고 있어 발생한 것이었다.
 

문제 해결

---

릴리즈 노트를 보면 위에서 제한한 값은 maxPartCount라는 값이며, 톰캣 Connector 설정에서 바꿀 수 있다고 되어 있다. 따라서 아래와 같이 톰캣 설치 경로의 conf/server.xml 에 접근하여 설정을 추가해 주면 해결할 수 있다.

그림 3. 톰캣 커넥터 maxPartCount 설정

만약 아파치를 같이 사용하여 커넥터가 2개 이상 있다면, 해당 커넥터에도 동일하게 설정을 해주어야 동작한다. 해당 값에 -1을 넣게 되면 제한 없이 사용할 수 있으나, 취약점에서 설명된 Dos 공격에 대한 대처가 어려워지므로 운영되는 서비스의 상황을 고려하여 설정하는 것이 좋을 것 같다.