HN 日本語サマリー

← 一覧へ戻る
セキュリティ

これが新しいサイバーの常態か？

Is this the new cyber normal? (drew.silcock.dev)

168 pointsby drewsberry202 コメント

要約

最近、深刻なソフトウェア脆弱性が多数発見され、サイバーセキュリティ界に激震が走っています。特にPHP2Shellの脆弱性はインターネットの70%に影響するとされ、AI（LLM）が脆弱性の発見とエクスプロイト作成を加速させている現状が浮き彫りになりました。この記事では、PHP2Shell、eMudhra、GitLab、LiteLLMなど、相次ぐセキュリティインシデントを分析し、AI時代におけるサイバーセキュリティの新たな常態と、それに対する我々の取るべき対策について考察しています。

全文翻訳

これが新しいサイバーの常態か？

先週は、数千もの主要なサイトに影響を与える深刻かつ重大なソフトウェア脆弱性が次々と発見され、人々をパニックに陥れました。一体何が起きているのか、そして我々は何ができるのでしょうか？

バグ

現在のソフトウェアセキュリティの世界で何が起きているのかを理解するには、これらのバグがどのように発生しているのかを理解する必要があります。私はサイバーセキュリティの専門家ではないため、ここでは技術的な詳細には深入りせず、外部の説明へのリンクを貼ることにします。これらの専門家の方が、より的確な説明をしてくれるはずです。

PHP2Shell – CVE-2026-109618 および CVE-2026-109619（別名「ニュースで話題の大きなやつ」）

カリフォルニアのセキュリティ企業Calif（OpenAIの「Patch the Planet」プログラムの一環）と、イスラエル・米国に拠点を置くクラウドセキュリティ企業Wiz（Google Cloudの一部らしい）の2つの異なるセキュリティチームが、PHPにおける2つのリモートコード実行（RCE）バグを発見しました。両チームとも、最先端のAIモデル（別名LLM、具体的にはGPT-5.6 Sol/Gemini 4 Argon）を使用してこれらの脆弱性を発見し、エクスプロイトを構築しました。

興味深いことに、バグの一つ（CVE-2026-109618）は、PHP Foundationが2024年に実施したセキュリティ監査で発見されていましたが（現在オープンソース分野で最も興味深い動きの一つであるSovereign Tech Agencyが資金提供）、より大きな懸念事項があり、修正方法について合意できなかったため、基本的に無視されていました。その理由として、理論的な問題に基づいて実際の悪用をどのように作成できるのか、誰も本当によく理解できなかったことが挙げられます。

LLMが得意とすることの一つは、たとえそれが曖昧な説明であったとしても、理論的なセキュリティ脆弱性を捉え、それを完全なエクスプロイトに構築することです。これは最近数ヶ月で大きな問題となっています。セキュリティパッチの通知があると、すぐに人々はLLMをコードベースに向け、エージェントは差分を非常に速く読み取り、セキュリティパッチのように見えるものを見つけると、それをカバーする脆弱性まで遡り、エクスプロイトに至るまで追跡します。

実際、これは非常に速く起こるため、現時点では、セキュリティパッチを発表した瞬間が、完全なエクスプロイトが公的または私的に配布されていない最後の可能な日付であると考えるのが妥当だと思います。

このPHP2Shell（マーケティングされているように、脆弱性には独自のマーケティング部門が付属するようになったようです）は、インターネットの70%以上に影響すると推定されており、Wikimedia FoundationからDeviantArt、英国政府や日本の銀行システムの多く、そしてThe Traitors BBC番組のウェブサイトまで、数千のウェブサイトに影響を与えています。脆弱性は発見されますが、通常、インターネットの半分がサーバーをシャットダウンする原因にはなりません。一体何が起きているのでしょうか？

これを理解するために、PHP Groupの元の投稿を見てみましょう。

［画像: PHPアナウンスメント「Upcoming Critical PHP Security Release」のスクリーンショット、2026年10月21日付け。リリースはUTC 10月21日水曜日14:00に予定されており、CVSS v4.0 9.2と評価された2つのクリティカルな脆弱性を修正し、リリース時に詳細が公開されると記載されています。］

petecooperという人物がHacker NewsにCVEについて投稿しましたが、エンバーゴが存在することに気づいていなかったようです。これが（そして他の明らかなリーク）PHP Groupによるこの急な声明と、パッチの提供日を木曜日22日から水曜日21日に前倒しさせた原因となりました。しかし、パッチは翌日まで利用可能になりませんでした。この意図しないリークには、CVSSスコア10.0（つまりひどい、奇妙なことに実際のスコアは9.2でしたが）が含まれていました。

