Apr 23, 2026

CVE-2026-5281 Chromiumベースの製品の脆弱性

CVE-2026-5281 (04/01)

『Google Dawn には、レンダリング処理を不正に操作したリモート攻撃者が、細工したHTMLページを介して任意のコードを実行できる可能性がある、Use-After-Freeの脆弱性(解放されたメモリを再使用宣言なく使用する脆弱性)があります。以上機械翻訳と手直し少々

KEV Catalog (04/01)

この脆弱性は、Google Chrome、Microsoft Edge、Opera などを含む複数のChromiumベースの製品に影響を与える可能性がある』 以上機械翻訳

「Google Chrome 146」には脆弱性の修正も ~深刻度「Critical」を含む29件に対処 - 窓の杜 (03/12)

『Windows環境ではv146.0.7680.71/72が展開中
 ・・・
深刻度の最大評価は、4段階中最高の「Critical」。』

「Microsoft Edge」にゼロデイ脆弱性、WebGPU実装「Dawn」の欠陥を突く攻撃が確認 - 窓の杜 (04/06)

『修正版のv146.0.3856.97が展開中、できるだけ早い適用を
 ・・・
 深刻度の最高評価は、4段階中上から2番目の「High」。なかでも、WebGPU実装「Dawn」で発見された解放後メモリ利用(Use after free)の脆弱性 「CVE-2026-5281」はすでに悪用が確認されており、警戒が必要だ。できるだけ早いアップデートをお勧めする。』

FortiClient EMS API認証および認証バイパス

https://fortiguard.fortinet.com/psirt/FG-IR-26-099

「FortiClient EMSの不適切なアクセス制御脆弱性[CWE-284]により、認証されていない攻撃者が不正なコードやコマンドを細工されたリクエストで実行できるようになる可能性があります。

フォーティネットはこれを実際に悪用する点を指摘しており、脆弱な顧客に対して、以下の手順に従って、FortiClient EMS 7.4.5および7.4.6のホットフィックスをインストールするよう呼びかけています。」 以上機械翻訳

Apr 21, 2026

Claude Mythos Preview

Anthropicが警鐘を鳴らすAI時代のサイバー脅威 企業が採用すべき対策とは:セキュリティニュースアラート - ITmedia エンタープライズ (04/15)

AI加速型攻撃への対抗策 組織が直面する課題と実践的な防御実装とは

パッチ適用の遅延解消(最優先事項)
  • 既知の脆弱性は公開後すぐに悪用手法が確立されるため、インターネット公開システムでは24時間以内の対応が望ましい
  • 米国の既知悪用脆弱性カタログや確率指標を活用し、適切な優先順位を付ける

脆弱性報告の急増への備え

  • 報告件数が桁違いに増えることを見込み、受付・分類・修正管理の仕組みを根本から見直す
  • オープンソース依存関係の安全性評価や、ベンダーに対しても同水準の対策を求める
  • AIを報告の重複整理、影響分析、修正チケット作成などに役立てる

出荷前の欠陥検出体制の強化

  • 静的解析、AIによるコードレビュー、継続的テストの導入によって問題の早期発見を図る
  • ビルド工程の保護や安全設計の原則を採用し、新規開発ではメモリ安全性の高い言語を利用する

既存コードの再検証

  • 長期間運用されているシステムには未発見の問題が残る可能性が高いため、AIによる再分析を実施する
  • 特に外部入力処理や認証関連など、影響の大きい箇所から優先的に調査する

侵入を前提とした設計

  • 侵入を完全に防ぐことは困難なため、ゼロトラストの採用、ハードウェア認証、短期間で失効するトークンの利用などで被害範囲を限定する

公開資産の把握と削減

  • 接続資産を正確に把握し、不要なシステムを停止して攻撃面を縮小させる
  • AIを活用して未使用コードや不要なサービスを特定し、模擬攻撃による検証を実施する

インシデント対応の迅速化

  • アラートの初期分析や記録作成をAIに任せ、人間が判断に集中できる体制を構築する
  • 複数の同時事案を想定した訓練や、検知能力の可視化を重視する

脆弱性報告の質の確保

  • AI生成の報告が増える中で、人間による検証、再現手順、修正案の提示を不可欠とし、信頼性を確保する

