Railway 환경 변수 노출 가능성 (2026년 10월, 최대 1.85% 워크스페이스): 교체해야 할 시크릿과 사용자 조치

회사는 10월 21일 이전에 Railway에 저장한 민감한 환경 변수를 모두 폐기하고 다시 적용할 것을 요청합니다. 여기에는 API 키와 프라이빗 레지스트리 자격 증명이 포함됩니다.

다음 순서로 진행하십시오.

• 환경 변수를 목록으로 정리합니다. 각 서비스의 Variables 탭을 열어 시크릿 값(API 키, 토큰, 비밀번호, 서명 키, 연결 문자열)을 표시합니다
• 각 원본의 대시보드에서 새 값을 발급합니다. AI API, 결제 서비스, GitHub, 클라우드, 외부 데이터베이스 등이 해당합니다
• Railway 변수를 갱신하고 서비스를 재배포합니다. 컨테이너는 시작할 때만 변수를 읽으므로 재배포하기 전까지는 이전 값으로 계속 실행됩니다(회사 가이드)
• 새 값이 작동하는 것을 확인한 뒤 원본에서 이전 값을 폐기하거나 삭제합니다

Railway 안에서만 값을 바꾸면 원본에서 폐기하기 전까지 노출된 값을 계속 사용할 수 있습니다(이 사이트의 참고).

회사는 모든 사용자에게 데이터베이스의 공개 네트워크 접근을 제거할 것을 권고합니다. 회사 가이드에 따르면 공개 접근(TCP 프록시)이 켜진 데이터베이스는 교체하기 전까지 자격 증명만 있으면 인터넷 어디에서나 접속할 수 있습니다.

• PostgreSQL, MySQL, Redis, MongoDB는 데이터베이스 화면의 Regenerate를 사용합니다. 데이터베이스 내부 비밀번호와 변수를 한 번에 바꾸고 열려 있는 세션을 끊습니다(회사 가이드)
• POSTGRES_PASSWORD 같은 비밀번호 변수를 직접 수정하거나 데이터베이스에서 비밀번호를 직접 바꾸지 마십시오. 변수와 데이터베이스가 서로 어긋납니다(회사 가이드)
• 해당 변수(예: ${{ Postgres.DATABASE_URL }})를 참조하는 모든 서비스를 재배포합니다. 붙여 넣은 연결 문자열은 참조로 바꿉니다
• Settings, Networking에서 프로젝트 밖에서 필요하지 않다면 Public Access를 끕니다. 외부(로컬 개발, CI, BI 도구)에서는 새 DATABASE_PUBLIC_URL을 직접 붙여 넣어야 합니다

회사는 GitHub 감사 로그와 앱 접근, 그리고 Docker Hub 같은 레지스트리의 감사 로그를 확인할 것을 권고합니다. 회사 가이드는 다음 점검 항목을 제시합니다.

• 개인 계정: GitHub 보안 로그(90일), 승인된 OAuth 앱과 GitHub Apps, SSH 및 GPG 키, 개인 액세스 토큰. 알 수 없는 항목은 폐기하고 토큰을 재생성합니다
• 조직: 조직 감사 로그(180일). 무엇이든 폐기하기 전에 로그를 내보내십시오. 각 저장소의 배포 키, 시크릿, 웹훅, 협업자를 점검합니다
• GitHub Container Registry(ghcr.io): Railway는 저장해 두었던 GitHub 토큰을 삭제했지만, 해당 토큰은 GitHub에서 폐기하기 전까지 여전히 작동합니다. GitHub에서 이전 토큰을 삭제하고 read:packages 범위의 새 토큰을 만들어 각 서비스에 설정하십시오

가이드는 푸시 권한이 있는 공격자가 비밀번호를 재설정한 뒤에도 남는 웹훅이나 시크릿을 추가할 수 있다고도 경고합니다.

회사의 예비 보고서에 따르면 공격자는 AI 제공업체 API 키를 노린 것으로 보입니다. 회사는 OpenAI, Anthropic, OpenRouter, Grok, Stripe, AWS, GCP용 사용량 확인 가이드를 공개했습니다. 예를 들어 OpenAI 가이드는 다음을 안내합니다.

• 노출되었을 수 있는 키를 삭제하고 같은 프로젝트에 새 키를 만듭니다
• 사용량 화면을 열어 API 키별로 묶고, 노출 기간의 토큰 양, 요청 수, 모델 구성을 평소 트래픽과 비교합니다
• 해당 기간의 지출과 소진된 크레딧 부여가 있는지 청구 내역을 확인합니다
• 초대하지 않은 구성원이나 프로젝트 멤버가 없는지 확인합니다
• 남용이 확인되면 사용량 내역을 보관하고 제공업체 지원팀에 문의합니다