ほぼ即座に、このニュースは野火のように広がり、人々はパニックに陥り始めました。「責任あるセキュリティ研究者」や「評判の良い企業」によって発見されたにもかかわらず、セキュリティパッチが実際にリリースされる頃には、すでに実世界で悪用されていました[1]。PHP Foundationは、Califがエクスプロイトの実行中のビデオ（奇妙なバックグラウンドミュージックと踊るアニメ少女付き）をリークし、Chainguardがエンバーゴ解除予定時刻の6時間前に修正を公開したと述べ、両方とも攻撃者がシステム管理者に先んじることを許したと非難しました。タイムラインは混乱していますが、ここでは約17時間のうちに複数の相互に関連した問題が発生したようです。

AIがコンピューターセキュリティを完全に変革するゲームチェンジャーなのかどうかについて、多くの議論がありました。大手AI企業（そして彼らは大きい）は、それがそうであることをあなたに信じさせたいと思っています。一部の人々は、LLMは脆弱性に対して過度に警戒し、「エクスプロイト」を作成する際に誤った仮定（既存のファイルインクルージョン脆弱性を介してアップロードしたPHPコードをサーバーが実行するというもの）をしたり、何らかの方法で不正を働いたりする傾向があるため、PHP2Shellは誇張されていると主張しています。LiveOverflowが指摘するように、LLMは何も証明せず機能しないエクスプロイトのスロップを簡単に作成できますが、それは脆弱性が実際には存在せず、AIを使用して簡単に悪用できるという意味ではありません。機能しないスロップエクスプロイトが10,000個あっても、機能するものが1つあれば、それがすべてです。おそらく、重要なものを見つけるためにスロップをかき分けることに慣れる必要があるだけでしょう。

他の人々は、多くの政府（英国2、EU、日本、米国）が興奮しすぎて、全員が直ちにコンピューターの電源を切る必要があるという緊急発表を行い、人々がパニックになったと指摘しています。人々がパニックになった理由は、PHPが非常に不安定であることを皆がなんとなく知っており、それでも使用しているため、悪いニュースに備えやすく、過剰に反応しやすいのだと思います。また、実際にはかなり悪いので、パニックになることが正しい反応なのかもしれません。

ここから得られる大きな教訓は、LLMのせいで、「このプロジェクトに重大なRCEがあるという話を聞いた」から「この脆弱性を標的とした洗練された、自動化された、協調的な攻撃がエクスプロイトを使用して行われている」までの時間が、数週間/数ヶ月から数時間/数分に短縮されたということです。機能しないエクスプロイトのスロップがたくさんあるという事実は、これらのものを実際に作成するには依然として専門知識が必要であることを示しています。もしあなたが何を見ているのかを知らなければ、AIが不正を働いたのか、あるいは誤った仮定をしたのかを判断できません。

リンク:

eMudhra (CVE-2026-111943 for Golang response)

全く同じ日（2026年10月20日）に、Mozillaはインドの認証局eMudhraが発行した8つの中間証明書をブロックしたと発表しました。これは、「Wayne」という匿名のセキュリティ研究者が、Mozilla、Apple、Google、Microsoftなどの大手テクノロジー企業に、その認証局が中間証明書に信じられないほど質の低い秘密鍵を使用していると報告した後、発生しました。安全な鍵が100桁の数字であるのに対し、eMudhraは「115」、「56」、「4」のような鍵を使用していました。彼らはRFC 1149.5に従っていたに違いありません。

［画像: xkcdコミック「Random Number」：int getRandomNumber()という関数があり、コメントに「公平なサイコロの目で選ばれました。ランダムであることが保証されています。」と書かれたコードリストが「4」を返します。］

代替: RFC 1149.5では、4を標準的なIEEE公認の乱数として指定しています。 xkcd #221より、CC BY-NC 2.5ライセンス。

これがAIやLLMによって発見または悪用された兆候はありませんが、研究者のScott Helmeは、単一のプロンプトでClaudeが中間証明書の秘密鍵を回復できたと指摘しています。

執筆時点（10月23日）で、eMudhraは、証明書発行事業者分野から撤退すると発表しました。無関係なニュースとして、農家が馬が逃げたという報告を受けて、厩舎のドアを閉めたと発表しました。

