セキュリティ

Renta!不正アクセスでサービス停止：再開未定の現状と運営側の停止判断・証拠保全・段階的再開

Renta!不正アクセスでサービス停止：再開未定の現状と運営側の停止判断・証拠保全・段階的再開

電子書籍ストア「Renta!」を運営するパピレスは、2026年10月18日にサーバーへの外部からの不正アクセスの可能性を把握し、サービスを一時停止しました。10月21日の続報でも詳細は調査中で、再開時期は未定です。本記事では、会員が知りたい「情報は漏れたのか」「読めなかったレンタル作品はどうなるか」「パスワードは変えるべきか」に、公表済みの事実だけで先に答えます。後半では会員サービスを運営する側に向けて、疑いの段階で止める判断、停止直後の証拠保全、購入済み作品の閲覧から戻す段階的再開を、手元で動かしたPythonで示します。

まとめ：Renta!の停止で公表された事実と会員が今日確かめること

確定しているのは、10月18日に不正アクセスの「可能性」を把握してサービスを止めたこと、10月21日時点でも調査中で再開時期が決まっていないことの2点です。会員情報が流出したかどうか、件数、侵入経路は公表されていません。同じ時期に止まったコミックシーモアとの関係を示す公式発表もありません。

会員が今日やることは2つです。Renta!と同じメールアドレスとパスワードを他社サービスで使っているなら、そちらを先に変えておくこと。そして、お詫びや補償をうたうメールのリンクを開かず、パピレスのコーポレートサイトで発表を確かめることです。運営側が学べるのは、確定前に止めた判断と、止めた後に何を残し、どの順で戻すかの設計です。

項目 公表されている内容（10月23日確認）
不正アクセスの把握 2026年10月18日（可能性の段階）
サービスの状態 一時停止・緊急メンテナンス中
再開時期 未定（10月21日時点）
会員情報の流出 公表なし（影響範囲は精査中）
レンタル作品 読めなかった作品は別途対応を検討
業績への影響 算定できていない（10月19日開示）

表は適時開示、10月21日のニュースリリース、停止中の画面の文言をもとに当社がまとめたものです。

会員が最初に確かめる4点｜情報流出の有無・レンタル作品・パスワード・偽メール

会員情報の流出は10月21日時点で未公表で影響範囲を精査している段階

10月21日のパピレスのニュースリリースは、不正アクセスの詳細は調査中で、影響範囲は精査中だと書いています。会員情報が漏れたとも、漏れていないとも書いていません。今の段階で「自分は大丈夫」と判断できる材料はありません。

「流出なし」と「流出の発表がない」は別のことです。ほかの事案では、停止の翌日以降の続報で流出が判明した例があります。10月15日に止まったコミックシーモアは、翌日の第2報で会員情報の流出を公表しました（詳細はコミックシーモアの不正アクセスの記事）。Renta!でも続報の内容が変わる前提で待つのが安全です。

停止中に読めなかったレンタル作品は別途対応を検討すると停止画面で告知

2026年10月23日6時12分（日本時間）に当社がRenta!のトップページを開いたところ、10月21日更新の停止画面が表示されました。そこには「メンテナンス期間中に閲覧できなかったレンタル作品については、別途対応を検討させていただきます」とあります。期限の延長か、返金やポイントか、申請が要るのかは書かれていません。

対応の中身が決まったときに照合できるよう、停止前に借りていた作品の名前と借りた日時を、購入完了メールなど手元に残っている記録から控えておくと確実です。購入済みの作品やポイントが消えたという発表もありません。

他社で使い回しているパスワードの組み合わせを優先する変更手順

Renta!のパスワードは、サービスが止まっているため今は変えられません。流出が確認された場合は、再開時に運営側から再設定の案内が出るのが一般的な流れです。待っている間にできるのは、同じメールアドレスとパスワードで登録している他社サービスの変更です。

順番はメールアカウント、ネット銀行と決済、通販サイトが目安です。メールを乗っ取られると、ほかのサービスのパスワード再設定まで奪われます。使い回しをやめる決め方はパスワード管理のベストプラクティスで整理しました。

会員向けのお詫びや補償を装う偽メールの見分け方と公式発表の確認先

停止画面は、最新情報をパピレスのコーポレートサイトとRenta!公式Xで知らせるとしています。補償やレンタル延長をうたうメールやSMSが届いても、本文のリンクは開かず、自分でブラウザにpapy.co.jpを入れて発表を探してください。上場会社なので、業績に関わる発表は10月19日の適時開示と同じTDnetにも載ります。