専門部門を持たない組織向けの対策

  • 自動更新の有効化、マネージドサービスの利用、ハードウェア認証の導入を推奨
  • コードホスティングサービスが提供する無料のセキュリティ機能を積極的に活用する
 同社は今後もパートナーとの取り組みを通じて指針を更新するとしており、AI時代における防御戦略の継続的な見直しの必要性を強調している。

Device code attacks #2

Q. 先の記事の"デバイス"と手法を紹介しているビデオはありますか?
A. デバイスコードフィッシングの攻撃手法を、実際の操作画面(デモ)を交えて解説している非常にわかりやすい動画がいくつかあります。

英語の動画が中心ですが、攻撃者がどのようなツールを使い、被害者がどのように騙されるのかという「攻撃の流れ」が視覚的に理解できるものを紹介します。

1. 攻撃と対策の全行程がわかるデモ(おすすめ)

動画タイトル:YOU NEED TO BLOCK THIS (Device Code Auth in M365)

(チャンネル:diecknet EN / 約9分)

この動画では、攻撃者側と被害者側の両方の画面を並べてデモを行っています。

  • 攻撃のデモ (01:21〜): 1. 攻撃者がコマンドラインツール(TokenTactics)を実行し、正規の「デバイスコード」と「認証URL」を取得します。

    2. 攻撃者が被害者に「システム確認のためにコードを入力してください」といった偽のメッセージを送ります。

    3. 被害者が**公式サイト(microsoft.com/devicelogin)**にアクセスし、送られてきたコードを入力します。

    4. 被害者が「続行」を押すと、攻撃者の手元にあるツールに「認証済みトークン」が届き、パスワードなしでアカウントが乗っ取られる様子が映し出されます。

  • 対策の解説 (04:37〜): * Microsoft Entra ID(旧Azure AD)の設定で、この「デバイスコードフロー」自体をブロックする方法を解説しています。

2. 「MFA(多要素認証)が効かない」ことを強調したデモ

動画タイトル:How to Stop Device Code Flow Attacks in Entra

(チャンネル:Threatscape / 約5分)

この動画のポイントは、被害者が**「物理セキュリティキー(FIDO2)」という非常に強固な認証を使っているにもかかわらず、攻撃が成功してしまう**ことを実演している点です。

  • 見どころ (02:01〜): 被害者が指紋認証や物理キーで「正しくログイン」したその瞬間に、攻撃者がトークンを奪取してメールやファイルにアクセスできるようになる流れが非常にスピーディーに示されています。


動画で示されている共通の「攻撃の流れ」まとめ

これらのデモ動画を見ると、以下の3ステップがこの攻撃の核心であることがわかります。

  1. 「本物のサイト」へ誘導する: 偽サイトではなく、MicrosoftやGoogleの本物のログインページにコードを入力させるため、被害者は警戒心を解いてしまいます。

  2. ログイン後の「権限」を奪う: ユーザーがログインを完了すると、その「ログイン済みの状態(トークン)」が攻撃者のマシンに転送されます。

  3. パスワード・MFAをバイパス: ユーザーが自分でMFAを突破して「許可」ボタンを押してしまうため、どれほど強固な認証を設定していても防げません。

より専門的・技術的な詳細に興味がある場合は、2025年のハッカーカンファレンスでの講演**「DEFCON33 - Turning Microsoft's Login Page into our Phishing Infrastructure」**も、この手法がどのように悪用されているかを深く掘り下げており、非常に参考になります。

Device code phishing attacks have skyrocketed: here’s what you need to know

https://pushsecurity.com/blog/device-code-phishing/ (04/04)


いつものセキュリティホールmemoさんの記事で気になったので、後で読むためのメモ。

◆悪用成立シナリオをAIに訊いてみた◆

RFC 8628で定義されている OAuth 2.0 Device Authorization Grant(デバイスフロー) において、攻撃者がターゲットのアカウントを乗っ取る操作手順を簡潔にまとめます。
この攻撃の核心は、「正規のログイン手順の中に、攻撃者のデバイスを紛れ込ませる」 ことにあります。