リンク:

Railwayバグ

翌日、クラウドプロバイダーのRailwayは、ハッカーがプラットフォームから環境変数（多くの場合、データベース認証情報やAPIキーなどの機密情報を保持している）にアクセスし、復号化していた証拠を発見したと発表しました。彼らの声明によると、これはAI推論を提供する企業を侵害することを目的とした協調的な取り組みの一部であると考えているとのことです。

ここでの最終的な目的は何でしょうか？執筆時点（10月23日）では、手がかりは非常に少ないです。この「不正な第三者」（「誰かが私たちのコンピューターに侵入した」という公式発表は、常に利用規約に違反しているかのように見せる方法を見つけますが、おそらく人々がそれに注意を払わないようにするためでしょう）は、AI推論を使用している人々が何をしているのかをスパイしようとしているのでしょうか、それとも新しいモデルや研究を盗もうとしているのでしょうか？あるいは、彼ら自身の悪意のある生成AI目的（PHPバグの発見など）のために、侵害された推論プロバイダーのネットワークを構築しようとしているのでしょうか？

リンク:

GitLab (CVE-2026-97229 および CVE-2026-110264)

2026年10月12日、GitLabは、GitLab CI/CDの正規表現解析における最大深刻度のバグについて警告しました。これは、特別に細工された正規表現を使用して、攻撃者が任意のコードを実行できる（別のRCE）可能性がありました。これはCVSSスコア10.0であり、最大値です。これは「ほぼ最悪の部類」を意味します[3]。これに続き、2026年10月21日には、別の正規表現整数オーバーフローRCE（これも10.0）が発表されました[4]。

これらは、先月発表された別の10.0 CVSS CVE（CVE-2026-85706）、今回はパス・トラバーサルに関連するものに続いています。これら3つのバグすべてが、GitLabのHackerOneバグバウンティプログラムを通じて報告されました。LLMが脆弱性を調査し、エクスプロイトを作成できることが明らかになったとき、バグバウンティプログラムはもはや意味をなさなくなったため、シャットダウンすべきだという多くの議論がありました。今、GitLabがそれをしなかったことを喜んでいることは確かでしょう。

GitLabは学術界、政府、民間企業で広く使用されていますが、これらはそれほど注目を集めていないようです。GitLabのCVEは明らかに非常に深刻です。特に民間企業にとっては、多くの非常に重要な知的財産がそこに保存されており、それが漏洩すると壊滅的な結果を招く可能性があります。多くの場合、企業はGitLabインスタンスをVPN/ファイアウォールで保護しているため、公開アクセスできません。これにより、関連するリスクが大幅に軽減されます。また、これらのCVEが公開プロジェクト、ユーザーによる自己登録などの特定の条件を必要とするかどうかは完全には明らかではありません。CVE-2026-110264は少なくとも1つの公開プロジェクトを必要とするようですが、以前のCVEに関する条件については情報が見つかりません。

これらがAIやLLMを使用して発見されたという兆候はありません。そうだったかもしれませんが、現時点ではそう考える理由はありません。

リンク:

musl libcバグ

10月21日、muslのlibcにおける正規表現（libcに正規表現があるとは知りませんでした…）に関連するバグが発表され、少なくともサービス拒否、あるいはコード実行につながる可能性があります。私の知る限り、これはタイミング的に完全に偶然であり、GitLabのバグとは関係ありません。どちらも信頼されていない正規表現を解析する際の整数オーバーフローに関連しており、一方は全く同じ日に報告されました。正規表現エンジンがこれほどセキュリティ上の問題になるとは誰が予想したでしょうか – 正規表現は新しいフォントレンダリングなのでしょうか？ GitLabのバグは両方ともJohan Carlsson (joaxcar)というスウェーデン人によって発見されましたが、muslのバグはフランスの自称「オープンソーサラー」であるJulien Voisinによって報告されました。

リンク:

LiteLLM

ああ、私の古い友人LiteLLMよ。金属製で200フィート（約60メートル）の高さがあれば、稲妻が二度同じ場所に落ちる可能性があることを証明しています。2026年のLiteLLMの大規模侵害について聞いたことがあるかと尋ねられたときに、「どちらの件？」と聞き返さなければならないのは良い兆候ではありません。幸いなことに、PHP2Shellや他のすべての件が多くの注目を集めてしまったため、3月の前回と同様にひどいにもかかわらず、今回はそれほど大きな注目を集めていません。