カード番号や暗証番号の入力を求める連絡は、まず疑ってかまいません。フィッシングの最新の報告はフィッシング対策協議会が公開しています。

公式発表2本と停止画面を時系列で確認｜10月18日の把握から21日の続報まで

適時開示・ニュースリリース・停止画面の3つで分かったことの一覧

公表された情報源は3つです。中身はほぼ重なりますが、書いてある項目が少しずつ違います。

情報源 日付 書かれていること
適時開示（TDnet） 10月19日 18日の把握と停止・業績影響は算定できず
ニュースリリース 10月21日 調査中・再開未定・影響範囲は精査中
停止画面 10月21日更新 レンタル作品は別途対応を検討

未公表のまま残っているのは、会員情報の流出の有無、件数、侵入経路、不正アクセスが始まった日時、再開日の5点です。10月23日にパピレスのニュース一覧を確認した時点で、21日より新しい発表は出ていませんでした。

停止画面が全パスで同じ503を返しRetry-Afterを付けていない状態

同じ10月23日の取得で、トップページと閲覧ページのURLはどちらも応答コード503と、同じ停止画面を返しました。最終更新日時のヘッダは10月21日13時50分（日本時間）で、再開までの目安を示すRetry-Afterヘッダは付いていませんでした。

サイト全体を1枚の静的ページに差し替えている状態で、購入済み作品の閲覧も止まっています。再開日が決まっていない段階でRetry-Afterを付けないのは、HTTPの仕様上も許される選択です（後述）。この状態から何を確かめて、どこから開けていくかが、運営側の次の工程になります。

「不正アクセスの可能性」の段階で全面停止する判断｜封じ込めと503応答の設計

NIST SP 800-61 Rev.3の封じ込め（RS.MI-01）と疑い時の停止判断

パピレスは侵害を確定する前の「可能性」の段階で、サービス全体を止めました。2025年4月に改訂されたNIST SP 800-61 Rev.3は、インシデント対応をCSF 2.0の項目に沿って整理しています。封じ込め（RS.MI-01）の注記では、封じ込めを「インシデントの拡大を防ぐこと」と説明し、ほとんどのインシデントは何らかの封じ込めを必要とすると書いています。

全面停止は売上を止めますが、侵入経路が分からない間に動かし続けると、会員DBへの被害が広がる余地を残します。電子書籍ストアは会員情報と決済をまとめて扱うため、経路が特定できるまで全体を止める判断は、被害拡大を防ぐための措置です。逆に、被害が特定の管理画面に限られると分かっているなら、その経路だけを塞げば足ります。

RFC 9110の503とRetry-Afterで停止中の応答を決める基準

RFC 9110の15.6.4は、503を「一時的な過負荷または予定されたメンテナンス」で処理できない状態を示すコードと定めています。同じ仕様の10.2.3によれば、503と一緒に送るRetry-Afterは、利用できない期間の見込みを秒数か日時で伝えるもので、付けるかどうかは任意です。

停止中に200で「メンテナンス中」を返すと、検索エンジンはその画面を本来のページの内容として扱うおそれがあります。Googleのクローラーに関する説明では、5xxを返すとクロールの頻度が下がり、エラーが続くURLはいずれインデックスから外れます。日数は示されていません。停止が1週間を超えそうなら、再開時に主要ページのクロールを促す準備も工程に入れておきます。

停止直後に証拠を残す｜ログの写しとSHA-256台帳をPythonで作る手順

RS.AN-07が求めるデータの完全性と来歴の保全を台帳で満たす方法

NIST SP 800-61 Rev.3のRS.AN-07は、インシデントのデータとメタデータを集め、その完全性と来歴（provenance）を保つことを求めています。復旧を急いでサーバーを作り直すと、侵入の痕跡が残るログやファイルが消えるおそれがあるためです。止めたらまず、触る前に写しを取り、取った時点の状態を後から証明できるようにします。

次のスクリプトは、指定したファイルを保全先にコピーし、元と写しのSHA-256を照合し、ファイルの大きさ・更新日時・取得日時と一緒にMANIFEST.csvへ書き出します。ハッシュの計算には、Python 3.11で入ったhashlib.file_digestを使う構成です。標準ライブラリだけで動き、preserve_evidence.pyとして保存します。

import csv, hashlib, os, shutil, sys
from datetime import datetime, timezone

# 使い方: python preserve_evidence.py collect <保全先> <対象ファイル...>
#         python preserve_evidence.py verify  <保全先>
def sha256(path):
    with open(path, "rb") as f:
        return hashlib.file_digest(f, "sha256").hexdigest()

