ヤマハがやらかした件について話そう
2026年6月6日、ヤマハにセキュリティ脆弱性の報告書を提出しました。返答がないまま、6月23日から7月2日にかけてJPCERT/CCとメールでやり取りを行いました。7月2日以降、どちらからも情報や返答は一切ありません。最初の報告日から60日が経過したため、主にヤマハに脆弱性の修正を促す目的で、この情報を公開する決断を下しました。
続きを読む前に申し上げておきたいのですが、私には偏見がある可能性が十分にあり、残念ながらこの記事にもそれが表れていると思われます。私は自分の意見を持った一人の人間です。どうか嫌わないでください。
このブログ記事は機械翻訳を使用して翻訳されています。最も正確な情報については、元の記事をご覧ください。
追記、2026年8月5日（公開の数時間後）：2日前の8月3日、ヤマハが密かにVOCALOID6 Editor 6.13.1をリリースしていたことを知らされました。その後、私も少し調べてみましたが、簡単に言うと、これは彼らからの部分的な緩和策であり、完全な修正ではありません。そして、彼らが私のレポートに目を通したことが実際に確認できました！（やったー！）
6.13.1では、Editorはコンテンツストアとテレメトリの認証情報を VSGMain.Initialize() 内でプレーンテキストとして割り当てることはなくなりました。それらはネイティブライブラリに移動され、数秒で誰でも読めるようなマネージドC#内には置かれていないため、その点は評価すべきでしょう！
しかし...
- 認証情報はローテーションされていません！6.13.1のキーは以前と全く同じキーです。別のソースから入手できる（6.12.0.1から6.13.0までの）以前のすべてのリリースには依然としてプレーンテキストで同梱されているため、シークレットは私がレポートを提出した日と全く同じように、今日でも露出しています。最新のバイナリから移動させたとしても、実際にローテーションされない限り意味がありません。
- アクティベーションの認証情報は依然としてプレーンテキストで同梱されています！今はEditorではなく、VOCALOID Authorizerの中にあるというだけです。
- Bridgeの問題は完全にそのままです！
- コードは依然として難読化されていません！
ですから、正直なところ、下記に記載されている内容はすべてまだ有効です。私が注目しているのは、これが私への返答もなく、ユーザーへのアドバイザリもなく、密かにリリースされたということです...これは、ええと、まさに私が後ほど述べている報告プロセスに対する不満そのものですので、あとは皆さんのご想像にお任せします。
追記、2026年8月22日：8月21日にJPCERTからアドバイザリ（JVNVU#90210212）が公開されました。こちらで確認できます：
https://jvn.jp/vu/JVNVU90210212/
その後、私はJPCERTにアドバイザリのいくつかの訂正を依頼し、現在返答を待っています。
2つのCVE識別子が割り当てられ、こちらで確認できます：
https://www.cve.org/CVERecord?id=CVE-2026-76131
https://www.cve.org/CVERecord?id=CVE-2026-76137
アクティベーションサーバーとコンテンツストアの問題は1つの識別子（CVE-2026-76131）に統合され、テレメトリエンドポイントには割り当てられませんでした。Bridgeの問題にはCVE-2026-76137が割り当てられました。
追記、2026年8月27日：ヤマハが6.13.2を公開し、JPCERTが公開した問題を修正したとしています。すべてが修正されたかどうかは確認していませんが、いずれにせよアップデートするべきです：
概要: 6月上旬、悪意のある攻撃者が以下に詳述する様々な操作を実行できるような本番用のシークレットやURLなどが、出荷されたVOCALOID6のバイナリ内に残されていることを発見しました。
この記事は私がこれまで投稿してきた、あるいはこれから投稿するであろうどの記事とも全く異なるものですが、世間に公表したい内容です！
2026年6月5日、私はILSpyというツールを使ってVOCALOID6のバイナリを調べていました。言い訳になりますが、私は退屈していて、ヤマハがどのUIフレームワークを選んだのか見たかったのです。ちなみにWPFです。
調査（と呼べるならですが）の後、いくつかの開発用資料を偶然見つけました。具体的には、Editorにボイスバンクのアクティベーション方法を指示する、完全に難読化されていないコード全体を偶然発見したのです。ヤバいですよね！
さらに調査を進めると、ソフトウェアをいとも簡単にクラックされるのを防ぐ唯一の要素を難読化していないだけでなく、コンパイルされた消費者向けバイナリに本番用シークレットを残していることに気づきました。Editorはライセンスのアクティベーションだけでなく、テレメトリデータの送信、VOCALOID所有者に限定されるべきアセットパックのダウンロード、ライセンスが有効かどうかの確認、そして——おそらく最悪なことに——マルウェアがVOCALOID Bridgeを経由してVOCALOIDにフックし、VOCALOID6 Editorによるものに見せかけたアクションを実行できるようにするためにも、これを使用することになっています。日本の数十億ドル規模の企業から訴えられない範囲で、可能な限り詳細にすべてを説明しましょう！
アクティベーションサーバー (CVE-2026-76131)
この部分の要旨は、ヤマハが（意図的か事故かは別として、ほぼ間違いなく後者ですが）Editorのコードにシークレットをハードコードしていたということです。
Editorの起動時に実行されるVSGMain.Initialize()では、本番用の認証情報（以下は伏せ字）がシングルトンインスタンスにプレーンテキストで割り当てられています：
public static void Initialize() {
VCSServerAPI api = VCSServerAPI.Shared();
VCSActivationAPI act = VCSActivationAPI.Shared();
api.BaseURL = "redacted";
act.BaseURL = "redacted";
api.AppKey = "redacted";
api.AppSecret = "redacted";
act.AccessKey = "redacted";
act.SecretKey = "redacted";
}
これで十分にエキサイティングでないなら、アクティベーションコードのさらに奥深くで、Editor/Authorizerが使用する認証ヘッダー全体も公開されている場所で、彼らがこれを再びやっていると知って喜ぶことでしょう：
Authorization: X-YamahaVocaloid AccessKey=redacted,Date=<date>,Signature=<hex>
署名はHMAC構造で生成され、そのシークレットもクライアントに埋め込まれています。
アクティベーションフローでは、正確なリクエスト/レスポンスのJSONボディも公開されますが、明白な理由（つまり、ヤマハはこれらを変更したくないかもしれず、私は訴えられたくない）により、これらについての詳細は省きます。
要するに、AccessKeyとSecretKeyを持っている人なら誰でも、（あたかもVOCALOID6 Editorであるかのように）ヤマハのライブアクティベーションサーバーに署名付きの検証リクエストを送信し、提供したアクティベーションコードの有効性と残りのアクティベーション回数を照会し、どのアクティベーションコードにどのcomponentIDが登録されているかを正確に特定し、コードが使い切られているかどうかを確認することができます。
コンテンツストア (CVE-2026-76131)
さて、これはアクティベーションサーバーに比べればまだマシですが、それでもEditorがヤマハのコンテンツAPIに対して自身を識別するために使用する認証シークレットが公開されています。
Editorは、ニュース、バージョンチェック、利用可能なボイスバンクのカタログ、そして最も重要な、コンテンツパッケージのダウンロードに必要なメタデータに使用される別のAPIと通信します。以前と同様に、ベースURL、アプリケーションキー、アプリケーションシークレットはすべて、VSGMain.Initialize()内でプレーンテキストで割り当てられています。DLLを開き、メソッドを検索すると、そこにあります！
ほとんどのリクエストにおいて、Editorは単にアプリケーションキーとシークレットから作られたHTTP Basic認証を送信しますが、コンテンツ詳細のエンドポイントについては、ヤマハはBasic認証では不十分だと判断したようで、2つ目のHMAC署名ヘッダーを追加しています。もし署名の作成に必要なシークレットが、それを作成するコードのすぐ横に置かれていなければ、それは完全に理にかなった対応だったでしょう。
訴訟のネタになりそうな部分を削除すると、リクエストは以下のようになります：
POST /api/v2/contents/{id}
Authorization: Basic redacted
X-Vapi-Content-Authorization: Signature AccessKey=redacted,Timestamp=<unix_timestamp>,Signature=<hex>
署名は、メソッド、URI、ボディ、アクセスキー、タイムスタンプを組み合わせ、ハッシュ化し、その後公開されたシークレットを使って署名するという、基本的にアクティベーションAPIと同じダブルハッシュ構造を使用して生成されます。
ヤマハが選択した認証スキーム自体は問題ありません... ただ、公式クライアントとして認証するために必要なすべての材料を、VOCALOID6のコピーを持つすべての人に提供しなければの話ですが！
テレメトリエンドポイント (CVE割り当てなし)
この部分の要旨は、ヤマハがGoogle Analyticsプロパティの書き込み用の認証情報も出荷してしまっているということです。
ほとんどのソフトウェアと同様に、VOCALOID6はGoogle Analytics 4のMeasurement Protocolを通じてテレメトリを送信します。Editorは、セッションの開始と終了、使用したボイスバンク、実行したコマンド、パラメータの編集、スタイルプリセットの変更、インストールされたバージョン、言語、地域、その他多くの使用状況情報を報告します。
あなた個人がそれほどの量のテレメトリを好むかどうかは別の議論です（私は好きではありません）。ここでの脆弱性は、これらのイベントを送信するために使用されるMeasurement Protocolの api_secret が、ご想像の通り、同じ難読化されていない消費者向けバイナリに埋め込まれていることです。
念のために言っておくと、GA4のMeasurement Protocolシークレットは、ヤマハのアナリティクスダッシュボードをダウンロードできるようにするものではありません。これは書き込み用の認証情報であり、これを持つ者は誰でも、正当なVOCALOID6クライアントを装ってプロパティに捏造したイベントを送信できることを意味します。
これにより、架空のセッション、偽の機能使用、任意のコマンドイベント、でっち上げのアプリケーションバージョン、およびエンドポイントが受け付けるその他の値で、ヤマハのアナリティクスを汚染することが可能になります。良くても、かわいそうな従業員がクリーンアップしなければならないジャンクデータが生成されるだけであり、最悪の場合、ヤマハが製品、エンジニアリング、またはビジネス上の意思決定を下すために使用する情報が歪められる可能性があります。
VOCALOID Bridge (CVE-2026-76137)
この部分の要旨は、任意のローカルプロセスが、実行中のVOCALOID6 Editorに認証なしのファイルオープンコマンドを送信できるということです。
VOCALOID6は、プロセス間通信のメカニズムとして名前付きパイプとメモリマップトファイルを使用しています。正直なところ、これはかなり標準的なものです。別のプロセスが共有メモリにパスを書き込み、パイプに接続し、1バイトを送信すると、Editorがパスを読み取り、それをStartup()メソッドに渡します。
コーディングの知識があれば、サーバーのループを読むだけで何が問題なのか理解できるはずです：
await serverStream.WaitForConnectionAsync();
await serverStream.ReadAsync(signal);
using var mmf = MemoryMappedFile.OpenExisting(pipeName);
using var acc = mmf.CreateViewAccessor();
int charCount = acc.ReadInt32(0);
acc.ReadArray(4, chars, 0, charCount);
Startup(new string(chars));
問題がわかりますか？わかりませんか？認証トークンも、接続するプロセスが本物のヤマハのコンポーネントであるかどうかの確認も、機能のネゴシエーションもありません。シグナルバイトは読み取られますが、その値は無視されます。グローバルに知られているパイプ名を所有していれば、事実上プロトコル全体を掌握したことになり、その名前はバイナリにハードコードされています！
ここで明確にしておきますが、これ自体はRCE（リモートコード実行）ではありませんし、そうみなすべきではないと思います。攻撃者はすでに同じWindowsマシン上で、おそらくパイプと同じユーザーアカウントか、それ以上の特権でプロセスを実行している必要があります。これが提供するのは、信頼されたアプリケーションのファイルオープンロジックへの、認証されていないルートです。
マルウェアがEditor自体に攻撃者から提供されたパスを処理させ、結果として生じるファイルオープンアクションが信頼されたVOCALOID6プロセスから発生したように見せかけることができるため、これは私の意見では群を抜いて最もセキュリティに直結する部分です。たとえパイプの背後にあるすべてのファイルパーサーが完璧であったとしても、ローカルアプリケーションは、実行可能ファイル内に見えるUUIDを知っているというだけの理由で、隣接する任意のプロセスからのコマンドを決して受け入れるべきではありません。これはセキュリティの基本中の基本であり、ヤマハがこれをQC（品質管理）で通過させたのは恥ずかしいレベルです。
難読化の欠如がどのようにこれらを簡単に発見させたか
今回のケースでは、難読化は根本的な問題を解決するものではありませんが、ヤマハがそれを全く行っていないことで、リバースエンジニアリングのプロジェクトがカジュアルなブラウジングへと変わってしまっています。
VOCALOID6.dllは、ILSpyのような無料でオープンソースのツールで開くことができ、ほんの数秒で読めるC#コードに変換できます。クラス名、メソッド名、フィールド、URL、JSONモデル、認証コード、制御フローに至るまで、すべてが開発者がソースコードで見るのとほぼ正確に同じように提示されます。
ヤマハへ、脆弱性報告プロセスに関して
修正してください。
これをあなた方に報告するのは地獄でした。機能する問い合わせフォームを見つけるために1時間以上もウェブサイトを探し回り、最終的にスウェーデンが選択可能な地域に含まれていない一般的なカスタマーサポートのフォームで妥協しました。
ヤマハから何の返答もないまま17日間待ち、その後JPCERT/CCに連絡しました。JPCERT/CCは3日後に報告を確認しましたが、それでもヤマハからは一度も直接の連絡はありませんでした。
ありがとうございました。愚痴は以上です。
開示タイムライン
訴訟から身を守るため、ヤマハおよびJPCERT/CCとのやり取りの完全なタイムラインをここに示します。
2026年6月5日 - VOCALOID6のバイナリを検査中に、公開されたコードと認証情報を発見
2026年6月6日、~01:30 CEST - ヤマハへ脆弱性報告を提出
2026年6月23日 - ヤマハからの応答がなかったため、JPCERT/CCに連絡
2026年6月23日〜7月2日 - JPCERT/CCとメールを交換し、分析資料を提供
2026年7月2日〜8月5日 - JPCERT/CCからもヤマハからもその後の更新はなし
2026年8月5日 - 最初の報告から60日が経過。この記事を公開。
私は当初、上記の発見をバージョン6.12.0.1で確認しました。6.13.0までの各新しいVOCALOID6 Editorリリースに対しても同じ検査を繰り返しましたが、問題はまったく同じ形で残っていました。バージョン6.13.1（2026年8月3日リリース）では、これらの認証情報の一部がネイティブコードに部分的に移動されていますが、ローテーションはされておらず、根本的な問題は解決していません。詳細については、この記事の冒頭にある更新ノートを参照してください。
私はヤマハのインフラストラクチャやユーザーデータにいかなる形でもアクセスしていません。
この記事の目的は悪用を容易にすることではなく、記事の冒頭で説明したように、ヤマハにこれらの脆弱性を解決しユーザーに知らせるよう促し、圧力をかけることです。
私はヤマハに対し、公開されたすべての認証情報のローテーション、悪用の有無を確認するためのログ監査、GA4 Measurement Protocolシークレットの交換、およびグローバルに共有されるシークレットに依存するクライアント認証の再設計を求めます。さらに、Bridge IPCメカニズムは呼び出し元を認証し、適切なパイプACLを通じてアクセスを制限し、共有メモリオブジェクトを検証し、提供されたすべてのパスを敵対的な入力として扱うべきです。