今回は、Python Package Index（PyPI）とDockerイメージ上の悪意のあるバージョンです。覚えている方のために言っておくと、LiteLLMは3月に非常に似たことが起こりました。悪意のあるパッケージがPyPIのlitellmパッケージにアップロードされ、.pthファイルを使用して悪意のあるコードを自動ロードしました（ええ、それはひどいものでした）。

今回の侵害も同様に.pthファイルを利用し、さらにsitecustomize.pyファイルを使用して悪意のあるペイロードを自動ロードし、Pythonインタープリタが起動するとすぐにプリロードステップで実行されました。Wizの分析によると、ペイロードには「LLM支援開発の強い兆候」が見られます。例えば、過度に冗長な変数名、過度に防御的なエラー処理、壊れやすいエッジケース、そして「ここが本当に肝心なところだ」「じっくり考える価値がある」「それを活かせ」「それは君のものだ」といったコメントが繰り返し[4]書かれています。

LiteLLMによると、この事件は、攻撃者がGitHub CLIの認証情報にアクセスできたために発生し、それによってCIジョブを実行することができたとのことです。LiteLLMは、Claude CodeがユーザーのGitHub CLI OAuthトークンをレスポンスボディに埋め込むことがあり、それがLiteLLMのログに表示される可能性があると指摘しています。

リンク:

PingCAP

2026年10月19日、「TiDB」というデータベースを開発するエンタープライズソフトウェア企業「PingCAP」は、「PingCAPへの不正アクセス」を明らかにし、「TiDBに保存されたデータが影響を受けた証拠はない」と発表しました。同時に、「FulcrumSec」（別名「Threatspians」[5]）というサイバー恐喝グループは、PingCAPから10.6TBのデータを流出させ、200GBのデータを「ステージ1リリース」として公開したと述べました（続編に人々を投資させる必要があります）。

彼らはまた、取得したデータの詳細と、PingCAPの優れたセキュリティ慣行の一部（クライアントのAWSシークレットアクセスキーをJiraチケットに入れることや、OpenAI、Anthropic、Gemini、xAIのAPIキーを含む、大規模な未編集ログをJiraチケットに添付することなど）を投稿しました。ひどい話です。もしサイバー恐喝グループのウェブサイトを訪れる気があるなら、彼らはそれについて非常に興味深い記事を書いています。LLMなしでロシア人がこれらを書かなければならなかった頃の、ひどい壊れた英語の時代は終わりました。彼らはLLMに助けられ、定冠詞と不定冠詞を思い出させてもらう必要がなくなりました[6]。

PingCAPにとって良いニュースは、データ抽出の証拠が見つからないことは実際には信じられないほど簡単だということです。実際、私は今、何千もの企業のために、無料でそれを行っています。そこにはきっとビジネスの提案があるはずです。ただ見ないようにすればいいのです（参照: U+1F648）。公平に言えば、彼らの主張は、TiDBインスタンス内のデータは侵害されていないということだと思います。もしそうなら、10.6TBは大量のデータです。明らかに、まだ顧客データは大量に残っています。

リンク:

Linuxの脆弱性が誤って間違ったグループチャットに投稿される

Linuxカーネル開発はすべてメーリングリストを通じて行われます。当然、その中にはセキュリティに敏感なものもあり、それらはプライベートです。2026年10月21日から22日の夜にかけて、トレンドマイクロが所有するソフトウェア脆弱性イニシアチブであるZero Day Initiative（ZDI）は、プライベートメーリングリストではなく、パブリックメーリングリストに多数の高深刻度（CVSS 9.0以上）のCVEを報告しました。当然、LLMと夢に満ちた心を持つ人なら誰でも、それらのレポートを入手し、数分以内にアクティブなエクスプロイトに変換できると想定されます。これは、Pete Hegsethがヨルダンでの軍事攻撃の計画の詳細をThe Atlanticに誤ってテキスト送信した[7]ほどひどいものではありませんが、人々がこれを今どれほど真剣に受け止めているかは興味深いです。

リンク:

これが新しい常態か？