def collect(dest, sources):
    os.makedirs(dest, exist_ok=False)          # 既存の保全先には上書きしない
    rows = []
    for src in sources:
        before = sha256(src)
        st = os.stat(src)
        copied = os.path.join(dest, os.path.basename(src))
        shutil.copy2(src, copied)              # 更新日時も写す
        after = sha256(copied)
        rows.append({
            "file": os.path.basename(src),
            "source": os.path.abspath(src),
            "bytes": st.st_size,
            "mtime_utc": datetime.fromtimestamp(st.st_mtime, timezone.utc).isoformat(),
            "collected_utc": datetime.now(timezone.utc).isoformat(timespec="seconds"),
            "sha256": after,
            "copy_ok": before == after,
        })
        os.chmod(copied, 0o444)                # 写しは読み取り専用にする
    with open(os.path.join(dest, "MANIFEST.csv"), "w", newline="", encoding="utf-8") as f:
        w = csv.DictWriter(f, fieldnames=rows[0].keys())
        w.writeheader()
        w.writerows(rows)
    for r in rows:
        print(f'{r["file"]:16} {r["bytes"]:>10} bytes  {r["sha256"][:16]}...  copy_ok={r["copy_ok"]}')

def verify(dest):
    bad = 0
    with open(os.path.join(dest, "MANIFEST.csv"), encoding="utf-8") as f:
        for r in csv.DictReader(f):
            ok = sha256(os.path.join(dest, r["file"])) == r["sha256"]
            bad += not ok
            print(f'{r["file"]:16} {"OK" if ok else "MISMATCH"}')
    sys.exit(1 if bad else 0)

if __name__ == "__main__":
    if sys.argv[1] == "collect":
        collect(sys.argv[2], sys.argv[3:])
    else:
        verify(sys.argv[2])

保全スクリプトの実行結果とSHA-256で写しの改ざんを検出する手順

2026年10月23日に、Python 3.14.7で架空のログ3本（アクセスログ50,000行、アプリログ20,000行、認証ログ8,000行）を保全しました。

$ python preserve_evidence.py collect evidence_20261023 var/log/access.log var/log/app.log var/log/auth.log
access.log          4318647 bytes  283e4b62c0620ecc...  copy_ok=True
app.log             1155476 bytes  6ff2a92edc993861...  copy_ok=True
auth.log             456600 bytes  c835ee573c3f06c0...  copy_ok=True
$ python preserve_evidence.py verify evidence_20261023
access.log       OK
app.log          OK
auth.log         OK
$ echo $?
0

3本ともcopy_ok=Trueで、元と写しのハッシュが一致しました。保全先がすでにある場合はエラーで止まるので、前回の証拠を上書きすることもありません。続けて、写しのapp.logに1行足してから照合すると、そのファイルだけがMISMATCHになり、終了コード1が返りました。写しを調査会社に渡す前と受け取った後に照合すれば、途中で中身が変わっていないことを示せます。

ログ以外に残す証拠とフォレンジック調査会社へ渡す前の操作上の注意

このスクリプトが扱うのは、ディスク上のファイルだけです。メモリ上のプロセス、ネットワーク接続の状態、クラウドの監査ログやロードバランサーのアクセスログは別に取ります。特にクラウドのログは保持期間が切れると消えるので、停止の当日に保管先へ書き出す設定を確かめてください。

サーバーの再起動、アカウントの削除、ウイルス対策ソフトによる自動の駆除も、痕跡を消す操作です。調査会社に頼むかどうかを決めるまでは、こうした操作を控えてください。調査の流れと費用はフォレンジック調査とは、平時に用意しておくものはデジタルフォレンジックとはで解説しています。ログを改ざんされない場所へ集めておく構成はFluentdで監査ログ基盤を作るが参考になります。

購入済み作品の閲覧から戻す段階的再開｜503ゲートをWSGIで実装する例

RC.RP-03とRC.RP-05に沿った復元前の検証と再開の順番

NIST SP 800-61 Rev.3は、復旧について2つの項目を置いています。RC.RP-03は、復元に使うバックアップなどを、使う前に侵害の痕跡や破損がないか確かめること。RC.RP-05は、復元した資産の完全性を確かめ、根本原因を取り除いてから本番で使うことです。

電子書籍ストアなら、戻す順番は「購入済み作品の閲覧」「ストアの閲覧」「購入と決済」が自然です。閲覧は会員がすでに払った対価にあたり、止まっている間の不満が最も大きい機能です。一方で決済は、侵入経路が塞がったと確かめるまで開けません。コミックシーモアも、購入済書籍のWEB閲覧から順次再開する準備をしていると発表していました。

