0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【警告】「npm install」しただけで感染? AI頼みの個人開発者が震えた、2026年10月のサイバー攻撃と脆弱

0
Posted at

「えっ、プログラムを書いているだけでパソコンが乗っ取られることがあるの?」

あります。

しかも、自分が悪いプログラムを書いていなくても。

便利だからとインストールした部品に、悪意のあるプログラムが紛れ込んでいる場合があるそうです。

いや、待って。

私はAIにコードを書いてもらって、それを理解するだけでも必死なんですが。

そこにサイバー攻撃まで気を配れと?

初心者への要求スペック、高すぎない???

こんにちは。猫とAIと個人開発を愛する、でやまです。

私はエンジニアとしてはまだまだ勉強中。ChatGPTやCodexに助けてもらいながら、Webサイトを作ったり、アプリを開発したりしています。

最近は夫婦で小さなIT事務所も始めました。

つまり、ようやく「作ること」に慣れてきたくらいの人間です。

そんな私が2026年10月、Node.jsやPHPの重大な脆弱性、世界中で起きているサイバー攻撃の情報を調べてみました。

そして思いました。

これ、エンジニアだけが知っていればいい話じゃないぞ。

AIでアプリを作っている人、ホームページを運営している人、パソコンを仕事に使っている人。

今は誰でも、知らないうちに攻撃の入口を持っている可能性があります。

今回は、2026年10月25日時点で確認できた主な脆弱性と実際の攻撃を、初心者の私なりにわかりやすくまとめます。

専門用語も使います。でも、できる限り説明も付けます。

私と同じく、横文字が3つ並ぶと脳のファンが全力回転する人にも読んでいただければ幸いです。

※本記事は2026年10月25日時点の公開情報をもとに作成しています。世界中のすべての脆弱性を網羅したものではありません。また、紹介する脆弱性がすべて実際の被害につながったわけではありません。


1. そもそも「脆弱性」ってなんなの?

まずはここから。

脆弱性(ぜいじゃくせい)とは、ソフトウェアやシステムに存在するセキュリティ上の弱点のこと。

家に例えるなら、玄関には立派な鍵が付いているのに、裏口の鍵が壊れていたり、窓がきちんと閉まらなかったりする状態です。

攻撃者は、そういう弱点を探します。

しかも困ったことに、脆弱性は私たちが作ったプログラムだけに存在するわけではありません。

  • WindowsなどのOS
  • Chromeなどのブラウザ
  • Node.jsなどの実行環境
  • npmからインストールしたライブラリ
  • WordPressなどのWebシステム
  • サーバーやネットワーク機器

このような、日常的に利用しているソフトウェアにも弱点は見つかります。

つまり、私がどれだけ頑張ってコードを書いたところで、使っている部品そのものに脆弱性があれば、影響を受ける可能性があります。

私のコード、まだそこまで高度なことしてないのに、セキュリティだけ世界レベルで戦わされてる。

ちなみに、よく出てくる「CVE-2026-XXXXXX」という文字列。

これは脆弱性に付けられる識別番号です。

CVEは Common Vulnerabilities and Exposures の略。

いわば、脆弱性の管理番号ですね。

また、CVSSという危険度の評価指標もあります。

基本的には数値が高いほど深刻ですが、点数が高いからといって、すべての環境で必ず攻撃が成功するわけではありません。

そして、ここがとても大事。

「脆弱性が見つかった」と「実際に攻撃された」と「情報が盗まれた」は、全部違います。

怖い見出しを見かけたら、まずはこの3つを区別して読みたいところです。


2. 【重要】Node.jsに重大な脆弱性10件。10月21日に緊急修正

個人開発者として、まず目を疑ったのがこれ。

2026年10月21日、Node.jsの公式開発チームが10件の脆弱性に対応するセキュリティ更新を公開しました。

Node.jsとは、JavaScriptというプログラミング言語を、Webブラウザの外でも動かせるようにする仕組みです。

Webアプリを作ったり、開発ツールを動かしたりする際によく使います。

私のようにVS Codeを開いて、AIに指示を出しながらアプリを作っている人にもおなじみです。

そして私はNode.jsのバージョンなんて、普段ほとんど見ていませんでした。

動いてるからヨシ!

……よくないらしい。

今回発見された主な問題

10件の中でも特に気になるのが、CVE-2026-111497です。

これはBrotliというデータ圧縮方式を処理する部分の脆弱性。

