exploit-garbage/0day-rubbishAI 시대의 취약점 공개를 재정의합니다. 우리는 악용 가능한 0-day를 대량 생산하고 직접 공개하며, 이벤트 기반 압박을 통해 공급업체의 보안 기준을 높이고 업계를 발전시킵니다.
# 0day Rubbish
> **0day 취약점은 AI 시대에 쓰레기가 되었습니다.**
[](./LICENSE)
[](https://0day-rubbish.com/blog)
[](https://0day-rubbish.com/blog)
[](https://0day-rubbish.com/blog)
[](https://0day-rubbish.com)
[](https://github.com/Exploit-Garbage/0day-Rubbish/subscription)
[](https://github.com/Exploit-Garbage/0day-Rubbish/discussions)
[](https://github.com/Exploit-Garbage/0day-Rubbish/commits)
**🌐 공식 웹사이트**: <https://0day-rubbish.com/blog>
---
## 🎯 존재 이유
전통적인 취약점 공개 방식은 망가졌습니다. 느리고, 관료적이며, 비효율적입니다. AI 시대에는 0day를 대규모로 양산할 수 있습니다. 이는 개별 취약점의 가치는 낮추지만, 직접 공개될 때는 더 큰 영향을 미칩니다.
우리는 **이벤트 기반 보안 강화**가 가장 효과적인 접근 방식이라고 믿습니다. 벤더가 실제로 악용 가능한 위협에 직면할 때만 수정을 우선순위에 두기 때문입니다.
## 🔄 공개 프로세스
### 1단계: AI 발견
자동화된 AI 시스템이 실제 소프트웨어 전반을 지속적으로 스캔하여 패턴 분석, 퍼징, 지능형 코드 리뷰를 통해 잠재적인 0-day를 식별합니다.
### 2단계: 검증 및 PoC 개발
각 발견 사항은 수동 검증을 거칩니다. 우리는 악용 가능성을 확인하고 실제 영향을 평가하기 위해 동작하는 개념 증명(proof-of-concept) 익스플로잇을 개발합니다.
### 3단계: 정기적 공개 공개
매주 — 월요일 또는 화요일 — 우리는 발견하고 검증한 새로운 배치의 검증된, 악용 가능한 0-day 취약점을 공개합니다:
- 전체 기술 분석 및 근본 원인
- 동작하는 PoC 익스플로잇 코드
- 영향을 받는 버전 및 시스템
- 영향 평가
- 권장 완화 조치
지연 없음. 관료주의 없음. 오직 사실만.
**모든 벤더에게**: 해커가 이 취약점들을 악용하기 전에 수정을 완료하시길 바랍니다.
## ⚡ 핵심 원칙
- **실제 영향만**: 실제 사용자 기반이 있는 실제 시스템에 영향을 미치는 취약점만 공개합니다
- **가치 없는 대상 제외**: 악용 불가능한 취약점이나 사용자 채택률이 미미한 기기는 제외됩니다—가치가 전혀 없는 쓰레기입니다
- **속도 우선**: 직접 공개는 전통적인 채널보다 더 빠른 조치를 이끌어냅니다
- **주장보다 증명**: 모든 공개에는 동작하는 익스플로잇이 포함됩니다
- **양보다 영향**: 고위험, 광범위하게 배포된 취약점에 집중합니다
- **투명성**: 전체 기술 세부 정보, 숨겨진 의도 없음
- **비영리**: 금전적 이익이 아닌 보안 연구에 대한 열정으로 운영됩니다
## 🤝 협력
우리는 다음과 협력합니다:
- 자동화된 보안 연구를 발전시키는 최고 AI 모델 제공업체
- AI 기반 발견을 탐구하는 보안 연구원
## 🤖 사용된 AI 모델
우리의 자동화된 취약점 발견은 선도적인 AI 제공업체의 최첨단 대규모 언어 모델을 활용합니다:
- **Anthropic (Claude)** - 심층 보안 패턴 인식 및 추론
- **OpenAI** - 고급 추론 및 코드 분석
- **DeepSeek** - 특화된 취약점 탐지
- **Z.ai (GLM)** - 장문맥 코드 분석
- **Moonshot (Kimi)** - 장문맥 보안 분석
---
## 📋 공개된 취약점
AI 기반 연구 프로세스(다중 LLM 앙상블: Claude, OpenAI, DeepSeek, GLM, Kimi)가 실제 엔터프라이즈 소프트웨어에서 0-day를 발견합니다. 아래의 모든 권고문에는 **전체 근본 원인 분석**과 **동작하고 재현 가능한 익스플로잇 스크립트**가 포함됩니다 — 탐지 전용 보고서도, 숨겨진 세부 정보도 없습니다.
### 최신 배치 — 배치 16 (6개 권고문)
*감사자의 자체 도구로 입증해야 했던 여섯 건의 발견 사항이며, 그중 어느 것도 도구가 보여준 것 이상을 주장하지 않는다. 2007년대 인증 모델에서 벗어나지 못한 PHP 엔드포인트를 겨냥한 익명 업로드 쌍 하나, 자체 호스트명 검증기를 뒤집은 라우팅 데몬의 진단 엔드포인트 하나, SOAP 앱 설치 필드가 셸이 된 소비자용 라우터 하나, 그리고 산업용 셀룰러 라우터의 셸로 구성된 설정 표면에 대한 세 개의 별도 진입점. 여섯 건 중 네 건은 원시 소스 기록이 시사한 것보다 낮은 수치를 게시하며, 그 각각의 하향 조정은 점수 옆에 산술과 함께 인쇄되어 있다.*
| # | 제품 | 영향받는 버전 | CVSS | 분류 | 권고 및 PoC |
|---|---------|------------------|------|-------|-----------------|
| 1 | NETGEAR RAX120 (Nighthawk AX12) | V1.2.5.18 | **6.8** \* | LAN 측 관리 평면의 SOAP InstallApp 액션이 `apName` 인자를 통해 `rm -rf` 셸 명령을 구성하며, `$(...)` 치환이 명령어 단어가 해석되기 전에 root로 구성된 웹 스택에 도달한다 | [InstallApp apName → 셸 명령 치환](https://0day-rubbish.com/blog/soap-installapp-apname-command-injection-root-rce) |
| 2 | NUUO Crystal Server | 3.19.0.85 | **9.8** \* | 세션도, 확장자 게이트도, 경로 검사도 없는 순수한 `copy()` 업로드 엔드포인트로, 벤더의 단종된 제품 라인이 유명하게 만든 웹 루트 착지 패턴을 이어가며, 단일 익명 요청 쌍이 실행 가능한 페이지를 작성하고 이를 다시 가져온다 | [upload.php → 웹 루트 쓰기 → 웹 측 코드 실행](https://0day-rubbish.com/blog/nuuo-crystal-server-unauth-upload-php-webroot-write-rce) |
| 3 | Raritan PX3 PDU G4 | 펌웨어 4.3.14 | **8.8** \* | 호스트명 검증기가 자체 반환 검사를 뒤집는 진단 `ping`/`traceroute` 핸들러로, 모든 일반 인증 세션에서 도달 가능하며, `netstat`은 진단 쌍에 없는 관리자 전용 속성을 지닌다 | [diag ping → 반환값 반전 → 셸 주입](https://0day-rubbish.com/blog/raritan-px3-pdu-g4-diag-ping-traceroute-command-injection) |
| 4 | Moxa MAR-2000 FWR_MAR2000 V1.0 Build 15010909 | V1.0 Build 15010909 | **7.2** \* | 관리 UI의 프로그램 테이블이 `argument` 필드를 사용자 프로그램 런처의 명령줄로 그대로 전달한다 | [Executer argument → 프로그램 실행 주입](https://0day-rubbish.com/blog/mar-2000-executer-program-argument-command-injection) |
| 5 | Moxa MAR-2000 (동일 제품, 동일 배치) | V1.0 Build 15010909 | **7.2** \* | 다섯 개의 별도 `ipsec.py` 핸들러가 터널 주소 필드의 공격자 텍스트를 담아 라우트 관리 명령으로 셸 아웃하며, 한 제품의 발견 사항은 배치 간에 절대 분할되지 않는다 | [터널 주소 → 라우트 관리 셸](https://0day-rubbish.com/blog/mar-2000-network-ipsec-command-injection) |
| 6 | Moxa MAR-2000 (동일 제품, 동일 배치) | V1.0 Build 15010909 | **7.2** \* | 시나리오 엔진이 저장된 `ping` 조건을 주기적으로 재평가하고, 스레드가 매 패스마다 셸 명령을 다시 구성하므로, 공격자가 요청을 다시 보내지 않아도 저장된 페이로드가 발동한다 | [시나리오 ping → 자동 실행 스레드](https://0day-rubbish.com/blog/mar-2000-scenario-ping-command-injection) |
\* 여섯 건 모두 하나 이상의 해석을 게시한다. 각 권고는 자체 벡터와 산술을 갖춘, 거부했거나 조건부로 만든 해석들을 자신이 지지하는 해석 옆에 함께 담고 있다:
> - **발견 1** — `AV:A/PR:H`에서 게시된 **6.8**: 출하된 어떤 산출물도 WAN 측 노출을 입증하지 않으며, 해당 동작은 관리자 계층에 속하므로, 순진하게 8.8-그리고-네트워크화된 해석의 양쪽 절반 모두 산출물 검사에서 무너졌고, 소스 레코드 자체의 8.8은 헤드라인이 아니라 PR:L 변형으로 그 산술과 함께 내부에 표시된다. 7.2에서의 `AV:N`은 관리 평면이 의도적으로 노출된 배포를 위한 라벨링된 조건부이다.
> - **발견 2** — `PR:N`에서 **9.8**. 단일 익명 요청 쌍; 웹 계층은 자신이 기록한 것을 그대로 다시 제공한다. 실행은 복제 환경의 웹 서비스 계정으로 귀결되며 정확히 그렇게 보고된다: 디바이스 측 서비스 아이덴티티는 측정된 적이 없으며 주장되지 않는다. 10.0에서의 `S:C`는 산술과 함께 인쇄되고 기각된다; `AV:A` 8.8은 관리-VLAN 격리를 위한 라벨링된 조건부이다; 디바이스-아이덴티티-불명이라는 주의사항은 요약에 눈에 띄게 인쇄되고 파일명과 본문에 반복된다: 이 발견의 헤드라인, 슬러그 또는 본문 어디에도 "root" 또는 "system" 주장은 담겨 있지 않다. 벤더의 단종된 라인에 있는 패밀리-모델 업로드 계보는 이 권고 시리즈의 사내 규칙에 따라 어떤 식별자도 없이 패턴으로서 기술된다.
> - **발견 3** — `PR:L`에서 **8.8**: 출하된 `netstat` 대 진단 속성 비대칭이야말로 어떤 일반 세션이든 의도된 주체 클래스임을 입증하는 산출물이다; 공장 기본 계정 쌍은 자체적인 조건부 `PR:N` 9.8 해석과 함께 별개의 인접 약점으로 공개되며, 결코 이 발견의 벡터로서가 아니다. 7.2에서의 `PR:H`는 인쇄되고 기각된다.
> - **발견 4-6** — 세 가지 모두 `PR:H`에서 **7.2**이며, 소스 레코드의 8.8이 수정된 881-관계 패밀리 규칙 하의 `PR:L` 산술이라는 정정과 함께 인쇄되고, 기각된-변형 산술이 나란히 표시된다. 세 가지 공장 기본 자격 증명 조건부(각각 9.8, 변경되지 않은 경우)는 라벨링되며 결코 헤드라인이 되지 않고, `S:C` 9.1은 세 가지 모두에 대해 인쇄되고 기각된다. 세 가지 모두 시나리오-핑 싱크에서 세미콜론 페이로드가 실패하고 평가 스레드를 차단한다는 정직한 부정적 결과를 담고 있으므로, 작동하는 형태(`$(...)`, 개행)는 테스트와 함께 인쇄된다.
> - **검증 경계, 일관되게 명시됨** — 이 배치의 모든 샌드박스 마커 `uid=0`은 이를 테스트하는 데 사용된 복제 환경의 속성이며, 출하된 이미지가 자체 웹 스택을 root로 구성하는 경우 그것은 그렇게 인쇄된 이미지 내 사실이다. 어떤 발견도 디바이스 측 아이덴티티를 매트릭스-주장하지 않으며, 이 배치 어디에도 라이브-디바이스 주장은 없다: 세 가지 발견은 `격리된 클라우드 호스팅 샌드박스에서의 싱크-레벨 복제`로 테스트되었고, 하나(Crystal Server)는 자체 VM 이미지 내부의 종단간 HTTP 체인으로, 하나(PX3)는 이미지로부터의 명령어-레벨 및 싱크의 명령-레벨 복제로(종단간 없음; RPC→cfgd→하드웨어 체인은 에뮬레이션 하에서 완료되지 않았음), 그리고 하나(RAX120)는 명령어-레벨 요청-경로 디스어셈블리와 세 가지 상호 독립적 마커 및 하나의 양성 대조군에 대한 네이티브-gcc 싱크 복제로 테스트되었다.
> - **Root 및 아이덴티티 주장, 하나씩 검증됨**: 게시된 9.8(`발견 2`)은 root 또는 system을 명시적으로 주장하지 않는다; 게시된 `발견 4-6` 슬러그 주장은 "관리 스택에 셸-주입됨"에서 멈추며, 복제 샌드박스 아이덴티티가 `uid=0` 라인의 출처로 공개된다; RAX120 발견의 슬러그와 인라인 주장은 배치에서 유일하게 root라는 단어를 담고 있으며, 그 앵커 둘 모두는 이미지 내 lighttpd `User root` 구성에 더해 세 개의 제로-id 마커와 하나의 대조군이며, 결코 라이브 디바이스가 아니다.
**합계**: 6개 권고 · 4개 제품 · 4개 벤더 조직(NETGEAR, NUUO, Raritan/Legrand, Moxa). MAR-2000 시리즈가 그중 세 개를 차지하는데, 한 제품의 적격 발견 항목은 절대 여러 배치로 분할되지 않기 때문이다 · 1개 비인증 체인 · 5개 인증 체인. 이 중 네 개는 명시적으로 관리자급 세션을 요구하고, 하나는 임의의 일반 세션을 요구한다. 단일 6.8이 유명 브랜드 슬롯의 헤드라인을 차지하며, 이는 의도적으로 이 배치에서 가장 극적이지 않은 수치다. `AV`와 `PR` 모두 순진한 모델 템플릿이 시사하는 값이 아니라 출하된 아티팩트가 입증한 값으로 떨어졌고, 공개된 `Totals`는 이를 분명히 밝히고 있다. 여섯 개 중 네 개는 원시 소스 기록이 시사한 것보다 최소 한 개 수치를 낮게 공개한다 — 증거 없는 WAN 측이 두 번, 잘못 입력된 PR 등급이 네 번 — 그리고 그 모든 하향 조정은 독자가 볼 수 있는 곳에 인쇄되어 있으며, 기각된 산술, 벡터, 근거 및 정정 이력이 살아남은 점수 옆에 함께 표시된다.
**도구가 실제로 보여준 것** — 이 배치의 신뢰성이 바로 이것에 달려 있으므로 명시한다:
- **두 개의 체인은 종단 간, 네 개는 싱크까지.** 발견 2는 벤더 자체의 VM 이미지에 대해 완전한 익명 HTTP 요청 쌍을 실행하여 작성된 페이지의 실행을 확인했다. 발견 3의 `diag` 핸들러는 공개된 펌웨어로부터 명령어 수준에서 검증되었고, 추가로 세 가지 페이로드 형태의 명령 수준 주입과 무해한 대조군으로 검증되었다. 발견 4-6은 펌웨어 소스 분석과 각 정확한 싱크 구성의 네이티브 gcc 셸 복제(마커 및 무해한 대조군 포함)로 검증되었다. 발견 1은 디스어셈블리에서 요청 경로 라인 수준으로 검증된 후, 세 개의 독립적 마커와 무해한 대조군에 대한 네이티브 gcc 싱크 복제로 검증되었다. 비라이브 발견에 대해서는 종단 간 주장을 하지 않으며, 각 발견의 README 행에는 "디스어셈블리" 또는 "복제"라고 명시되어 있다.
- **관점, 일관되게:** 이 배치의 어떤 발견에서도 요청이나 실행이 신뢰할 수 없는 네트워크 경계를 넘지 않았다. 발견이 복제 환경보다 넓은 범위를 주장하는 경우, 그 주장은 출하된 아티팩트 — 이미지 내 바인딩 또는 이미지 내 웹 스택 구성 — 에 근거하며 그렇게 명시되어 있다.
- **우리 자체 하네스가 제공한 것** — 우리가 생성한 상태는 제품 기본값이 아니기 때문이다: 복제 호스트 환경(샌드박스 계정 ID는 호스트의 속성으로 측정된 후, 기기 측에서 주장하지 않는 것에 대한 발견의 주장에 반영됨), 발견과 우연을 구분하는 무해한 대조군, 진입점이 최초 사용 후 닫히는 일회용 폐쇄 마커(단방향 창).
*모든 이전 배치와 그 권고는 [Releases](https://github.com/Exploit-Garbage/0day-Rubbish/releases)에 나열되어 있습니다.*
*모든 이전 배치와 그 권고는 [Releases](https://github.com/Exploit-Garbage/0day-Rubbish/releases)에 나열되어 있습니다.*
---
## 🔁 진행 중인 시리즈 — 주간 공개
이것은 **연속 공개 시리즈**입니다. 지속적인 최적화 덕분에 AI 기반 발견 파이프라인은 이제 안정적인 일일 속도로 새로운 0-day 발견을 생성하며, 검증된 배치를 **주간 주기**로 공개합니다.
- **최신 배치**: 배치 16 — 6개 권고; 16개 배치에 걸쳐 누적 144개
- **다음 공개**: 매주 월요일 또는 화요일
- **향후 범위**: 엔터프라이즈 IT를 넘어 **ICS / SCADA, 에너지, 항공우주** 시스템으로 확장
다음 공개가 게시되는 순간 확인하고 싶다면:
[](https://github.com/Exploit-Garbage/0day-Rubbish) [](https://github.com/Exploit-Garbage/0day-Rubbish/subscription) [](https://0day-rubbish.com/blog)
> ⭐ **Star**로 북마크 · 👁 **Watch**(사용자 지정 → Releases + Discussions)로 새 배치 알림 · 🌐 블로그 **팔로우**로 권고별 업데이트 확인.
---
## 📂 취약점 제출 형식
공개된 모든 취약점은 표준화된 디렉터리 구조를 따릅니다:
```
product/
└── <vendor>/
└── <version>/
└── <vulnerability_type>/
├── exploit/ # Exploit scripts and PoC code
├── analysis.md # Detailed vulnerability analysis
└── summary.md # Brief vulnerability overview
```
### 디렉터리 규칙
- **product/**: 모든 취약점의 루트 디렉터리
- **<vendor>/**: 벤더 또는 제품 이름 (예: `apache`, `cisco`, `sonicwall`)
- **<version>/**: 영향을 받는 버전 범위 (예: `6.11.0`, `12.4.2`)
- **<vulnerability_type>/**: 분류 (예: `unauth-rce`, `auth-bypass`, `deserialization-rce`)
### 각 취약점 디렉터리의 필수 파일
1. **exploit/**: 동작하는 익스플로잇 스크립트와 PoC 코드가 포함된 디렉터리
2. **analysis.md**: 근본 원인, 공격 벡터, 영향을 포함한 포괄적인 기술 분석
3. **summary.md**: 영향을 받는 버전과 빠른 완화 단계를 포함한 간결한 취약점 개요
### 예시
```
product/
└── sonicwall/
└── sma-12.4/
└── preauth-deserialization-rce/
├── exploit/
│ └── poc.py
├── analysis.md
└── summary.md
```
**AI 시대의 취약점 공개 방식을 재정의하는 데 함께해 주세요.**