段階ごとに通すパスを切り替えて残りに503とRetry-Afterを返すゲート

次のコードは、アプリの手前に置くWSGIのミドルウェアです。環境変数REOPEN_PHASEで段階を切り替え、その段階で開けるパスだけを通し、それ以外には503とRetry-Afterを返す仕組みです。検証担当のIPアドレスは、停止中でもすべてのパスを通します。Python標準のwsgirefで動作を確かめられる構成です。maintenance_gate.pyとして保存します。

import os
from wsgiref.util import setup_testing_defaults

# 再開段階ごとに通すパス（段階は環境変数 REOPEN_PHASE で切り替える）
PHASES = {
    0: (),                                   # 全面停止
    1: ("/login", "/mypage/", "/viewer/"),   # 購入済み作品の閲覧だけ
    2: ("/login", "/mypage/", "/viewer/", "/store/"),
    3: ("/",),                               # 購入・決済まで全面再開
}
STAFF_IPS = {"203.0.113.10"}                 # 検証担当は停止中も通す
RETRY_AFTER = "3600"                         # 秒数。日時が決まったらHTTP-dateにする

def gate(app):
    def wrapped(environ, start_response):
        phase = int(os.environ.get("REOPEN_PHASE", "0"))
        path = environ.get("PATH_INFO", "/")
        ip = environ.get("REMOTE_ADDR", "")
        if ip in STAFF_IPS or path.startswith(PHASES[phase]):
            return app(environ, start_response)
        body = "メンテナンス中です。再開状況はコーポレートサイトでお知らせします。".encode()
        start_response("503 Service Unavailable", [
            ("Content-Type", "text/plain; charset=utf-8"),
            ("Retry-After", RETRY_AFTER),
            ("Cache-Control", "no-store"),
        ])
        return [body]
    return wrapped

def store_app(environ, start_response):
    start_response("200 OK", [("Content-Type", "text/plain")])
    return [b"ok"]

app = gate(store_app)

if __name__ == "__main__":
    for phase in ("0", "1", "3"):
        os.environ["REOPEN_PHASE"] = phase
        for ip, path in [("198.51.100.7", "/viewer/123"), ("198.51.100.7", "/cart/checkout"),
                         ("203.0.113.10", "/cart/checkout")]:
            env = {"PATH_INFO": path, "REMOTE_ADDR": ip}
            setup_testing_defaults(env)
            res = {}
            app(env, lambda s, h: res.update(status=s, headers=dict(h)))
            print(f'phase={phase} {ip:13} {path:15} {res["status"][:3]} {res["headers"].get("Retry-After", "-")}')

2026年10月23日に、Python 3.14.7で実行した結果です。段階0では一般の利用者はすべて503、段階1では閲覧だけが通って決済は503のまま、段階3で全面再開になります。検証担当の203.0.113.10は、どの段階でも決済まで通りました。

$ python maintenance_gate.py
phase=0 198.51.100.7  /viewer/123     503 3600
phase=0 198.51.100.7  /cart/checkout  503 3600
phase=0 203.0.113.10  /cart/checkout  200 -
phase=1 198.51.100.7  /viewer/123     200 -
phase=1 198.51.100.7  /cart/checkout  503 3600
phase=1 203.0.113.10  /cart/checkout  200 -
phase=3 198.51.100.7  /viewer/123     200 -
phase=3 198.51.100.7  /cart/checkout  200 -
phase=3 203.0.113.10  /cart/checkout  200 -

ロードバランサー配下で送信元IPとキャッシュを扱うときの注意点

ロードバランサーやCDNの後ろに置くと、REMOTE_ADDRには利用者ではなく中継機器のアドレスが入ります。その場合はX-Forwarded-Forの値を使いますが、利用者が自由に書き換えられるヘッダなので、信頼できる中継機器が付けた末尾の値だけを読む作りにしてください。

503の応答にCache-Control: no-storeを付けているのは、CDNが停止画面を覚えて、再開後も返し続ける事故を防ぐためです。段階を進めるときは、開けたパスにだけ利用者を通し、ログでエラー率と不審なアクセスを1日ほど見てから次の段階に移ります。APIの認可とトークン失効の点検はAPI不正アクセス対策の実装手順で扱いました。

侵害の疑いで全面停止すべき事業者と部分遮断で足りる事業者の線引き

会員DBと決済を同じシステムで持ち侵入経路がまだ分からない事業者