圧縮データとは、大きなデータを小さくまとめたものです。旅行に行く前、圧縮袋で洋服を小さくするのと似ています。

ところが、攻撃者が細工したデータをNode.jsに展開させると、内部のメモリが壊れてしまう可能性があります。

結果として、プログラムの異常終了、メモリ内の情報漏えい、最悪の場合は不正なコードの実行につながるおそれがあります。

最後のものは、**RCE(Remote Code Execution:リモートコード実行)**と呼ばれます。

簡単にいうと、外部からサーバーに勝手な命令を実行させることです。

そのほかにも、DNSというインターネット上の住所案内に関係する問題や、通信相手の電子証明書を確認する仕組みの問題、ファイルへのアクセス制限に関係する問題が修正されています。

公式に公表された10件のCVE番号は以下です。

CVE番号 主な問題
CVE-2026-111497 Brotli圧縮データの処理によるメモリ破損
CVE-2026-105482 DNSの名前解決で別の接続先を扱ってしまう
CVE-2026-105483 特殊なIPアドレス表記による証明書検証の問題
CVE-2026-106069 IPアドレスの解釈の違いによる証明書検証の問題
CVE-2026-105481 HTTP通信で不正な応答を受け入れる
CVE-2026-106072 非標準的なIP表記による証明書検証の回避
CVE-2026-106074 特定条件で乱数やUUIDが重複・予測可能になる
CVE-2026-106070 ZIPファイルの不正な内容を誤認する
CVE-2026-106071 ファイルアクセス許可が広く認められる
CVE-2026-106073 制限されたファイルの存在や場所を調べられる

ただし、これらの問題がすべて同じ深刻度ではありません。

また、Node.jsをインストールしているだけで、必ず外部から乗っ取られるわけでもありません。

使用している機能やアプリの構成によって、実際の影響は変わります。

修正されたNode.jsのバージョン

2026年10月21日に公開された修正版はこちらです。

Node.jsの系列 修正版
22系 22.23.4
24系 24.22.1
26系 26.12.1

Node.jsにはLTSという長期サポート版があります。

新しく開発するなら、サポートされているLTSを選ぶのが基本です。ただし、既存プロジェクトは対応するNode.jsのバージョンを確認してから更新しましょう。

確認方法は簡単。

VS CodeのターミナルやPowerShellで、次を入力します。

node -v

バージョンが表示されます。

私のように「昨日まで動いていたものを更新したら、今日から動かなくなった」という悲劇を起こしたくない人は、いきなり大幅にバージョンを変えないでください。

セキュリティ対策のつもりで、自分の手でアプリを壊すのは避けたい。

公式情報:Node.js 2026年10月セキュリティリリース


3. 【実際に攻撃発生】npmの「正規パッケージ」が汚染された

正直、今回の調査で一番怖かったのがこちらです。

2026年8月、400以上のnpmパッケージを巻き込むサプライチェーン攻撃がMicrosoftによって報告されました。

サプライチェーン攻撃とは、ソフトウェアを作るために使う部品や、部品を配布する仕組みを狙う攻撃です。

npmはNode.jsで使うパッケージ管理ツール。

便利な機能を追加したいとき、たとえばこんなコマンドを使います。

npm install パッケージ名

私も使います。

というか、AIが「これをインストールしてください」と言ってくるので、言われるがまま実行してきたこともあります。

AI「こちらのコマンドを実行してください」
私「はい喜んで!」

居酒屋の店員さんより返事がいい。

でも、この攻撃を知ってからは、少し考えるようになりました。

何が起きたの?

Microsoftが2026年8月4日に報告した「ChainDrop」という攻撃では、正規のnpmパッケージの公開権限などが悪用され、悪意のあるバージョンが配布されました。

調査対象にはkeyv、flat-cache、cache-managerなどに関連するパッケージも含まれています。

攻撃者のプログラムは、インストール処理の途中で実行される仕組みを利用していました。

感染すると、開発用パソコンや自動ビルド環境に保存された認証情報を探します。

たとえば、

  • GitHubのトークン
  • npmの公開権限
  • クラウドサービスの認証情報
  • 開発環境内の秘密情報

などです。

そして、盗んだ権限で別のパッケージに悪意のあるコードを混ぜ、感染を広げることもありました。

つまり、攻撃者が作った怪しい名前のパッケージをインストールするだけが危険なのではなく、普段から利用されている正規パッケージも攻撃対象になるということです。