これらのサイバーインシデントとセキュリティ開示に関して、ここ数日間は異常に活発だったと言っても過言ではないでしょう。これらのインシデントに関するHacker Newsの議論では、これが何も特別なことではなく、これからさらに悪化するだけだと述べるコメンターが多くいます。正直なところ、まだ決めていません。率直に言って、4年前にLLMがどこまで進むか尋ねられたら、今のようになるとは決して予想できませんでした。それでも、人々はこれらの発表に過剰に興奮し、ソフトウェアが安全ではなくなり、誰もが脆弱になる世界に住むことになるだろうと示唆する傾向があります。

このオンラインでの議論の多くがAIとLLMに焦点を当てていることは注目に値しますが、これらの開示のほんの一部だけがLLMで調査または作成されたものです。PingCAPのもののような一部については不明ですが、多くの犯罪組織や国家支援グループがAIを使用してハッキングを増やし、より速く行っているという明確な証拠があります。なぜそうしないのでしょうか？それは非常に得意なようです。これらの脆弱性の多くは、昔ながらのソフトウェアの脆弱性であり、人間の指で発見・記述されたものですが、オンラインでの会話は、エキサイティングで恐ろしい新しいものに焦点を当てています。なぜそうしないのでしょうか？

NHS Englandのような組織がすべてのオープンソースコードをプライベートにした（それが愚かな決定であったにもかかわらず）理由がわかります。これらのLLMが非常に優れており、誰でもエージェントをオープンソースコードに向け、数多くの脆弱性を発見し、それらのための完全なエクスプロイトを作成できるとすれば、それは多くの人にとって懸念事項です。では、ここでの解決策は何でしょうか？

我々は何ができるのか？

NHSのアプローチ：すべてをクローズドソースにする。（別名マダガスカルアプローチ）

長所:

  • コードがオンラインにないため、人々はLLMをそれに向け、セキュリティ修正のためにすべてのコミットを分析したり、数多くの以前は未知の重大なバグを発見したりすることができません。