会員情報と決済の処理が同じシステムにあり、侵入経路がまだ特定できていないなら、全面停止を選びます。売上の損失は日数で見積もれますが、会員情報が広く漏れたときの損失は見積もれません。止める判断を誰が下すか、停止画面とRetry-Afterの文言を誰が決めるかを、平時に決めておいてください。

不正アクセスによる漏えいの「おそれ」の段階でも、個人情報保護委員会への報告の対象になります。人数にかかわらず、速報はおおむね3〜5日以内、確報は60日以内です。段取りは個人情報保護委員会への報告義務、様式は個人情報保護委員会の「漏えい等の対応とお役立ち資料」にあります。止めた後に侵入経路を第三者の目で確かめたいときは、脆弱性診断・セキュリティ診断で、公開しているサーバーと管理画面の弱点を再開前に点検できます。

被害が管理画面や一部APIに限られ会員DBと経路が分かれている事業者

侵入の痕跡が特定の管理画面や1本のAPIに限られ、会員DBへの経路がネットワークで分かれていると確かめられたなら、全面停止は過剰です。その経路だけを遮断し、利用者向けの機能は動かしたまま調査を進めます。ランサムウェアで事務系のNASが暗号化された例では、業務系を切り分けて4日で業務を再開しています（佐賀大学のランサムウェア被害）。

ただし「分かれているはず」は判断の材料になりません。ネットワーク構成図ではなく、実際の通信ログで経路がないことを確かめてから部分遮断を選んでください。暗号化型の攻撃を受けたときの初動はランサムウェアの初動対応で整理しています。

よくある質問

Renta!の停止について、会員と会員サービスを運営する担当者から出やすい質問をまとめました。

Renta!はいつ再開しますか？

10月21日のパピレスの発表では、再開時期は未定です。10月23日に当社が確認した時点でも、新しい発表は出ていません。調査結果や再開時期が分かった時点で速やかに公表するとしているので、パピレスのコーポレートサイトのニュースで確かめてください。SNSの転載や、再開をうたうメールのリンクは頼らないのが安全です。

Renta!で個人情報は流出しましたか？

10月21日時点で、会員情報が流出したという発表も、流出していないという発表もありません。影響範囲は精査中とされています。流出が確認された場合は続報で知らされるはずです。それまでは、同じメールアドレスとパスワードを使っている他社サービスの変更を先に済ませておくと、どちらの結果になっても困りません。

停止中に期限が切れたレンタル作品はどうなりますか？

停止画面には、メンテナンス期間中に閲覧できなかったレンタル作品について別途対応を検討すると書かれています。延長、返金、ポイントのどれになるか、申請が要るかはまだ決まっていません。対応が発表されたときに照合できるよう、借りていた作品の名前と借りた日時を控えておくと確実です。

Renta!の停止はコミックシーモアの不正アクセスと関係がありますか？

同じ時期に止まった電子書籍ストアですが、両者の関係を示す公式発表はありません。コミックシーモアは10月15日に停止し、16日に会員情報の流出を公表しました。Renta!は10月18日に不正アクセスの可能性を把握したとしていますが、手口や侵入経路は公表されていません。同じ攻撃者と決めつける根拠は今のところありません。

自社のサービスで侵害が疑われたら、最初に何をすればよいですか？

止めるかどうかを決める前に、止めた後に消えるものを書き出します。ログ、クラウドの監査ログ、メモリ上の情報です。止めると決めたら、503の停止画面に切り替え、ログの写しとハッシュの台帳を取り、再起動やアカウント削除は調査の方針が決まるまで控えます。個人情報の漏えいのおそれがあれば、速報の期限も同時に数え始めます。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.07.21　テックブログ Apache Tomcatの脆弱性一覧【2026年10月】最新版11.0.27・10.1.61・9.0.123とCVE-2026-59083ほかの影響確認・対応手順
  2. 2026.10.21　テックブログ NEC委託先の不正アクセスとは｜顧客システム暗号化・情報漏えいの経緯と委託元が点検する正規アカウント
  3. 2026.10.21　テックブログ ふるさとチョイス不正アクセスで445万件流出：対象確認・パスワード変更と再開時期
  4. 2026.10.22　テックブログ Tomcatバージョン一覧とサポート期限【2026年10月】9.0系は2027年3月末で終了・9.1系と11.0系への移行判断
  5. 2024.07.05　コラム XAMPPの脆弱性とは？危険性とCVE-2024-4577への対策をわかりやすく解説【2026年10月】

RELATED POSTS 関連記事

一覧へ戻る

目次