これは困る。

私のような初心者に、パッケージの中身を全部読んで安全性を証明しろと言われても。

無理です。

猫のごはんの原材料表示ですら、全部は理解できていません。

どんな被害が考えられる?

盗まれたAPIキーで外部サービスを不正利用されたり、GitHubのソースコードを書き換えられたりする可能性があります。

最悪の場合、自分が公開するアプリに悪意のあるコードが混入することも考えられます。

APIキーとは、外部サービスを利用するための秘密の合鍵のようなものです。

これが流出すると、攻撃者が契約しているサービスを勝手に利用したり、許可されている範囲の情報を取得したりできる場合があります。

自分はアプリを作っているつもりなのに、知らない間に攻撃者のための開発環境になっていたら笑えません。

公式に確認された攻撃なので、単なる可能性の話ではありません。

ただし、npmを使った全員が感染したという意味ではありません。汚染された特定のバージョンを、影響を受ける条件で利用した場合の問題です。

Microsoftの調査:ChainDrop supply chain compromise


4. React・Next.jsも危ない? 10月14日に重大な修正

Reactは、WebサイトやWebアプリの画面を作るためによく使われるライブラリです。

Next.jsは、Reactを利用してWebアプリやWebサービスを作るためのフレームワークです。

フレームワークとは、開発に必要な仕組みをあらかじめまとめてくれた土台のこと。

例えるなら、Reactが建物を作るための部品、Next.jsは部品と建築方法がある程度セットになったもの、でしょうか。

私なら最初から完成した家を買いたいところですが、個人開発者なので今日もせっせと組み立てています。

2026年10月14日に修正された問題

React Server Componentsという、サーバー側で動作するReactの仕組みに重大な脆弱性が見つかりました。

識別番号はGHSA-xqc2-xf4c-x3h3。

条件を満たしたアプリへ特殊なデータを送ることで、外部から不正なコードを実行される可能性があります。

さらにNext.jsでも、キャッシュ機能やSVG画像の処理などで、RCEにつながる重大な脆弱性が修正されました。

修正版は次のとおりです。

製品 修正版
Next.js 15系 15.5.28
Next.js 16系 16.4.1
React Server Components 19.0系 19.0.9
React Server Components 19.1系 19.1.10
React Server Components 19.2系 19.2.9
React Server Components 19.3系 19.3.1

ただし、Reactを使っているWebサイトがすべて危険という意味ではありません。

普通のブラウザ上だけで動くReactアプリなど、今回の脆弱性に該当しない構成もあります。

まずは自分のアプリがどの仕組みを使っているのか確認することが大切です。

公式情報:Next.js 2026年10月14日セキュリティ更新

公式情報:React Server Componentsの重大な脆弱性


5. Vite・Axiosにも脆弱性。「開発中だから大丈夫」は通用しないことも

続いて、JavaScript開発者にはおなじみのViteとAxiosです。

Vite:見せてはいけないファイルが見える可能性

Viteは、JavaScriptやReactなどの開発でよく使われるツールです。

2026年10月6日と21日に、複数のセキュリティ問題が公表されました。

中でも気になるのは、開発サーバーが本来公開してはいけないファイルを返してしまう可能性がある問題です。

たとえば、.envというファイル。

これはAPIキーや設定情報などを保存するためによく利用されます。

.envは、ネット上に堂々と置いてよい秘密のメモ帳ではありません。

そもそも秘密のメモ帳を世界中の人が読めるところに置いたら、秘密でも何でもないです。

Viteの問題は、特に開発用サーバーを外部ネットワークからアクセスできる状態にしている場合に注意が必要です。

ただし、通常のローカル開発で外部からアクセスできない設定なら、同じ条件で直接攻撃される危険は抑えられます。

公式情報:Vite Security Advisories

Axios:通信に関係する問題

Axiosは、Web APIなどと通信するためによく使われるJavaScriptライブラリです。

2026年9月16日には、通信の制限を回避されたり、特殊なデータで処理が止まったりする複数の問題が公表されています。

たとえば「この通信先にはアクセスしないでね」と設定していたのに、条件によってその制限を回避されるケースです。

主な修正はAxios 1.20.0に含まれています。

もちろんAxiosを使用していなければ、Axios固有の脆弱性は直接関係ありません。

公式情報:Axios Security Advisories


6. PHP2shellって何? WordPressやホームページ管理者は要注意