悪用の操作手順

  1. 攻撃者によるコード取得
    攻撃者は自分のデバイスから認証サーバーへリクエストを送り、**ユーザーコード(例: ABC-123)**を取得します。
  2. 被害者へのフィッシング(誘導)
    攻撃者は「セキュリティ確認のため」や「特典の受け取り」などの口実を使い、被害者に以下の2点を伝えます。
    • 正規の認証用URL(例: google.com/device)にアクセスすること
    • 攻撃者が取得したユーザーコードを入力すること
  3. 被害者による承認
    被害者は、URL自体が本物であるため安心してアクセスし、指示されたコードを入力します。その後、自分のID/パスワードでログインし、「デバイス(実際は攻撃者のもの)のアクセスを許可しますか?」という画面で「はい」を押してしまいます。
  4. 攻撃者によるトークン奪取
    被害者が承認した瞬間、攻撃者のデバイスがポーリング(待機)していた認証サーバーからアクセストークンが発行されます。これにより、攻撃者は被害者のパスワードを知ることなく、アカウントへアクセス可能になります。

なぜこれが成り立つのか?

このフローでは、**「コードを入力している人間(被害者)」「実際にログインしようとしているデバイス(攻撃者)」**が同一人物であることを確認する仕組みが欠けているため、このような「コードのすり替え」が成立してしまいます。
ポイント:
攻撃の成功には、被害者に「偽のサイト」ではなく、**「本物のサイトに、攻撃者のコードを入力させる」**というソーシャルエンジニアリング(騙しのテクニック)が不可欠です。
なお、各種アプリのすべての機能を使用するには、Gemini アプリ アクティビティを有効にする必要があります。

シャドーAIによる誤認逮捕

AI顔認識による誤認逮捕で5カ月勾留、行ったこともない州の事件の「容疑者」に 米(1/2) - CNN.co.jp (03/30)

『「ウェストファーゴの関係機関は、我々の上層部が認識していない独自のAI顔認識システムを調達した。我々はその使用を認めておらず、その後使用を禁止した」とファーゴ警察のデイブ・ジボルスキー署長は話している。
 ・・・
ファーゴでは弁護士が選任され、犯行時刻にリップスさんがテネシー州にいたことを証明する銀行記録が見つかった。ファーゴ警察によると、州検察は12月12日、「無実を証明し得る証拠」が弁護士から提出されたとファーゴ警察に通知した。』

弁護士が証拠を提出できていなければ、有罪確定だったのか? 案外司法が未成熟!?

Apr 16, 2026

Progress ShareFile にリモートコード実行可能な脆弱性

『Progress ShareFile チームは最近、お客様が管理するゾーンの ShareFile Storage Zones Controller v5 バージョンのデプロイメントに重大なセキュリティ脆弱性があることを確認しました。現在のところ、これらの脆弱性が悪用されたという報告は受けておりません。

これらの脆弱性は、認証されていないリモートの攻撃者がオンプレミスのストレージゾーンコントローラーの設定ページにアクセスすることを可能にし、システム設定の変更やリモートコードの実行につながる可能性があります。』 以上機械翻訳

『私たちは Progress ShareFile のフィンガープリントをスキャンとレポートに追加し、2026-04-02 に公開された 784 のユニーク IP を確認しました。最近、@watchtowrcyber が ShareFile に影響を及ぼす RCE CVE-2026-2699 & CVE-2026-2701 悪用チェーンの詳細を公開しました。最新のパッチを必ず適用してください! pic.twitter.com/aVvl83pzt4
- Shadowserver Foundation (@Shadowserver) April 3, 2026 』

April 3, 2026 nekono_nanomotoni (@nekono_naha)
Progress社ShareFileで認証前RCEに繋がる脆弱性の詳細PoCが公開されたため公開サーバを調査。グローバルで642台を発見し内18.1%の116台が脆弱性の影響を受ける可能性あり。同社製品は様々なものが過去何度も悪用されており今回も遅かれ早かれITWになると予想。日系へ影響小https://t.co/wUTDlr8teR pic.twitter.com/AzI6i2FkXW

『Customer Managed ShareFile Storage Zones Controller (SZC) allows an unauthenticated attacker to access restricted configuration pages. This leads to changing system configuration and potential remote code execution.
 ・・・
