ココナラは2026年10月9日、スキルマーケットが不正アクセスを受け、会員が登録した履歴書449件と職務経歴書関連書類1,845件が外部に持ち出されたと公表しました。クレジットカード情報とパスワードは対象外です。本記事では公式発表の文言をもとに、届いた連絡が本物か、自分が対象に入るか、パスワード変更が必要かを先に答えます。後半では、履歴書のような書類をアップロードで受け取るサービス向けに、所有者を確かめてから短時間だけ有効なURLを発行するコードと、保存先の公開を止める設定を示します。
まとめ：ココナラの不正アクセスで確定した事実と会員がいま確かめること
確定しているのは、10月8日の2時05分に最初の不正アクセスを検知して遮断したものの、13時頃に再び侵入され、15時頃に個人情報の持ち出しの形跡が見つかったことです。15時44分に攻撃経路を遮断し、21時27分までに脆弱性の修正を終えています。原因は「対象システムの脆弱性」とだけ書かれ、種類や製品名は出ていません。
会員がやることは多くありません。対象者には個別に連絡が届くため、その連絡がパスワードやカード番号を聞いてきたら偽物と判断します。ココナラは本件でそれらを聞かないと明言しています。履歴書や職務経歴書を登録していない会員は対象外です。
| 項目 | 公表されている内容 |
|---|---|
| 公表日 | 2026年10月9日 |
| 対象サービス | ココナラスキルマーケット |
| 対象者 | 履歴書・職務経歴書を登録した会員の一部 |
| 件数 | 履歴書449件、職務経歴書関連書類1,845件 |
| 対象外 | クレジットカード情報、各種パスワード |
| 原因 | 対象システムの脆弱性（詳細は非公表） |
| サービス | 対策を講じたうえで提供を継続 |
届いた連絡は本物か・自分は対象かを確かめる｜ココナラ会員の確認手順
ココナラから届く個別連絡の見分け方と公式が聞かないと明言した情報
ココナラの公表文は、情報を精査したうえで対象者へ順次個別に連絡すると書いています。同じ文面は会員向けのニュースページにも掲載されている内容です。そのうえで、本件に関してメール、SMS、電話でパスワード、クレジットカード情報その他の認証情報そのものを聞くことはないと明記しています。
判断の線は単純です。連絡の中でパスワード、カード番号、ログイン用のコードの入力を求められたら、ココナラ名義でも偽物として扱ってください。リンクを開かずに、ブラウザからcoconala.comへ自分で入り、ログイン後の画面やお知らせで内容を照合します。
履歴書・職務経歴書を登録していない会員と他サービス利用者の扱い
対象者は「スキルマーケットに履歴書・職務経歴書を登録された会員様の一部」です。登録していない会員は、公表上は対象に入りません。登録していた会員も全員ではなく、一部とされています。
エージェント事業をはじめ、スキルマーケット以外のココナラのサービスやサイトには影響がないとも書かれています。ココナラアシストやココナラテックなどエージェント経由で仕事を受けている人は、スキルマーケット側で書類を登録していなければ対象外と読めます。迷う場合は、公表文が案内する相談窓口（coconala.com/inquiryのチャット）で確かめるのが確実です。
パスワード変更とカード停止が必要かを公表内容から判断する基準
公表文は、クレジットカード情報と各種パスワードは今回の不正アクセスの対象になっていないことを確認したと書いています。この記載に従えば、カードの停止や再発行は不要です。ココナラのパスワードも、本件を理由に変える必要はありません。
ただし、ほかのサービスと同じパスワードを使い回している人は、この機会に分けておく価値があります。本件とは別の漏えいで同じ組み合わせが出回っていれば、被害はそちらから起きます。カードの利用明細を月に一度見る習慣も、費用ゼロの保険として残しておくとよいでしょう。
公表内容を時系列で読む｜10月8日の初回遮断から再侵入と修正完了まで
2時05分の遮断から13時の再検知までの約11時間で起きていたこと
時系列で目を引くのは、最初の遮断から約11時間後に再び侵入されている点です。2時05分に不正なアクセスを検知して遮断し、13時頃に再度検知、15時頃に持ち出しの形跡を確認、15時44分に攻撃経路を遮断しました。脆弱性の再検査とセキュリティ強化の措置は21時27分です。
公表文から読み取れるのは、初回の遮断では再侵入を止められず、脆弱性の修正まで入口が残っていたという順序です。接続元の遮断と脆弱性の修正は別の作業で、前者だけでは同じ穴を別の経路から突かれます。どんな脆弱性だったかは書かれていないため、本記事では特定の攻撃手法には結び付けません。
履歴書449件と職務経歴書関連書類1,845件が書類の件数である意味
公表された数字は書類の件数で、人数ではありません。1人が履歴書と職務経歴書の両方を登録していれば2件以上に数えられるため、影響を受けた人数は合計の2,294件より少ない可能性があります。人数は公表されていません。
書類に含まれていた項目の内訳も示されていません。一般的な履歴書の様式には氏名、生年月日、住所、電話番号、メールアドレス、学歴、職歴が並び、顔写真を貼る欄もあります。登録していた書類に何を書いたかを、自分の手元の原本で確かめておくと、次の章の悪用パターンに当てはめやすくなります。
10月21日夜の臨時メンテナンスと本件の関係について書けること
ココナラは10月22日に臨時メンテナンス完了の連絡を出しています。10月21日22時20分から10月22日6時35分まで、Webとアプリを対象に、サービスの安全性を守るための予防的措置として実施したという内容です。
この告知には、メンテナンスに起因する不正アクセスや情報流出は確認されていないと書かれています。10月9日の件との関係は記載がありません。続報として扱える情報ではないため、10月23日時点では10月9日の公表文が唯一の一次情報です。
履歴書が外に出た場合の悪用パターン｜採用連絡を装う詐欺と相談先
氏名・連絡先・職歴がそろう書類が採用連絡を装う詐欺に使われる流れ
履歴書や職務経歴書は、名簿とは違って職歴や希望条件まで書かれています。その人だけに向けた文面を作る材料がそろっているのが特徴です。想定しやすいのは、登録していた職種や経歴に触れた「案件の打診」「面談の日程調整」を装う連絡で、外部のフォームへ誘導して本人確認書類や口座情報を入力させる手口です。
公表文も、身に覚えのない連絡に記載されたURLへのアクセスや、個人情報の入力をしないよう求めています。経歴に触れているから本物、とは判断しないでください。同じ時期に公表されたバイトルの不正アクセスでも、求人サービスの会員を狙う不審メールへの対処が論点になっています。
流出後に会員が残しておく不審な連絡の記録と被害に応じた相談窓口の使い分け
不審な連絡が届いたら、削除する前に記録を残します。メールなら送信元アドレスと受信日時、SMSなら送信元番号と本文の画面です。実害が出たときに、警察や消費生活センターへ相談する材料になります。
ココナラ本体への問い合わせは、公表文が案内する相談窓口のチャットを使います。口座やカードの情報を入力してしまった場合は、ココナラより先に、その金融機関やカード会社へ連絡して止めてください。順番を逆にすると、その間に引き出されるおそれがあります。
アップロード書類の保管設計｜所有者チェック付き署名付きURLの実装手順
書類のURLや番号を知っていれば開ける設計が漏えいを広げる理由
ここからは、履歴書や本人確認書類をアップロードで受け取るサービスを作る側の話です。本件の原因は公表されていないため、以下は同種の機能で一般に押さえるべき設計として読んでください。最も多い落とし穴は、書類のIDやファイル名さえ分かれば、誰の書類でも取り出せてしまう作りです。
OWASPのIDOR対策チートシートは、リクエストのたびに、そのユーザーが対象の物へアクセスしてよいかをサーバー側で確かめることを基本に置いています。IDを推測しにくくするのは補助で、確認の代わりにはなりません。認可の抜けを止める実装は認可バイパスとIDORの対策で詳しく扱っています。
boto3で所有者を確かめてから5分だけ有効なURLを発行するコード
書類をS3などの非公開ストレージに置き、閲覧のたびに短時間だけ有効なURLを発行する形にすると、URLが漏れても被害は時間で切れます。AWSの署名付きURLの説明では、有効期限はSDKやCLIで最長7日で、URLは期限まで何度でも使えるという説明です。次のコードはboto3のgenerate_presigned_urlを使い、所有者の確認を通った場合だけ300秒のURLを返します。
import boto3
from botocore.config import Config
BUCKET = "example-resume-store"
s3 = boto3.client("s3", region_name="ap-northeast-1",
config=Config(signature_version="s3v4"))
# 書類台帳の例（本番ではDBから引く）
DOCUMENTS = {
"d-7f3a": {"owner_id": "u-1001", "s3_key": "resumes/9b2e6c1d-4f.pdf"},
}
def issue_download_url(user_id, document_id):
doc = DOCUMENTS.get(document_id)
# 所有者でなければ「存在しない」と同じ扱いにする
if doc is None or doc["owner_id"] != user_id:
return None
return s3.generate_presigned_url(
"get_object",
Params={
"Bucket": BUCKET,
"Key": doc["s3_key"],
"ResponseContentDisposition": "attachment",
},
ExpiresIn=300,
)
print(issue_download_url("u-1001", "d-7f3a")) # URLが返る
print(issue_download_url("u-2002", "d-7f3a")) # None要点は三つの値の決め方です。ExpiresInは画面を開いてから表示するまでに足りる長さに絞り、ResponseContentDispositionでダウンロードとして返してブラウザ内での表示を避けます。S3のキーに使うのは、利用者の氏名や連番ではなく、ランダムな値です。他人の書類を指定された場合に403ではなく見つからない扱いで返すと、書類の存在そのものも隠せます。
S3のパブリックアクセスブロックと古い署名を拒否するバケットポリシー
署名付きURLで配る前提でも、バケット側の公開設定が緩ければ意味がありません。S3のパブリックアクセスブロックを四項目とも有効にし、ACLやバケットポリシーで公開されない状態に固定します。あわせて、署名から10分を超えたリクエストを拒否するポリシーを置くと、長い期限で発行してしまったURLも10分で止まります。
aws s3api put-public-access-block \
--bucket example-resume-store \
--public-access-block-configuration \
BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
cat > policy.json <<'EOF'
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyOldSignature",
"Effect": "Deny",
"Principal": {"AWS": "*"},
"Action": "s3:*",
"Resource": "arn:aws:s3:::example-resume-store/*",
"Condition": {"NumericGreaterThan": {"s3:signatureAge": "600000"}}
}]
}
EOF
aws s3api put-bucket-policy --bucket example-resume-store --policy file://policy.jsons3:signatureAgeはミリ秒で指定するため、600000が10分です。この条件はAWSの説明ページに例として載っている形をそのまま使っています。S3の権限設計を最初から組む場合は、S3のバケット作成から署名付きURLまでの手順も参考になります。
書類の保存先を本体のDBと分け、保有期間を決めて自動で消す運用
書類ファイルは会員情報のDBとは別のバケットに置き、Webアプリのサーバーには書類バケットへの読み取り権限を持たせない構成にします。URLの発行だけを担う小さなAPIに権限を寄せれば、Webアプリ側が乗っ取られても書類を一括で抜かれる経路が細くなります。
書類をいつまで残すか、保有期間も事前に決めておく運用です。応募や案件のやり取りが終わった書類を残し続ければ、漏えいしたときの件数がそのまま積み上がります。IPAの注意喚起でも、速やかに行う点検の一つは、保有する情報資産を把握して必要最小限にすることです。S3であればライフサイクルルールで、一定日数を過ぎた書類を自動で削除できます。
運営側に残る報告と点検の手順｜個人情報保護委員会とIPAの注意喚起
不正アクセスによる漏えいが件数に関係なく個人情報保護委員会への報告対象になる類型
個人情報保護委員会の案内では、報告の対象は要配慮個人情報、財産的被害のおそれがあるもの、不正の目的をもって行われたおそれがあるもの、本人の数が1,000人を超えるもの、の四類型です。不正アクセスによる漏えいは三つ目に当たるため、人数が少なくても報告の対象になります。
期限は速報が発覚から3〜5日以内、確報が30日以内で、不正の目的によるものは60日以内です。ココナラは公表文で、所轄警察署への通報と個人情報保護委員会など関係省庁への報告を行うとしています。報告書に書く項目や社内の段取りは個人情報保護委員会への報告義務の実務にまとめています。
IPAが10月9日に求めた外部公開アプリの精査と保有データの再点検
本件の公表と同じ10月9日、IPAは注意喚起を出しました。大量の個人情報を扱うオンラインサービスで侵入と窃取が相次いでいるとして、外部に公開しているアプリケーションの直近ログと未適用パッチの確認、利用している外部サービスの洗い出し、保有データの再点検を速やかに行うよう求めています。IPAは10月16日から不正アクセス特別相談窓口も開設しました。
書類アップロード機能を持つサービスなら、点検の順番は、書類を返すAPIの認可確認、保存先の公開設定、保有期間の三つです。ログの見方は不正アクセスの調べ方、API全体の対策はAPI不正アクセス対策の実装手順が使えます。社内だけで確かめきれない場合は、脆弱性診断・セキュリティ診断で、書類の受け取りから配信までの経路を含めて検査できます。
よくある質問
ココナラの不正アクセスについて、会員と開発者から出やすい質問をまとめました。
ココナラから自分が対象だという連絡がまだ届いていません。対象外ですか？
連絡がまだ届いていないだけで対象外とは言い切れません。公表文は、情報を精査したうえで対象者へ順次個別に連絡するとしています。履歴書や職務経歴書を登録していなかった場合は対象外です。登録していて不安な場合は、公表文にある相談窓口のチャットで確かめてください。届いた連絡がパスワードやカード番号の入力を求めてきたら、偽物として扱います。
ココナラのパスワードは変更したほうがよいですか？
公表文は、各種パスワードは今回の不正アクセスの対象になっていないことを確認したとしています。本件を理由にした変更は必須ではありません。ほかのサービスと同じパスワードを使っている場合は、別の漏えいへの備えとして分けておくと安全です。
ココナラは今も使えますか？
現在も利用できる状態です。ココナラは、外部からの不正アクセスへの対策を講じたうえでサービスの提供を続けるとしています。10月21日夜から22日朝にかけて予防的な臨時メンテナンスがありましたが、告知では、メンテナンスに起因する不正アクセスや情報流出は確認されていないとしています。
何人分の情報が流出したのですか？
人数は公表されていません。公表されているのは履歴書449件と職務経歴書関連書類1,845件という書類の件数です。1人が複数の書類を登録している場合があるため、人数は合計の2,294件より少ない可能性があります。原因の詳細や書類に含まれていた項目の内訳も、10月23日時点では出ていません。
書類アップロード機能を作るとき、最初に確かめることは何ですか？
最初は、書類を返すAPIが毎回ログイン中のユーザーと書類の所有者を照合しているかです。次に、保存先のバケットが公開されない設定になっているか、最後に不要になった書類を消す期限があるかを確かめます。配信は所有者確認を通った後に短時間だけ有効なURLで行うと、URLが漏れても被害が時間で切れます。
関連記事
- バイトル不正アクセス：388万件のメールアドレス漏えいの対象確認と不審メール対策：同時期に公表された求人系サービスの事例
- 認可バイパスとは？IDOR・権限昇格の仕組みとサーバ側で止める実装対策を解説：書類を他人に開かせない認可の実装
- AWS S3の使い方｜CLIでのバケット作成から権限設計・署名付きURLまでの実装手順：書類の保存先を組むときの手順
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：運営側が漏えい時に進める報告
- 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：アップロード機能の点検を外注するときの判断材料