2026年10月21日、PHPにも重大なセキュリティ修正が公開されました。

PHPは、WordPressなど多くのWebサービスで利用されているプログラミング言語です。

今回公表された脆弱性は、次の2件です。

  • CVE-2026-109618
  • CVE-2026-109619

この2件はPHP2shellと呼ばれています。

メモリ不足時のエラー処理や、過去の通信処理で使ったメモリの扱いに問題があり、条件によっては外部から不正なコードを実行される可能性があります。

修正版はこちらです。

PHP系列 修正版
8.2 8.2.35
8.3 8.3.36
8.4 8.4.27
8.5 8.5.12

IPA(情報処理推進機構)も10月22日に注意喚起を公表しています。

ただし、10月21日のIPA発表では、今回の脆弱性を悪用した攻撃は確認していないと説明されています。

つまり、重大な弱点が確認されたことと、実際に攻撃が起きたことは別です。

そこは冷静に読みたいところ。

そしてもう一つ。

WordPressを使っている人は、WordPress本体の更新とPHPの更新を別々に考える必要があります。

WordPressは2026年10月6日に7件のセキュリティ修正を含む7.1.3を公開しています。

PHPだけ更新しても、WordPress本体やプラグインが古いままなら別の問題が残る可能性があります。

ちなみに、私の事務所のホームページはWixで運営しています。

Wixのようなサービスでは、利用者がPHP本体を直接更新するわけではありません。サービス提供者が管理する部分と、私たちが管理する部分を分けて考える必要があります。

何でもかんでも「PHPを更新しなきゃ!」と焦る必要はありません。

まず自分が何を使っているかを確認する。それが大事です。

公式情報:IPA:PHP2shellの脆弱性対策

公式情報:WordPress 7.1.3セキュリティ更新


7. Windows・Chromeも他人事じゃない

ここまで読んで、

「私はプログラミングなんてしないし、関係ないかな」

と思った人。

まだ帰らないでください。

WindowsやChromeにもセキュリティ更新が必要です。

Windows 11

Microsoftは2026年10月、複数の脆弱性を修正しました。

特にCVE-2026-96951については、実際の悪用が確認されています。

Windowsの安全機能を回避される可能性がある問題で、IPAも10月14日に緊急の注意喚起を出しています。

対応は基本的にWindows Updateです。

「設定」からWindows Updateを開き、最新の更新を確認しましょう。

更新後に再起動が必要な場合もあります。

私は再起動を後回しにしがちです。

タブを大量に開いて、何を調べていたのか自分でも覚えていないからです。

しかし、セキュリティ更新の再起動は後回しにしない方がよさそうです。

Google Chrome

Googleも2026年10月20日にChrome 156を公開しました。

この更新には、353件のセキュリティ修正が含まれています。

353件。

私の未処理タスクより多い気がします。

Chromeは「設定」→「Chromeについて」から更新を確認できます。

Chromeだけでなく、Microsoft EdgeやFirefoxなど、普段使うブラウザも更新しましょう。


公式情報:IPA:2026年10月のMicrosoft製品の脆弱性

公式情報:Google Chrome 2026年10月20日更新


8. 【スマホアプリ開発者は特に注意】アプリを解析して裏側のサーバーを攻撃する「A2B攻撃」

これは個人的に、かなり気になったニュースです。

2026年10月13日、情報通信研究機構(NICT)が、公開Androidアプリを解析してサーバーを攻撃する手法について注意喚起を公表しました。

名前はA2B攻撃(App-to-Backend Attack)。

Appはアプリ、Backendはアプリの裏側で動くサーバーのこと。

たとえば、スマホアプリで会員登録するとき、入力した情報を保存するサーバーがありますよね。

攻撃者は公開されているアプリを調べて、裏側でどんな通信をしているのか、どんなサーバーにつながっているのかを分析します。

そして、その情報をもとにサーバーの弱点を狙います。

表側のアプリを調べて、裏側の秘密を探ろうとするわけです。

私はまだアプリをストアで公開する準備をしている段階ですが、これは覚えておくべきだと思いました。

アプリの中に秘密のAPIキーを直接入れてしまったり、サーバー側のアクセス制限を適切に設定していなかったりすると、危険が大きくなる場合があります。

大事なのは、アプリ内に書いた情報は解析される可能性があるという前提で設計すること。

NICTは、同様の問題がiOSアプリやWebサービスでも起こり得ると説明しています。