短所:

  • オープンソースコミュニティとコンピューティングの未来は、オフラインになったオープンソースリポジトリごとに少しずつ悪化します。
  • 世界中のすべてのコードベースをクローズドソースにすることはできません。プログラミング言語（しばしば重大なバグの原因となる）のように、機能するためにオープンソースに依存しているものもあります。Pythonをクローズドソースプロジェクトにすることは、コンピューティングの世界にとって壊滅的なものになるでしょう。
  • それは漏洩されるまでクローズドソースです。そして、おそらく最終的には漏洩されるでしょう。そして、その時、あなたは最初にコードベースをクリーンで安全に保つための長年の公開レビューを受けていないでしょう。
  • 時には、PythonやJavaのようにバイトコードからソースコードを復元できるプログラミング言語のように、これはあまり関係ありません。
  • LLMはコンパイルされたバイナリをかなり効果的にリバースエンジニアリングすることもできます。
  • コードが以前オンラインにあった場合、その古いバージョンはまだオンラインにあります。誰かがどこかにそれを保持していると想定する必要があります。Shellshockは1989年から2014年までGNU Bashにありましたが、修正されるまで、それは地球上で最も広く使用されているプログラムの一つでした。
  • 私を悲しくさせます :(

AIを積極的に受け入れるアプローチ：勝てないなら、参加する。言い換えれば、私たちがより優れたLLMを、より速く、より多くのお金とより良いモデルでコードに実行していれば、相手はLLMを使って脆弱性を発見できません。

長所:

  • いくつかの非常に裕福なテックCEOを非常に幸せにします。
  • 大量のバグを発見するでしょう。

短所:

  • いくつかの非常に裕福なテックCEOを非常に幸せにします。
  • 大量のバグを発見するでしょう。（誰かがそれらを修正する必要があるでしょう。）
  • 多額のお金がかかります。
  • AIがそれを容易にするとしても、これを適切に行うには依然として専門知識と深い技術的知識が必要です（今のところ）。

楽観主義者のアプローチ：すべての企業がトップクラスのセキュリティ体制、十分に理解されたリスク、十分に文書化されたプロセスなどを備え、セキュリティ脆弱性の報告、処理、緩和のための標準化されたアプローチを普遍的に改善すること。

長所:

  • 素晴らしいアイデアです。
  • 他に誰もこれを思いつかなかったのはなぜでしょうか？
  • すごい、私たちはとても賢いですね。これで解決したのでしょうか？

短所:

  • 私たちはこの世界には住んでいません。私たちは決してこの世界には住まないでしょう。
  • これが実際にはかなり難しいことを言いましたか？そしておそらく不可能ですか？
  • 高価です。

今後、簡単な勝利を得ることもできます。「クリティカルな脆弱性の詳細をパッチがインストール可能になる前に発表しない」といったことですが、このケースでは意図しないリークにより、公式発表前でさえ誰もが脆弱性について知っていました。おそらくそれさえも要求しすぎかもしれません。この場合、複数の個人や企業の一連のミスが、パッチが利用可能になる数時間前にエクスプロイトが実際に使用される原因または加速させたため、誰もがサーバーをオフラインにしました。AWSはその後、これらのリークが発生する前の10月17日から、誰かがこの脆弱性を試しているのを見たと言っています。

shalk/debugやShai-Hulud、そして3月のLiteLLMインシデントの後で人気が出た最小リリース年齢でさえ、広く悪用されている脆弱性を修正する大規模なアップデートがパッチ適用されるまでに数日かかるため、攻撃者にあなたをハッキングする十分な時間を与えることになります。少なくとも、皆がパニックになってすべてのサーバーをオフラインにするのを避けるために、より良いクライアント管理が必要かもしれません。

おそらく、広大なインターネットに何かを公開すれば、それはハッキングされると受け入れ、それに応じて計画を立てる必要があるだけかもしれません。おそらく、私たちの期待が間違っているのです。

結論

ここには間違いなくAIとセキュリティに関する物語があります。それはソフトウェアの世界を変えており、それがより良い方向なのか、それとも悪い方向なのかはまだ明らかではありません。お金は真実を歪める方法を知っています。まるで物質が時空を歪めるように、AIには中規模のブラックホールの真実の等価物を引き起こすのに十分なお金があります。AIには信じられないほどのお金が費やされており、それはあなたの人生のすべて、ソフトウェアやセキュリティさえも変えるだろうと、すべてがあなたに思わせたいと思っています。もちろん、それが真実ではないという意味ではありません。

自動化された分析ツールが10年代に多くの新しいバグを発見する原因となり、今また同じことが起きていると言う人もいます。私には質的に異なっているように感じますが、おそらくすべてが落ち着いて元に戻る前に、報告されるバグが増加する初期段階があるでしょう。私はそうは思いません。人間がすべての怪しいコードを書いたことが原因だと言う人もいます。AIが最初からすべてのコードを書くようになれば、LLMは人間よりも安全なコードを書くのが得意なので、脆弱性はなくなるでしょう。私はこの議論には納得していません。

多くの予測（12ヶ月後に私が必然的に間違っていると証明されて、馬鹿のように見られたくないので）はしていませんが、ソフトウェア業界は変わり、オープンソースも変わるでしょう。そして、この変化が私たち全員の利益になるように、そして特定の利益や民間企業のためにならないようにすることは、ソフトウェアコミュニティのメンバーとしての私たちの集団的な責任です。

更新

これは開発中のストーリーです – ここにどんな更新も記録します。私はある程度急いでこれを書いたので、いくつかの部分の言葉遣いや証拠を段階的に改善するかもしれません。

注釈

  1. パッチがリリースされる前に、実際に機能するエクスプロイトの試みがなされたかどうかについて、議論や意見の相違があります。↩
  2. 免責事項：私は、ある意味で英国政府のために働いています。↩
  3. GitLabはCVSS 3.1を使用しており、PHPはここでCVSS 4.0を使用しているため、わずかに異なるメトリックを使用してCVSSスコアを計算しています。そのため、直接比較することはできません。↩
  4. まあ、最後の点についてはそうかもしれません。↩
  5. もしこれらの非難されるべき犯罪者が正義に直面することになれば、彼らの最も長い刑罰は言葉遊びに対する罪であると提案します。本当にひどいものです。↩
  6. 明確にするために、このグループがロシアのハッカーであるという証拠はありません。彼らは主に金銭的な動機を持っているように見えるため、どこからでも来ている可能性があります。しかし、私の言いたいことはわかりますよね – 昔は、ロシアのフィッシングキャンペーンを文法的な特徴から見分けることができました。今では、AIのおかげで、その魅力はすべて失われています。↩
  7. 幸いなことに、彼がそうであるように、彼は誠実で信頼できる市民であり、大統領の個人的なアジェンダへの忠誠心や敬虔さではなく、国にとって最善のことに基づいて管理職の採用の決定を下しているため、大統領は責任者全員責任者が迅速に彼の政権から解任され、ワシントンで二度と見られなかったことを保証しました。↩