【2026/9/19 AIニュース】Claude Code・Codex・Copilotを襲う「Plugin4Shell」。Azure AI FoundryにはCVSS 10.0
AIコーディングエージェントのPluginを「特定の安全なCommitへ固定したから大丈夫」という前提を崩すSupply Chain Vulnerability「Plugin4Shell」が公開されました。Claude Code、OpenAI Codex、GitHub Copilot、Gemini CLIの4製品で同じ設計上の問題が確認されています。
MicrosoftではAzure AI FoundryにCVSS 10.0のPrivilege Escalation Vulnerabilityが修正されました。後半は、わずか74フェムト秒で光の進行方向を変えるCaltechのMetasurfaceと、Muoniumを使ってEinsteinの「自由落下の普遍性」を初めて検証しようとする最新Particle Physicsです。
🤖 AI開発セキュリティ：「Commitを固定したから安全」が崩れる
1. Plugin4Shell：Claude Code、Codex、Copilot、Gemini CLIでZero-click RCE
AI Security企業AIRが9月17日、「Plugin4Shell」と名付けたAI Coding AgentのSupply Chain Vulnerabilityを公開しました。
対象として確認されたのは、Claude Code、OpenAI Codex、GitHub Copilot、Gemini CLIです。
AI Coding Agentでは、本体機能に加えてPluginやSkillをMarketplaceから導入できます。当然、外部RepositoryのCodeをそのまま信頼するのは危険なので、Marketplace側では「レビュー済みの特定Commit SHAへ固定する」という対策が使われています。
例えば、安全性を確認したCommitが、
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
なら、そのSHAを指定してInstallする。Repository側がその後更新されても、Agentは安全確認済みのCommitだけを使う。
一見、かなり堅牢に見えます。
Plugin4Shellが悪用するのは、その「SHAを指定した」という事実と、「実際にそのSHAのCodeがCheckoutされた」という事実の間にある隙です。
Claude Code、Codex、GitHub Copilotでは、AgentがRepositoryをCloneした後、
git checkout <pinned SHA>
のような処理を行います。
問題は、GitではCommit Hashと同じ名前のBranchを作れるHosting Environmentがあることです。攻撃者がPlugin RepositoryをControlできる状態で、固定されている40桁SHAとまったく同じ名前のBranchを作り、それをDefault Branchに設定します。
すると git checkout のName Resolutionによって、Agentが意図したCommitではなく攻撃者が用意したBranchへ切り替わる場合があります。
Marketplace上では「安全なSHAに固定済み」と表示されたままです。しかし実際のWorking Treeには別のMalicious Codeが入ります。
Gemini CLIでは仕組みが少し異なります。正しいCommitを FETCH_HEAD へ取得した後に git checkout FETCH_HEAD を実行しますが、Default Branchそのものを FETCH_HEAD という名前にすることで、同様に意図したCommitとは異なるCodeをCheckoutさせる方法が確認されました。
さらに危険なのがAuto Updateです。
Claude CodeやCodexではPlugin UpdateがBackgroundで行われるため、一度安全なPluginをInstallしたユーザーに対し、Repository側を後から「Rug Pull」するだけでMalicious Versionを配布できます。
新しいPluginをInstallする必要も、確認Dialogを押す必要もありません。
これが「Zero-click」とされる理由です。
攻撃が成立すると、PluginはCoding Agentと同じ権限で実行されます。つまりSource Code、Local File、Credential、Terminal、Cloud Environmentなど、Agentが触れられるResourceへそのままAccessできる可能性があります。
ここが重要です。今回壊れたのは「怪しいPluginをInstallしない」という防御ではありません。レビュー済みCodeをCommit SHAへPinするという、むしろ正しいSecurity Practiceが想定どおり機能していませんでした。
AIRによると、Claude Codeは2.1.179、Codexは0.146.0で修正済みです。一方、調査公開時点でGitHub CopilotにはFixが提供されておらず、Gemini CLIはDeprecatedのため修正予定がないとされています。
構図として。AI Coding AgentはEditor Extensionというより、File、Shell、Git、Cloud Credentialまで操作する実行主体になりつつあります。そのPlugin DistributionもnpmやPyPIと同じSoftware Supply Chainとして考える必要があります。
「MarketplaceでReview済み」「SHA Pinning済み」だけではなく、Install後に HEAD が本当に期待したCommit Hashと一致しているかまで検証する。AI Agent時代には、その一段深いIntegrity Checkが必要になっています。
ソース：AIR「Plugin4Shell」、The Hacker News
☁️ AIクラウドセキュリティ：Azure AI FoundryにCVSS 10.0
2. CVE-2026-85889：認証不足からPrivilege Escalationへ
MicrosoftがAzure AI Foundryに存在したMaximum SeverityのSecurity Vulnerability「CVE-2026-85889」を修正しました。CVSSは10.0です。
Azure AI Foundryは、企業がGenerative AI ApplicationやAI Agentを構築、Deploy、管理するためのMicrosoftのCloud Platformです。
Microsoftの説明によると、原因は、
Missing Authentication for Critical Function
です。
認証されていないRemote AttackerがNetwork経由でPrivilegeをElevateできる可能性がありました。
ここで重要なのは、今回の脆弱性がLocal PC上のAI Modelではなく、AI AgentやApplicationを運用するCloud Control Plane側に存在した点です。
AI FoundryのようなPlatformには、Modelだけでなく、Data Source、Agent、Tool、Identity、Deployment、Cloud ResourceへのAccessが集まります。
そのためPrivilege Boundaryを突破された場合、単一のModel Response以上の影響につながる可能性があります。
ただし、今回の件で利用者がPatchをInstallする必要はありません。
MicrosoftはCloud Service側ですでにMitigationを完了しており、
Customer Action Required：なし
としています。
また、Microsoftによれば現時点で実際の攻撃に悪用された証拠も確認されていません。
同時期にはMicrosoft 365 CopilotにもCVSS 9.9のCommand Injection Vulnerability「CVE-2026-85885」が修正されています。さらにAzure Database for PostgreSQLやAzure Cosmos DBなど、Cloud / AI関連製品でも複数のPrivilege Escalationが修正されました。
ここが重要です。AI SecurityというとPrompt InjectionやJailbreakに目が向きますが、AI Platformそのものは普通のCloud Infrastructureでもあります。
Authentication、Authorization、Network Boundary、Secrets Management、Tenant Isolation。AIであっても、最終的にSecurityを支えるのは従来からある基本的なControlです。
構図として。AI Agentが強力になるほど、「Modelが何を答えるか」より「Agentが何へアクセスできるか」の重要性が上がります。今回のようにCloud Platform側のPrivilege Boundaryに問題があれば、AI Safetyだけでは守れません。
Model SecurityとCloud Securityを別々に考えるのではなく、一つのAttack Surfaceとして見る必要があります。
ソース：Microsoft Security Response Center、The Hacker News
💡 フォトニクス：74フェムト秒で光を曲げる
3. Caltech：別の光を使って光の進行方向を超高速制御
9月18日、ScienceDailyがCaltechの超高速Optical Beam Steering研究を紹介しました。
結果から書くと、
74フェムト秒。
1フェムト秒は1000兆分の1秒です。
研究チームは、1本のLight Beamを使って別のLight Beamの進行方向を変えるDeviceを開発し、74fsという極めて短いResponse Timeを実証しました。
中心となるのが、
Metasurface
です。
Metasurfaceは、光のWavelengthよりも小さなNanostructureを大量に配置した非常に薄いOptical Surfaceです。それぞれの構造で光のPhaseやAmplitudeをControlすることで、普通のLensとは異なる方法で光を操作できます。
今回のDeviceでは、Siliconを使ったHigh-Q Metasurfaceへ「Pump Beam」を照射します。
するとOptical Kerr Effectによって、照射された場所のRefractive Indexが瞬間的に変化します。
その状態で別の「Probe Beam」を通すと、Pump Beamが作った空間Patternに応じてProbe Beamの進行方向が変わります。
研究では最大約±13°のBeam Steeringを実現しています。
そして、Pump LightのPatternを書き換えればDeflection AngleもProgrammableに変更できます。
つまり機械的にMirrorを動かす必要がありません。
従来のBeam SteeringではMEMS MirrorやLiquid Crystalなどを利用しますが、Mechanical MotionやMaterial ResponseによってSpeedに限界があります。
今回使われたKerr EffectはElectronic Polarizationに由来するため非常に高速で、74fsというResponseを実現できました。
ここが重要です。これは「74フェムト秒で大量のDataを処理できるComputerが完成した」という話ではありません。74fsはMetasurfaceのOptical Response、つまり光を切り替える時間です。
それでも、Photonic ComputingやOptical Communicationでは「光をどう高速にRouteするか」が大きな課題です。
電子信号へ変換してからSwitchingするのではなく、
Light → Light
のままControlできれば、Data TransferやComputingのLatencyを大きく減らせる可能性があります。
構図として。AI Chipでは「電子で計算し、光でDataを運ぶ」Photonic Interconnectが注目されています。そこで必要になるのが、Lightを高速に曲げ、分岐し、切り替えるDeviceです。
今回の研究は、Photonic Networkにおける「超高速Switch」の基礎技術として面白い成果です。
なお、論文そのものはNature Nanotechnologyに7月掲載、Caltechの公式発表も7月7日です。9月18日にScienceDailyが再紹介した研究であり、「9月18日に初めて発表された成果」ではありません。
ソース：Caltech、Nature Nanotechnology、ScienceDaily
🌍 基礎物理学：Einsteinの「自由落下」を第二世代粒子で試す
4. Muonium：重力を測定するための「冷たい粒子Beam」の生成に成功
最後はEinsteinのGravityです。
ETH ZurichとPaul Scherrer Institute（PSI）の研究チームが、MuoniumというExotic Atomを高強度かつ狭いVelocity Distributionを持つBeamとして生成することに成功しました。論文は9月14日にNature Physicsへ掲載され、9月18日にScienceDailyでも紹介されています。
Muoniumは、
Positive Muon（μ+）＋ Electron（e−）
から構成されるHydrogenに似たAtomです。
普通のHydrogenではProtonとElectronが結合していますが、MuoniumではProtonの代わりにPositive Muonが入ります。
MuonはElectronの約207倍のMassを持つ第二世代のLeptonです。
現在のPhysicsでは、物体の種類に関係なくGravityによるAccelerationは同じになるという、
Universality of Free Fall
がEinsteinのGeneral Relativityの重要な前提になっています。
これまでこの原理はAtom、Neutron、Antihydrogenなどで非常に高いPrecisionで調べられてきました。
しかし、それらの多くは第一世代のStandard Model Particleで構成されています。
Muoniumを使えば、
第二世代Particleを含むMatterにもGravityが同じように作用するか
を初めて直接調べられる可能性があります。
問題はMuonのLifetimeです。
Muonは約2.2µsでDecayします。
そのため従来のMuonium Sourceでは、生成したAtomがさまざまな方向・Velocityへ飛び出し、Gravityによる非常に小さなDeflectionを測定する前に消えてしまいます。
研究チームはSuperfluid Heliumの薄いLayerからMuoniumを取り出すことで、高輝度かつ速度のばらつきが小さい「Superthermal Muonium Beam」を生成しました。
これによりMuonium Interferometryが現実的になり、将来的には重力加速度をPercent-levelで測定できると期待されています。
ただし、ここも重要です。
まだMuoniumが落下する様子を測定したわけではありません。
今回成功したのは、そのGravity Experimentを可能にするBeam Sourceの構築です。
研究チームは2026年中にBeamを使った初期Testを行い、Gravity Measurement本体は今後2〜3年程度で実施したいとしています。
もしMuoniumのGravity Accelerationが普通のMatterと違っていた場合、EinsteinのEquivalence Principleに対する非常に大きなChallengeになります。
そして研究者らは、そのような差が見つかれば未知の「Fifth Force」などNew Physicsを示唆する可能性もあると説明しています。
構図として。EinsteinのTheoryを破ることが目的なのではありません。
100年以上正しく機能してきたTheoryを、「まだ誰も測っていない種類のMatter」でさらに厳しくTestする。その結果が一致してもPhysicsの理解は深まり、違いが出ればさらに大きな発見になります。
Scienceは「間違いを探す」だけでなく、「どこまで正しいのかを確認する」営みでもあります。
ソース：ETH Zurich、Paul Scherrer Institute、Nature Physics、ScienceDaily
#AI #ニュース #Plugin4Shell #ClaudeCode #Codex #GitHubCopilot #AzureAIFoundry