AIのおかげでアプリを作るハードルは下がりました。

でも、アプリを公開するなら、利用者の情報を守る責任も付いてきます。

AIに「アプリ作って!」と頼むだけでは、セキュリティ対策まで自動的に完璧になるわけではない。

耳が痛いですね。

公式情報:NICT:アプリ解析からのサーバ攻撃への注意喚起


9. 実際に企業が攻撃されたら、何が起きるの?

ここからは仮定の話ではありません。

2026年に企業が公表した、実際の被害について紹介します。

NEC:委託先の攻撃から顧客システムにも被害

2026年10月20日、NECは委託先へのサイバー攻撃によって、顧客システムへの不正アクセスや情報漏えいが発生したと公表しました。

委託先の正規アカウントの認証情報が盗まれ、それを使って顧客システムへアクセスされたとのこと。

結果として、ファイルの暗号化、システム停止、個人情報やシステム関連情報の漏えいが確認されています。

ここで怖いのは、自分の会社が直接攻撃されなくても、仕事を任せている相手から被害が広がる可能性があることです。

私は小さなIT事務所を運営しています。

将来、お客様のホームページやアカウントをお預かりする機会もあります。

つまり、私の管理が甘かった場合、私だけでなくお客様にも迷惑をかける可能性がある。

これは本当に気を付けたいところです。

公式情報:NEC:委託先への不正アクセスに起因する被害について

タイムズカー:本人確認書類の画像データにも影響

2026年10月23日、タイムズモビリティはWebシステムへの不正アクセスに関する調査結果を公表しました。

その中では、本人確認書類の画像データ約146万件について、外部送信の痕跡が確認されたと説明されています。

ただし、画像データは暗号化された状態で保管されていたため、外部送信の痕跡があることと、画像の中身をそのまま閲覧されたことは同じではありません。

この区別は大切です。

また、同社は被害を受けたあと、本人確認書類の画像の保有方法についても見直しています。

この事件から私が学んだのは、必要以上の個人情報を長期間保存すること自体が、事業者にとってリスクになるということです。

これは、小さなWebサービスでも無関係ではありません。

公式情報:タイムズモビリティ:不正アクセス調査結果

PingCAP:GitHubの認証情報が侵入経路の一部に

2026年10月23日、データベース技術を提供するPingCAPもセキュリティ事故について公表しました。

侵害されたGitHubアカウントや露出していた認証情報を利用され、社内システムへの不正アクセスや情報のコピーが行われたと説明しています。

開発者としては、かなり気になる事件です。

GitHubはソースコードを保存するだけでなく、自動ビルドや公開作業にも使えます。

つまり、GitHubの認証情報が漏れると、被害がソースコードの閲覧だけで済まない場合があります。

GitHubのパスワードを適当にしていたら、未来の自分が泣く。

そういうことですね。

公式情報:PingCAP Trust Hub


10. ハッカーはどうやって攻撃してくるの?

ここまで読むと、攻撃者というのは映画に出てくるような、黒いパーカーを着た天才プログラマーばかりだと思うかもしれません。

でも、現実の攻撃はもっと地味で、もっと厄介です。

たとえば、次のような方法があります。

フィッシング

本物の会社やサービスを装ったメール・SMS・Webサイトなどで、パスワードや認証情報を盗み取る手口です。

認証情報の悪用

盗まれたIDやパスワードを使って、正規の利用者としてログインします。

脆弱性の悪用

更新されていないソフトウェアの弱点を使い、サーバーやネットワークへ侵入します。

サプライチェーン攻撃

正規のソフトウェアやライブラリの配布経路に悪意のあるコードを紛れ込ませます。

そして、被害を受けた企業に金銭を要求する攻撃もあります。

ランサムウェアと二重脅迫

ランサムウェアとは、データを暗号化して使用できなくするなどして、身代金を要求するマルウェアの一種です。

さらに近年は、データを盗んだうえで、

「お金を払わなければ公開する」

と脅す手口もあります。

これを**二重脅迫(ダブルエクストーション)**と呼びます。

2026年10月、米国CISAとFBIなどは、ランサムウェア集団SafePayについて共同注意喚起を公表しました。

2024年8月以降、少なくとも600組織に影響があったと報告されています。

この集団は、認証情報の窃取、VPNの悪用、未修正の脆弱性を使った侵入などを行い、データの窃取や暗号化を通じて金銭を要求する手口が確認されています。