적어도 공격 기간의 시작(10월 20일 13:58 UTC)부터 키를 교체한 시점까지 확인하십시오(이 사이트의 참고).

회사는 대응 과정에서 모든 로그인 세션, Railway 액세스 토큰, GitHub 연결, 스토리지 버킷 자격 증명을 폐기했습니다. 배포가 중단된 동안 푸시된 커밋은 배포되지 않았습니다.

• 가입 때 사용한 같은 Gmail, GitHub 계정 또는 이메일로 로그인합니다. 다른 계정으로 로그인하면 비어 있는 새 계정이 만들어집니다(회사 가이드)
• 계정 설정에서 GitHub를 다시 연결하고, 서비스의 Settings에서 저장소를 다시 연결한 뒤 최신 커밋을 배포합니다
• CLI: railway logout 후 railway login을 실행합니다. CI: 프로젝트 토큰(RAILWAY_TOKEN) 또는 계정/워크스페이스 토큰(RAILWAY_API_TOKEN)을 다시 만들어 CI 시크릿에서 교체합니다
• 버킷을 사용하는 서비스는 새 자격 증명을 적용하도록 재배포합니다. 또한 버킷에 직접 업로드하지 않은 파일이 있거나 본인이 하지 않은 삭제가 있었는지 확인합니다(회사에 따르면 버킷에는 자동 백업이 없습니다)
• 워크스페이스 감사 로그에서 노출 기간 중 팀이나 Railway("Railway Staff"로 표시)가 수행하지 않은 변수 조회, 레지스트리 자격 증명 변경, 배포가 있는지 찾아봅니다

Railway의 환경 변수는 암호화되어 있었지만, 예비 보고서에 따르면 공격자는 탈취한 자격 증명의 조합으로 일부를 복호화했습니다. 호스팅 플랫폼은 앱을 실행하려면 변수를 다시 평문 값으로 되돌려야 하므로, 플랫폼 내부 권한이 탈취되면 암호화만으로는 완전히 보호하기 어렵습니다(이 사이트의 참고).

플랫폼의 암호화와 별개로, 유출되더라도 피해가 제한되도록 시크릿을 보관하십시오. 우선 AI API와 결제 제공업체에서 지출 한도와 알림을 설정하십시오. 운영, 스테이징, 개발용 키를 분리하면 교체해야 할 범위도 줄어듭니다. 시크릿 보관은 .env와 API 키에서 실제로 위험한 것에서 다룹니다.

회사 가이드에 따르면 공개 접근이 켜진 데이터베이스는 연결 문자열이 유출되면 인터넷 어디에서나 접속할 수 있습니다. 프로젝트의 프라이빗 네트워크로만 사용하는 데이터베이스는 연결 문자열이 유출되더라도 외부에서 직접 접속할 수 없습니다.

외부 접근은 보통 로컬 개발, CI, BI 도구에만 필요합니다. 그런 경우에도 필요한 동안만 열거나 별도의 읽기 전용 사용자를 쓰는 방법을 고려하십시오(이 사이트의 참고).

회사 가이드는 연결 문자열과 키를 각 서비스에 붙여 넣지 말고 ${{ Postgres.DATABASE_URL }} 같은 참조 변수로 공유할 것을 권장합니다. 참조를 쓰면 원본 값을 바꾸고 재배포하는 것만으로 모든 서비스에 반영되며, 붙여 넣은 사본을 잊을 일이 없습니다.

같은 취지로, 각 서비스가 어떤 시크릿을 쓰고 어디서 재발급하는지 목록으로 관리하십시오(이 사이트의 참고). 지금처럼 전부 교체해야 할 때 이 목록이 작업 시간을 좌우합니다. 비슷한 사례인 Vercel 보안 사고에서는 나중에 값을 표시할 수 없는 분류로 시크릿을 저장했는지가 중요했습니다.

이번 사고에서 회사는 보관하던 GitHub 토큰을 폐기했고 GitHub 감사 로그와 앱 접근을 검토할 것을 권고합니다. 호스팅 플랫폼에 부여하는 GitHub 접근은 배포하는 저장소로 제한하고, 컨테이너 레지스트리 토큰에는 읽기 권한(read:packages)만 주어 유출 시 영향 범위를 줄이십시오(이 사이트의 참고). 유출된 자격 증명이 계속 유효한 문제는 계속 유효한 유출 자격 증명에서 다룹니다.