CNA:  Progress Software Corporation
Base Score: 

『Authenticated user can upload a malicious file to the server and execute it, which leads to remote code execution.
 ・・・
CNA:  Progress Software Corporation
Base Score: 

AIX、住信SBIネット銀行 .. 東京海上との比較

◆住信SBIのAIX◆

住信SBIネット銀行が2025年に発表し、2026年現在まさに進行させている取り組みは、単なる「システムのクラウド化」を超えた、銀行業におけるAIXの極致も言えるものです。
彼らが掲げているのは、銀行そのものをAI化する**「NEOBANK ai」**という構想です。
1. 国内初「ジェネレーティブUI」の実装(2026年2月〜)
住信SBIネット銀行がAIXとして特筆すべきなのは、**「ジェネレーティブUI(画面の自動生成)」**という概念をアプリに持ち込んだことです。
  • 従来のDX: 人間が使いやすいようにボタンを配置した「固定の画面」を作る。
  • 住信SBIのAIX: AIとの対話に応じて、その瞬間に必要な「振込画面」や「グラフ」をAIがその場で組み立てて提示する。
    • 例えば、「先月のデビットの使いすぎを分析して、残金から来月の家賃を引いた額を貯金用口座に移して」と話しかければ、AIが分析グラフを生成し、最適な振込実行ボタンをその場で作り出します。
2. 「銀行員」そのもののエージェント化
東京海上が「損害査定」をAI化したように、住信SBIは**「コンシェルジュ業務」**をAIエージェントに置き換えています。
  • NEOBANK ai エージェント: 2026年2月からベータテストが開始されているこの機能は、単なるチャットボットではなく、**「銀行の操作権限を持ったAI部下」**です。
  • 何ができるか: 自然言語(話し言葉)だけで、振込、残高確認、デビットの利用制限設定、さらには「割り勘したお金が全員から振り込まれたかの確認」といった、これまで人間が手作業で画面をポチポチ操作していたことをすべてAIが肩代わりします。
3. クラウド移行は「AIX」のための「土台作り」
ご指摘の「勘定系システムのクラウド移行(AWSへの完全移行)」は、実はこのAIXを実現するための必須条件でした。
  • 理由: 従来の銀行の古いシステム(オンプレミス)は、AIがアクセスするには「重すぎて」「固すぎる」のです。
  • AIXとの関係: 全システムをクラウド(AWS)に載せることで、AIが銀行の深部のデータ(勘定系データ)にミリ秒単位でアクセスし、即座に処理を実行できる**「AIファーストな銀行」**へと肉体を改造したわけです。

東京海上(損保)と住信SBI(銀行)のAIX比較
特徴
東京海上(8766)
住信SBIネット銀行(7163)
主なAIX対象
事故査定・支払いの自動化
銀行操作・UIの自動生成
ユーザー体験
「事故対応の待ち時間がゼロになる」
「銀行アプリの操作そのものがなくなる」
戦略の肝
膨大な過去の損害データとAIの結合
クラウド基盤(BaaS)と生成AIの融合
結論
住信SBIの取り組みは、「銀行を『アプリ』から『見えないエージェント』へ変えること」を目指しています。「勘定系システムのクラウド化」は、例えるなら「AIという強力な脳」を動かすために、全身の神経(システム)を光ファイバーに差し替える手術のようなもので、これによって初めてAIが銀行業務を「独走」できる準備が整ったと言えます。
金融業界では、この両社が「AIXによって既存の金融機関をどれだけ突き放すか」が2026年現在の最大の関心事となっています。

◆住信SBI、東京海上のAIXと競争優位性◆