怖いですね。

でも、これを知ったからといって、パソコンを窓から投げ捨てるわけにもいきません。

まだローンの残っているパソコンだったら、物理的な被害が増えるだけです。

私たちにできるのは、攻撃の入口を減らして、万が一の被害を小さくすることです。

参考:CISA・FBIなどによるSafePayへの共同注意喚起


11. AI頼みの個人開発者が、今日からできること

ここまで読んで、

「わかった。危ないのはわかった。で、何をすればいいの?」

となった人。

大丈夫です。

私も同じです。

専門用語を50個覚えるより、まずは実際に使っているパソコンや開発環境を確認しましょう。

① Windowsとブラウザを更新する

まずは一番身近なところから。

Windows Updateを確認し、ChromeやEdge、Firefoxなども更新します。

必要な再起動も忘れずに。

② Node.jsとnpmのバージョンを確認する

VS CodeのターミナルやPowerShellで、次を実行します。

node -v
npm -v

使用しているバージョンが表示されます。

Node.jsは公式のセキュリティ情報と照らし合わせて、修正が必要か確認しましょう。

ただし、プロジェクトが必要とするバージョンを調べずに、いきなり最新版へ変更するのは避けたいところです。

③ npmの脆弱性を確認する

開発中のプロジェクトフォルダで、次のコマンドを実行します。

npm audit

既知の脆弱性を持つ依存パッケージがあるか確認できます。

さらに、

npm outdated

で更新候補を調べられます。

ただし、npm auditで問題が表示されなくても、未知のマルウェアまで完全に見つけられるわけではありません。

また、何も考えずにnpm audit fix --forceを実行すると、互換性のないバージョンへ更新される場合があります。

セキュリティ対策でアプリが起動しなくなったら、それはそれで泣きます。

まずは結果を確認し、必要な修正だけをテストしながら行いましょう。

④ GitHubのセキュリティ設定を確認する

GitHubには、依存パッケージの脆弱性を知らせるDependabot alertsや、秘密情報の漏えいを検出するSecret scanningなどがあります。

利用できる機能は、リポジトリやプランなどの条件によって異なります。

GitHubのアカウントには多要素認証を設定し、不要なアクセストークンや、必要以上の権限を持つトークンがないか確認しましょう。

⑤ APIキーをソースコードに直接書かない

AIを使っていると、コードが動くことを優先してしまいがちです。

しかし、公開するソースコードやブラウザから読み取れるプログラムに、秘密のAPIキーを直接埋め込むのは危険です。

.envや各サービスの秘密情報管理機能などを利用して、用途に合った場所で管理することが大切です。

なお、.envなら何でも安全というわけではありません。公開環境への配置方法やアクセス制限も重要です。

すでに秘密情報を公開してしまった場合は、ファイルから削除するだけでなく、その認証情報を無効化・再発行することも必要です。

一度流出した合鍵は、隠し直しても合鍵のままです。

⑥ AIが提案したコマンドをそのまま実行しない

これが私には一番刺さります。

AIが出してくれたコードやコマンドはとても便利です。

でも、AIが提案した内容が常に安全とは限りません。

特に、新しいパッケージのインストール、ファイル削除、権限変更、外部サイトからのスクリプト取得などは、実行前に内容を確認するようにしましょう。

わからなければ、別のAIに「このコマンドは何をする? 危険なところはない?」と確認する方法もあります。

ただし、AI同士が同じ間違いをすることもあるので、重要な変更は公式ドキュメントと照らし合わせる必要があります。

AI「安全です」
別のAI「安全です」
私「じゃあ安全……なのか?」

多数決で決める話ではありません。

⑦ バックアップを取る

大事なソースコード、設定、データは定期的にバックアップしましょう。

GitHubへpushしているだけでは、すべてのバックアップが十分とは限りません。

データベースや、GitHubに保存していない設定、公開サービスのデータなども確認が必要です。

特に、バックアップ先まで同じアカウントで削除できる構成だと、アカウント乗っ取りによって一緒に消される危険があります。

別の場所にも保管し、必要なときに復元できるか確認することが大切です。


12. 「でも私、Wixでホームページ作ってるだけだよ?」という人へ

Wixのようなホームページ作成サービスを使っている人は、Node.jsやPHPの更新を自分で実施する必要があるとは限りません。

基盤部分はサービス提供者が管理しているためです。

ただし、それで完全に安全という意味ではありません。

