リカバリーコードでサインインした npm アカウントは、72時間 publish やアクセストークン作成ができなくなる。何が止まり何が使えるか、解除の条件、身に覚えがないときの判断を、パッケージを公開するメンテナ向けに整理した。
72時間 リカバリーコードでサインインした後、publish とトークン作成が止まる期間 GitHub Changelog（2026年9月9日）。期限が来れば自動で解除され、サポートへの依頼は不要
リカバリーコードで npm にサインインしたら、publish もアクセストークンの作成も止まった。サインインはできるし、パッケージの閲覧やインストールも普通に通る。書き込みだけが受け付けられない。この症状は、2026年9月9日付の GitHub Changelog で告知された リカバリーコード使用後のセキュリティホールド（recovery-code security hold）に当たる。72時間たてば自動で解け、npm Support への依頼も要らない。
変わったのは対象の広さだ。このホールドはこれまで high-impact なアカウントにだけかかっていたが、今回から すべての npm アカウント に適用される。パッケージを公開しているメンテナなら、リカバリーコードでサインインしたあとの72時間は publish できない、と覚えておけばいい。
| 操作 | ホールド中（72時間） | changelog での書かれ方 |
|---|---|---|
| パッケージの publish | 止まる | publishing と明記 |
| アクセストークンの作成 | 止まる | creating access tokens と明記 |
| その他のセキュリティ上重要な書き込み | 止まる | security-sensitive writes とだけあり、一覧はない |
| サインイン | できる | sign in と明記 |
| パッケージの閲覧 | できる | browse と明記 |
| パッケージのインストール | できる | install と明記 |
出典：GitHub Changelog「npm extends recovery-code security holds to all accounts」（2026年9月9日）
表の3行目が曖昧なところだ。「security-sensitive writes」にほかに何が含まれるのか、changelog に一覧はない。publish とトークン作成以外の書き込みがホールド中に通るかどうかは、告知からは判断できない。
できる側の3行は、サインインとパッケージを読む操作だ。閲覧とインストールはホールド中でも通ると明記されているので、依存パッケージを入れて手元の開発を続けるぶんには困らない。
困りやすいのは、リカバリーコードでサインインしたその足で別の作業に移る場面だ。CI 用のトークンを発行し直すつもりでサインインしても、トークン作成はホールドの対象なので72時間後まで持ち越しになる。リリース直前にリカバリーコードを使うと、そのアカウントでの publish は72時間待ちになる。
publish をしないアカウントにも関係はある。changelog はトークンの種類や用途で区別していないので、publish 以外の目的でトークンを発行したい場合も、ホールドが切れるまで待つことになる。
発行済みのトークンを使った publish、たとえば CI からのリリースがホールド中にどう扱われるかは書かれていない。changelog は publishing が止まるとだけ書き、経路を区別していない。CI からの公開を予定しているなら、通らない前提で段取りを組んでおくほうが安全だ。
ホールドは期限が来れば自動で外れ、フルアクセスに戻すために自分で操作する必要も、サポートに依頼する必要もない。changelog にはそう書かれている。
72時間は丸3日だ。金曜の夜にリカバリーコードでサインインすれば、publish できるようになるのは月曜の夜になる。期限より前に解除してもらえるのかは changelog に書かれていないので、急ぎのリリースを抱えていても、72時間を待つ前提で予定を組み直すことになる。
この仕組みは、npm が high-impact アカウント向けに先に入れていた予防的なアカウント保護を土台にしている。狙いは二つあると changelog は説明する。乗っ取りの試みをさらに遅らせること、そして漏えいしたリカバリーコードを使った悪意ある publish のリスクを下げることだ。
攻撃する側から見ると効き方がわかる。漏れたリカバリーコードでサインインまで進めても、そこから72時間は publish もトークン作成も通らない。
変更前は、high-impact に当たらないアカウントならこの待ち時間がなかったことになる。どのアカウントが high-impact に分類されていたのかは、この changelog では定義されていない。いまは全アカウントが対象なので、自分がどちらに入っていたかを気にする必要はなくなった。
publish が止まったとき、最初に確かめるのは、直近72時間以内に自分でリカバリーコードを使ってサインインしたかどうかだ。使ったのなら想定どおりのホールドで、待てば戻る。
使っていないのに publish が止まったなら、changelog は すぐに npm Support へ連絡する よう求めている。自分のリカバリーコードを誰かが使ってサインインした可能性がある、と読める。changelog 自体はそこまで書いていないので、これは推測だ。いずれにしても、72時間の自動解除を待つ場面ではない。
リカバリーコードを使う予定があるなら、その後の72時間に publish やトークン発行の予定を入れない。使った覚えがないのに止まったら、待たずに連絡する。メンテナが覚えておく判断は、この二つだ。