東京海上ホールディングスが「リスク評価の精度(=保険商品の原価低減)」で差をつけるのに対し、**住信SBIネット銀行がAIXで狙う競争優位は、「銀行という存在の消滅(インビジブル・バンキング)」と「圧倒的な低コスト構造」**にあります。
一言で言えば、東京海上のAIXは**「中身(評価)」の進化、住信SBIのAIXは「器(インフラ)」**の進化といえます。具体的には以下の3点が競争優位の源泉です。
1. 「BaaS(ネオバンク)」のプラットフォーム支配力
住信SBIの最大の武器は、自社の銀行機能を他社(JAL、ヤマダ電機、高島屋等)に貸し出す**BaaS(Banking as a Service)**です。
  • AIXの役割: 提携先が増えるほど、本来は審査やサポートのコストが膨れ上がります。しかし、AIエージェントがこれらを自律的に処理することで、**「提携先が100社に増えても、銀行側の行員数は増やさない」**という究極のスケーラビリティ(拡張性)を実現します。
  • 競争優位: 提携先企業にとっては「最も低コストで、最も賢い銀行機能を自社アプリに組み込める」ため、住信SBIがプラットフォーマーとして独走状態になります。
2. 「AI審査」による高収益・低リスクの両立
東京海上のリスク評価に近い部分ですが、銀行においては「住宅ローン」などの融資審査がこれに当たります。
  • AIXの役割: 2026年現在、同行は膨大なデータを活用した**「AIスコアリング審査」**を極めています。通常、数日〜数週間かかる住宅ローン審査を最短当日に短縮しつつ、人間が見逃すような微細な不正・デフォルトの兆候をAIが検知します。
  • 競争優位: **「爆速で借りられるのに、貸し倒れが極めて少ない」**という状態を作ることで、他行が追随できない低金利(または高利回り)を提供し、優良顧客を総取りします。
3. 「限界費用のゼロ化」によるROEの極大化
銀行業は本来、店舗や大量の事務員を抱える「重い」ビジネスです。
  • AIXの役割: 勘定系システムのクラウド移行とAIエージェントの導入により、預金残高や口座数が増えても、システム維持費や人件費がほとんど増えない**「限界費用がほぼゼロ」**の収益構造へ移行しています。
  • 競争優位: 2026年度に掲げているROE 18%以上という目標は、一般的な銀行(5〜8%程度)を圧倒しています。この高収益を原資に、さらなるシステム投資や還元を行う「勝利のループ」に入っています。

比較まとめ:両社のAIXが目指す「決定的な差」
視点
東京海上 (8766)
住信SBIネット銀行 (7163)
競争優位の本質
**「損をしない」**力の最大化

(精緻なプライシング)
**「コストをかけない」**力の最大化

(徹底した無人化・インフラ化)
狙うポジション
リスクマネジメントの世界的権威
金融機能の黒子(OS)
顧客のメリット
事故が起きる前に防げる、安い保険
銀行を意識せず、勝手にお金が管理される
住信SBIの怖さは、彼らが「銀行」として戦っているのではなく、**「銀行の機能を持ったITプラットフォーム」**として、他の銀行を「部品」に変えてしまおうとしている点にあります。東京海上が「最強の保険屋」を目指すなら、住信SBIは「銀行の概念そのものを消す」ことで勝とうとしている、という違いがあります。

AIX、東京海上

◆AIXとは◆

「ブラウザでChatGPTに質問する」のと、東京海上のような企業が「AIエージェントを基盤に組み込む」のとでは、**「AIが単なる相談相手(チャット)か、それとも実務を実行する部下(エージェント)か」**という決定的な違いがあります。
具体的にどう違うのか、3つのポイントで解説します。

1. 「答える」だけでなく「動く」
ブラウザ版のAIは、私たちが入力したテキストに対して「回答」を生成するまでが仕事です。
一方、AIエージェントは、回答の先にある**「社内システムの操作」**を行います。
  • ブラウザ版: 「この契約内容だと保険金はいくら?」と聞くと、規約を読み取って「10万円です」と教えてくれる
  • AIエージェント: 「この事故の保険金を支払っておいて」と頼むと、AIが自ら社内の顧客データベースを確認し、支払い可否を判断し、送金システムを操作して振り込み手続きまで完了させる
2. 社内の「秘匿データ」とシームレスに繋がっている
ブラウザのAI(ChatGPTなど)は、一般的に公開されている知識には強いですが、あなたの会社の「Aさんの保険契約の詳細」や「過去30年の事故対応ノウハウ」は知りません。
  • 基盤への組み込み: 東京海上の持つ膨大な過去の事故データ、判例、顧客情報を、セキュアな環境でAIに直接学習(あるいは参照)させています。
  • 効果: 「過去の似たような事故では、過失割合はどう判断されたか?」といった、その会社にしかできない高度な判断をAIが瞬時に行えるようになります。