たとえば、

  • Wixアカウントの乗っ取り
  • 不要な共同管理者の放置
  • 外部サービスとの連携設定
  • 問い合わせフォームで扱う個人情報の管理
  • 偽メールによる認証情報の窃取

などは、サイト運営者自身にも関係する問題です。

私もWixでホームページを運営しているので、今回の調査を機に管理者や連携アプリの設定を確認しようと思いました。

サーバーの難しい設定を自分で管理しなくてよいのはありがたいことです。

しかし、管理しているアカウントそのものを盗まれたら大変です。

「Wixだから安全」「WordPressだから危険」といった単純な話ではありません。

どのサービスにも、サービス提供者が守る部分と、利用者が守る部分があります。

そこを理解しておきたいですね。


13. そもそも、私たち初心者はどうやって勉強すればいいの?

ここまで読んで、少し疲れませんでしたか?

私は疲れました。

脆弱性、CVE、RCE、npm、TLS、DNS、CI/CD、APIキー、サプライチェーン……。

もうアルファベットはお腹いっぱいです。

でも、今回調べていて気付いたことがあります。

全部の専門用語を暗記する必要はない。自分が使っているものを把握することが、最初の一歩になる。

自分のパソコンはWindowsなのかLinuxなのか。

自分のアプリはNode.jsを使っているのか。

Next.jsなのか、普通のJavaScriptなのか。

npmから何をインストールしているのか。

GitHubの認証情報はどこで管理しているのか。

そういう基本情報を一つずつ知っていくことが大切なんだと思います。

そして、これはAIを使って開発している人ほど意識したいことです。

AIは、コードを書いたり、エラーを調べたり、わからない言葉を説明したりしてくれます。

でも、公開するアプリに責任を持つのは、最終的には開発者です。

私は「AIが作ったからわかりません」で済ませないようにしたい。

もちろん、まだまだわからないことだらけです。

それでも、「これは何のために必要なの?」「どうしてこのライブラリを使うの?」「このコードに危険はないの?」と確認する習慣は付けられます。

完成させることと、安全に使ってもらうこと。

個人開発者として、両方を目標にしたいと思いました。


14. 最後に。怖がるより、確認しよう。

今回の調査をして、正直少し怖くなりました。

自分が一生懸命作ったアプリ。

時間をかけて整えたホームページ。

AIに何度も「そこじゃない」と言いながら修正してもらったコード。

それらが攻撃で壊されたり、利用者に迷惑をかける原因になったりするのは避けたいものです。

でも、怖いからといって開発をやめる必要はありません。

セキュリティの脆弱性は、発見され、修正され、対策が進められています。

大切なのは、「何が危険なのか」「自分が使っているものに関係するのか」「何を更新すればよいのか」を知ること。

私のような初心者でも、まずはバージョンを確認するところから始められます。

そして、全部を一日で完璧にする必要もありません。

体調のいい日に一つずつ。

今日できなければ、別の日に。

ただし、実際に悪用されている重大な脆弱性が自分の公開システムに該当する場合は、放置せず、必要に応じて公開停止や管理者への相談なども含めて早急に対応したいところです。

AIにコードを書いてもらう時代だからこそ、そのコードを使う私たちにも最低限のセキュリティ知識が必要なのだと思います。

ちなみに、この記事を書いている私は、セキュリティの専門家ではありません。

AIと一緒に個人開発をしている、まだまだ勉強中の人間です。

だからこそ、同じ初心者の方に、難しい言葉をできるだけかみ砕いて伝えたいと思い、今回の記事を書きました。

最後にひとつだけ。

「昨日まで動いていたから、今日も安全」とは限りません。

私自身、これを忘れないようにしたいと思います。

さて、まずは自分のNode.jsのバージョンでも確認してきます。

もし古かったら?

……そのときはAIに相談しながら、慎重に更新します。

AI頼みは続くんかい。

続きます。

でも、丸投げは少しずつ卒業したい。

そんな個人開発者のセキュリティ勉強記録でした。

最後まで読んでいただき、ありがとうございました。


参考資料・一次情報

この記事は2026年10月25日時点で公開されていた各開発元、政府・公的機関、被害企業の情報をもとに作成しました。

開発環境・ソフトウェア

国内の公的機関

実際の攻撃・企業被害

※実際の被害については、各社が公表した範囲を記載しています。未確認の攻撃原因や被害規模を断定するものではありません。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?