プロトタイプ汚染と変数スコープ：グローバル変数が招くV8ランタイムの崩壊とRCEへの扉
JavaScriptのコードを書くとき、私たちは何気なく変数を宣言し、オブジェクトを操作している。しかし、その背後でV8エンジンがどのようにメモリを割り当て、隠しクラス（Hidden Class / Map）を構築し、インラインキャッシュ（Inline Caching）を最適化しているかまで意識できているだろうか。
「たかがグローバル変数」「たかが動的なプロパティ追加」と軽視されたコードは、ランタイムの物理最適化の隙を突き、サプライチェーン全体を巻き込んだリモートコード実行（RCE）という最悪のセキュリティインシデントを引き起こす。
本稿では、変数スコープの不備がどのようにしてプロトタイプ汚染（Prototype Pollution）を誘発し、それがV8のメモリ空間とNode.jsのイベントループをどのように蝕むのか、その深層メカニズムをコードとランタイムの挙動から解き明かす。
—
1. V8エンジンにおけるオブジェクトの物理構造と「隠しクラス」
JavaScriptは動的型付き言語であり、実行時にオブジェクトのプロパティを自由に追加・削除できる。しかし、C++やJavaのように静的なメモリオフセットを持たないオブジェクトから、毎度ハッシュマップルックアップでプロパティを引いていたのでは、モダンWebアプリが要求する数百万OPS（Operations Per Second）のパフォーマンスなど到底達成できない。
ここでV8エンジンは、隠しクラス（Internal Map）という概念を導入する。
// V8の隠しクラス遷移を誘発する典型例
function Point(x, y) {
this.x = x; // Map 0 から Map 1 へ遷移
this.y = y; // Map 1 から Map 2 へ遷移
}
const p1 = new Point(1, 2);
const p2 = new Point(3, 4);
// p1 と p2 は同じ Map 2 を共有し、インラインキャッシュの恩恵を受ける
V8は、プロパティが追加される順序が同じであれば、同じ「Map」をオブジェクトに割り当てる。これにより、プロパティアクセスはハッシュ探索ではなく、メモリ上の固定オフセット（例：ベースアドレスから +8バイト）への直接アクセスへとコンパイル（JIT）される。
グローバルスコープの汚染がもたらす最適化の崩壊
もし、このオブジェクトのプロパティが、不適切に管理されたグローバル変数や、外部から入力された悪意あるキーによって動的に書き換えられたらどうなるか。
オブジェクトのプロパティ構造が実行時に予期せぬ変化を遂げると、V8のJITコンパイラ（TurboFan）が生成した最適化コードは「型フィードバックの不一致（Deoptimization / Megamorphic）」を起こし、コードはスローダウンする。さらに厄介なのは、パフォーマンスの低下だけではない。この動的なプロパティ追加メカニズムの根幹にあるのが、すべてのオブジェクトの祖先である `Object.prototype` である。
—
2. プロトタイプ汚染のメカニズム：なぜグローバルな油断が全体を蝕むのか
プロトタイプ汚染とは、アプリケーションの脆弱なコード（再帰的なマージ関数やディープコピー処理など）を通じて、組み込みの `Object.prototype` に任意のプロパティを注入する攻撃手法だ。
以下の脆弱なユーティリティ関数を見てほしい。
// ⚠️ 危険なディープマージの実装（典型的な脆弱性パターン）
function unsafeMerge(target, source) {
for (let key in source) {
if (typeof source[key] === ‘object’ && source[key] !== null) {
if (!target[key]) target[key] = {};
unsafeMerge(target[key], source[key]);
} else {
target[key] = source[key];
}
}
return target;
}
// 攻撃者が外部から注入するJSONペイロード（例：HTTPリクエストボディ）
const maliciousPayload = JSON.parse(‘{“__proto__”: {“polluted”: “vulnerable”}}’);
const benignObject = {};
unsafeMerge(benignObject, maliciousPayload);
// 衝撃の結果
console.log({}.polluted); // => “vulnerable”
この瞬間、アプリケーション内で新しく生成されるすべてのプレーンオブジェクトが、暗黙的に `polluted: “vulnerable”` というプロパティを継承するようになる。
なぜこれがグローバル変数と結びつくのか？
大規模なNode.jsアプリケーションやフロントエンドのバンドルにおいて、設定情報、グローバルな状態管理ストア、あるいはモジュール間で共有されるコンテキストオブジェクトが、適切なバリデーションなしにグローバルスコープや共通の親オブジェクトを経由して初期化されるとき、この脆弱性が爆発する。
スコープチェーンの最上位、あるいはオブジェクト階層の根源であるプロトタイプチェーンに対する操作が制限されていない環境では、ひとつの変数の汚染が、ランタイム全体が共有するメモリ空間の汚染へと直結するのだ。
—
3. サプライチェーンを突いたRCE（リモートコード実行）への昇格
プロトタイプ汚染は単なる「予期せぬプロパティの混入」にとどまらない。Node.js環境においては、これが致命的なRCE（Remote Code Execution）のトリガーとなる。
Node.jsの内部モジュール（`child_process`, `vm`, `http` など）やサードパーティ製ライブラリが、内部でオブジェクトのプロパティ（例: `options.cwd`, `options.shell`, `options.env`）をチェックする際、未定義であればデフォルト値を使うつもりで記述されているケースがある。
もし、そのプロパティが `Object.prototype` 経由で汚染されていたらどうなるか？
// Node.jsの内部処理の擬似コード（脆弱なライブラリの挙動）
function spawnProcess(userOptions) {
// userOptions自体には ‘shell’ が指定されていなくても、
// Object.prototype.shell が汚染されていると、ここで真と評価されてしまう！
const shell = userOptions.shell || ‘/bin/sh’;
const args = userOptions.args || [];
// 任意のコマンド実行へ繋がる危険性
// require(‘child_process’).spawnSync(userOptions.command, args, { shell });
}
イベントループと非同期コンテキストへの影響
Node.jsのイベントループ（Libuv）上で動作する非同期処理や、`async_hooks` を用いたコンテキスト追跡において、グローバルな汚染やプロトタイプ汚染は、非同期リクエスト間でデータが混濁する「クロスリクエスト・ステート汚染」を引き起こす。あるユーザーのリクエストで注入された汚染プロパティが、別ユーザーの認証チェックやデータベースクエリの構築ロジックに侵食し、セキュリティ境界を完全に無効化する。
—
4. ランタイムの防壁を構築する：極限の防御策
この脆弱性とランタイムの脆弱性を断ち切るためには、JavaScriptの言語仕様とV8の挙動を踏まえた多層防御（Defense in Depth）が不可欠である。
① `Object.prototype` の凍結（Freezing）
アプリケーションの起動時（エントリポイントの最上部）で、組み込みプロトタイプを不変にする。
// アプリケーション起動の最初に実行する
Object.freeze(Object.prototype);
Object.freeze(Array.prototype);
// これ以降、プロトタイプへのプロパティ追加は TypeError をスローする
try {
Object.prototype.evil = true;
} catch (e) {
console.error(“プロトタイプ汚染の試行をブロック:”, e.message);
}
※注意: 多くの古いサードパーティライブラリが組み込みプロトタイプを拡張している場合、これによって動作不良を起こす可能性がある。そのため、モダンな環境でのコード監査が前提となる。
② 安全なオブジェクトのマージとキーの検証
動的なプロパティを受け入れる際は、`__proto__`, `constructor`, `prototype` といった危険なキーを厳格にホワイトリスト方式またはブラックリスト方式で排除する。
function safeMerge(target, source) {
for (let key of Object.keys(source)) {
// 危険なプロパティ名インジェクションを完全にシャットアウト
if (key === ‘__proto__’ || key === ‘constructor’ || key === ‘prototype’) {
continue;
}
if (source[key] !== null && typeof source[key] === ‘object’) {
if (!target[key]) target[key] = {};
safeMerge(target[key], source[key]);
} else {
target[key] = source[key];
}
}
return target;
}
③ プロトタイプレスのオブジェクト活用
そもそも継承チェーンを持たないオブジェクトを生成することで、プロトタイプ汚染の影響を物理的に遮断する。
// __proto__ を持たない完全なハッシュマップ（Dictionary）の生成
const safeDictionary = Object.create(null);
console.log(safeDictionary.__proto__); // => undefined
console.log(Object.prototype.hasOwnProperty.call(safeDictionary, ‘toString’)); // => false
`Object.create(null)` で生成されたオブジェクトは、V8の通常の隠しクラス最適化経路からは外れる場合があるが、不特定多数のユーザー入力を扱うマッピング処理（ルーティングやJSONパース結果の格納など）においては、セキュリティ上の最強の盾となる。
—
5. 結びにかえて：シニアエンジニアが持つべき「ランタイムの視点」
JavaScriptは手軽に書ける言語であるがゆえに、変数スコープやオブジェクトモデルの抽象化の裏側に隠された「メモリと実行エンジンの現実」を忘れがちになる。
グローバル変数の乱用や、不安全なオブジェクト操作は、単なる「バグ」ではなく、V8エンジンの最適化機構とメモリ構造を逆手に取られた立派なセキュリティホールである。
コードを書くとき、目の前の1行がV8のヒープ上でどう解釈され、どの隠しクラスを生成し、イベントループのどの瞬間に実行されるか――その解像度を持ち合わせたエンジニアだけが、真に堅牢で高速なシステムアーキテクチャを構築できる。