3. 自律的な「判断と連携」
これが最大の特徴です。AIエージェントは、一つの指示に対して「自分で手順を考えて」動きます。
例:大規模災害が発生した際
  1. AIが自ら判断: 気象データから被害地域を特定。
  2. AIが調査: その地域の契約者リストを抽出。
  3. AIが実行: 契約者に「被害はありませんか?」と自動で連絡。
  4. AIが処理: 返信があった写真(家の損壊など)を画像解析して損害額を算出し、査定に回す。
このように、人間がいちいち「次はこれをやって」と指示しなくても、一連の業務プロセスをAIが自律的に完結させのが「業務基盤への組み込み」の正体です。

なぜ東京海上がこれを急ぐのか?
損害保険の業務は「膨大な書類」と「複雑な約款(ルール)」、そして「個別の状況判断」の塊です。
これらをAIエージェントに任せることで、**「支払いまでのスピードを劇的に早める(顧客満足度)」事務コストを圧倒的に下げる(利益率)」**を同時に達成しようとしています。
投資家の目線では、これは単なる「IT化」ではなく、**「保険業というビジネスモデルそのものの装置産業化(自動化)」**に見えているため、非常に大きなインパクトとして受け止められています。

◆東京海上のAIX、統制設計◆

強力な「AIエージェント」が自律的に動くほど、人間の制御を離れる**「独走リスク」や、判断プロセスが不透明になる「ブラックボックス問題」**は、金融機関にとって最大の懸念事項です。
東京海上は2026年現在、このリスクに対して「AIを信じる」のではなく**「AIを疑い、監視し続けるシステム」**を多層的に組み込んでいます。具体的には以下の3つの統制設計が柱となっています。

1. 「金融界初」の外部AIガバナンスツールの導入
2026年3月、東京海上は**Citadel AI(シタデル エーアイ)などの高度なAIガバナンスツールを本格導入しました。これはAIの「外側」に設置する、いわばAI専用の監査カメラ」**です。
  • 自動モニタリング: AIエージェントが「いつ、なぜ、その判断をしたか」をリアルタイムで監視します。
  • 異常検知: 過去のデータから大きく外れた判断(例:不自然に高額な保険金査定)をAIがしようとした瞬間、強制的にブレーキをかけ、人間の承認に回す仕組みです。
2. XAI(説明可能なAI)の実装
「AIがなぜそう判断したのかわからない」という状態を避けるため、**XAI(Explainable AI)**技術を組み込んでいます。
  • 根拠の可視化: 保険金の支払い可否をAIが判定する際、必ず「どの規約のどの文言に基づき、どの証拠写真から判断したか」という根拠レポートを自動生成します。
  • 人間による検証: 最終的な高額決済や異議申し立てがあった場合、人間がこのレポートを読んで「AIのロジックが妥当か」を即座に検証できる体制になっています。
3. 「AIセーフティ」に特化した組織と外部連携
単なるIT部門ではなく、法務・コンプライアンス・リスク管理を統合した**「AIガバナンス体制」**を構築しています。
  • R-Mapによる評価: 独自のリスクマップを用いて、AIが及ぼす影響を「安全性」「倫理」「法規制」の観点から常にスコアリングしています。
  • 第3者機関との連携: 2026年には「AI Security Conference」など、外部のセキュリティ企業(DeNA等)や研究機関と連携し、自社のAIが「独走」しないための客観的な基準(AIセーフティ)の策定にも関与しています。

まとめ:統制の設計思想
東京海上のAIXにおける統制は、以下の**「ヒューマン・イン・ザ・ループ(Human in the loop)」**という考え方が徹底されています。
「作業はAIが100%行うが、責任と最終判断の主導権は、常に『AIの動作を検証可能な状態にした人間』が持つ」
投資家にとっても、この「攻めのAI活用」と「守りのガバナンス(統制)」のセットが、同社の信頼性を支える重要なファクターになっています。
この統制設計があるからこそ、彼らは「独走」を恐れずにアクセルを踏めている、とも言えるかもしれませんね。