はぐれSE

はぐれSEは、アプリ開発やコンサルをやってるシステムエンジニアです。『脆弱性はどこにある?』をテーマにWebアプリケーションのセキュリティについてつぶやきます。C#、Android-Java、Unity、アーキテクチャ、フレームワーク、オブジェクト指向、Webアプリケーションセキュリティ、脆弱性診断、Fiddler

[セカヤサ@AI×Web制作💻小林 秀樹 @hideki_climax]

【PHPセキュリティ問題　時系列順まとめ】

今回のPHPの事案を時系列順にまとめてみました。

----
2024年：PHPの潜在的な脆弱性を発見
外部監査をきっかけにメモリ管理の問題を認識。
しかし、修正方針がまとまらず約2年間対応が停滞。

↓

2026年8月：重大な任意コード実行リスクが判明
Calif（セキュリティ企業）やOpenAIなどが、認証なしで任意コード実行（RCE）が可能な攻撃経路を報告。
PHP開発チームが修正を最優先で進める。

↓

10月21日 0時頃：脆弱性情報が事前流出
修正パッチ公開前に、2件のCVE番号がHacker Newsへ投稿され、←何してんの
それがSNSや掲示板にも拡散。

※この時点では技術的な詳細は含まれていなかった。

↓

10月21日 4時30分：PHP公式が緊急告知
情報流出を受け、パッチ公開予定を22日から21日23時（日本時間）へ前倒し。

↓

10月21日 5時頃：攻撃実証動画が誤公開
Califが攻撃の動作動画を誤って公開。←最高にカス、バカ

すぐに削除されたものの複製が拡散し、攻撃コードの開発が加速。

↓

10月21日：研究者らによる未検証情報が拡散
パッチ公開前に、@ J4ck3LSyN などによって脆弱性の原因や再現方法をSNSなどで発信する動きが発生。←余計なことをするな

↓

10月21日 16時41分：修正済みバイナリを先行公開
Chainguard（セキュリティを専門とする米国企業）が公開予定の約6時間前に修正済みコンテナイメージを配布。←最大最悪のカス、超絶ルール違反

これにより攻撃者によるパッチの差分解析が可能な状態に。

※PHP Foundationもこれを一方的なエンバーゴ違反（事前に取り決めた情報の公開禁止期間を守らないこと）と明言しています。

↓

10月21日：国内外でサービスの緊急停止が相次ぐ
修正パッチがまだ提供されていないため、国内外のWebサービスや政府機関が予防措置として一時停止・メンテナンスを実施。

↓

10月21日 23時頃：PHP公式が修正版を公開
CVE-2026-109618、CVE-2026-109619への修正を含むPHP 8.2〜8.5の更新版を公開。

↓

10月22日：情報流出と管理体制の問題が焦点に
PHP Foundationが、2024年からの修正停滞を組織的な失敗と認める。協調的な脆弱性開示が崩れた経緯も問題視される。

----

【結論】人災。

特に、
⚠️ Califが攻撃の動作動画を誤って公開したこと
⚠️ Chainguardの勝手な判断による修正済みバイナリを含むコンテナイメージの公開
が最悪。終わってます。

[オカダリョウタロウ @okdt]

PHP2Shell 着弾発見ガイド（実務反映版）出すよー

■ error.log
```
zgrep -HnEi 'Allowed memory size.*exhausted|Unknown on line 0|Out of memory|SIGSEGV|Segmentation fault|zend_mm_heap corrupted|exited on signal 11' error.log*
```

■ access.log

```
# 5xxを返したPOSTをIPごとに集計（パスで絞らない）
zgrep -HnE 'POST ' access.log* | grep -E ' (500|502|503) ' | awk '{print $1}' | sort | uniq -c | sort -nr
```

■ ポイント
・発火がアプリより前なので、パスで絞らない方が漏れにくい
・標準ログの大きい数字は「応答サイズ」。リクエストサイズは %I や $request_length を足さないと残らない
・暫定で memory_limit=-1 にした環境では "Out of memory" も検索対象
・ここで見えるのは「試行」まで。着弾確認は以下も見る

■ 着弾確認

```
# php-fpm / apache2 からシェルが起動していないか
ps aux | grep -E 'php-fpm|apache2|httpd' | grep -v grep

# Webルートに新しい .php が増えていないか
find /var/www /www /srv -name '*.php' -mtime -1 2>/dev/null
```

#PHP2Shell

[Hazy @kawada_syogo225]

遅くなりましたが、昨日の「しろおびセキュリティ」さんでお話ししたクラウドセキュリティの資料を公開しました。

改めて、素敵な会場と発表の機会を頂いた皆様に心より感謝申し上げます。

#shirosec

https://t.co/LppMXVKt5o

[はぐれSE @hagurese]

25年くらい前に0から書いたのを思い出した。情報処理やアルゴリズムの本質に迫る良問だと思います。

ねえパパ、ほとんどのエンジニアは四則演算を計算するプログラムすら書けないってホント？｜hiroyahorai https://t.co/5hyyML0mVZ #zenn

[はぐれSE @hagurese]

GitHub Copilotを使ってAIコーディングをしているとコード生成の過程でマルチエージェントで動作している様を見ることが出来ます。まるで映画スター・ウォーズに出てくるC-3POとR2-D2みたいでカワイイなと思いつつ、SFの世界が現実になっている事例に感心しています。

[gohan 🍚⛩️ @grandchildrice]

セキュリティの未来について最近考えていることを記事にしました

ソフトウェア監査
ペネトレーションテスト
バグバウンティ

などの既存の業界構造は変革を余儀なくされます

ここでは問いを提起しているので、いつか解決策は何だったのか答え合わせしましょう

https://t.co/MHSEFGAOne

[はぐれSE @hagurese]

AIコーティングは始めたばかりだけど、既に共感できます。構造をあらかじめ伝える、小さな増築でもレビューしリファクタリングする、テストケースも同時にメンテする位しておかないと直ぐにモンスターコードになりそうな危機感があります。
https://t.co/IsIL4mlRVn

[はぐれSE @hagurese]

つまるところAIコーティングで人間に必要なのは、システムの設計を描ける、コードをレビューできる、ケースを網羅できる程ドメインを理解していることだと感じました。AIによってエンジニアの仕事が奪われるという話はこの辺りが解決の要になりそうです。

[はぐれSE @hagurese]

今更かもしれませんが、AIコーティングを始めてみました。がんがんコードを書いてくれますね。指示の文脈もある程度理解してくれます。こちらがしっかり仕様と構造を定義する、適切な言葉で指示する、できたコードには直ぐに目を通す位でよい感じになりそうな予感です。

[はぐれSE @hagurese]

AIコーティングで構造に関する指示をしないと、あまり読みたくないコードになりがちな印象です。不具合を特定する、抜けケースを把握するには手早くコードを読みたいので、しっかり構造を指示したほうがいいと思いました。拡張性を盛り込みたい場合は構造の骨格だけ書いて渡すとよい感じでした。

[Koichi @x64koichi]

いまGithubで多数のリポジトリに対して展開されている不正なコードの挿入は、手口が非常に斬新です。一見、１行の短い難読化コードのように見えますが、実はs(``)の中に見えないUnicodeのデータが格納されてます。メモ帳に張り付けると18,250桁！この見えないデータをコードに変換して実行してます。しかも、そのコードの中でSolanaの特定アドレスへアクセスして追加コードも取得してます。EtherHiding！

[NCO国家サイバー統括室 @cas_cyberpr]

【サイバーセキュリティ人材フレームワーク（案）のご意見募集】
サイバー人材の役割・技能を体系化し、人材育成・確保の共通指針を目指します。
活用に向けた手引きも作成中です。ぜひご意見をお寄せください。
▼詳細（e-GOVへ）
https://t.co/Kn6VEjc468

[Sen Ueno @sen_u]

SecBoK 改訂委員会のメンバーとして携わった「セキュリティ知識分野（SecBoK）人材スキルマップ2025年版」がJNSAより公開されました。
SecBoK は情報セキュリティに関する知識項目を体系化したフレームワークで、セキュリティ人材に求められる知識・技能を整理・可視化したものです。
https://t.co/aTrPzeTeKv

[piyokango @piyokango]

サイバー攻撃による個人情報表示不具合およびサイト停止・復旧に関するお知らせ
2025年12月30日
五次元株式会社
https://t.co/5kmKQ0iCtG

『このたび発生いたしましたサイバー攻撃につきましては、関係各所と連携のうえ対応を進め、攻撃への対処および必要な安全対策をすべて完了いたしました。
その結果、2025年12月30日17時頃にサーバーを再開し、現在は通常通りサイトをご利用いただける状態となっております。
本お知らせでは、本件の発生経緯、影響範囲、原因および当社の対応内容について、改めてご報告いたします。

■ 経緯説明
2025年12月27日20時より、数量限定の福袋販売を開始いたしましたが、事前に販売開始時刻を告知していたこともあり、福袋販売開始と同時にアクセスが集中し、サーバー負荷が最大となったタイミングを狙った悪質なサイバー攻撃を受けました。
本件は、サイバー攻撃の影響によりシステム内の一部データに不整合が発生し、データの整合性が損なわれる事象が確認されました。
その結果、12月27日20時以降、一部のお客様において、ご注文手続き中に他のお客様の氏名・住所、ならびにクレジットカード情報の一部が誤って表示される事象が発生しました。
お客様からのご報告を受け、当社では事態の重大性を鑑み、同日20時30分頃にサーバーを緊急停止し、被害拡大防止を最優先として調査および確認作業を開始いたしました。

■ 影響範囲について
2025年12月27日20時からサーバー停止までの間に、当サイトへログイン・ご利用されたお客様につきましては、
氏名、住所、またはクレジットカード情報の一部が同時にログイン中のお客様同士に表示された可能性がございます。
なお、クレジットカード情報につきましては、決済時に表示されるのは下4桁のみであり、セキュリティコードはサーバー上に保存されておらず取得不可能な仕様となっております。
そのため、当該情報のみでクレジットカードを不正利用することは極めて困難であると認識しております。
本公告掲載時点において、当サイトをご利用されたお客様から、12月27日20時以降にクレジットカードの不正利用が発生したことは確認されておりません。

■ 原因究明および対応状況
2025年12月30日までに、不正アクセスの侵入経路および攻撃手法の特定が完了し、攻撃により注入された不正データの完全除去を実施いたしました。
あわせて、サイト全体のセキュリティ対策を見直し、防御強化のための改修およびネットワークセキュリティ対策を新たに導入しております。
今後、お客様により安全にご利用いただくため、以下の変更を行う予定です。
・クレジットカード情報に関わるすべてのデータを暗号化管理
・マイページにおけるログイン関連情報の暗号化
・サーバー監視および防御体制の強化
また、今回の件では福袋販売時刻を事前に大きく告知していたことが、結果として攻撃の標的となる要因の一つとなりました。
今後の福袋販売につきましては、同様の事態を防止するため、SNS（X等）での大幅な事前告知は控える方針といたします。

■ サイト再開について
本件では、攻撃者が意図的にサーバー負荷が最も高い時間帯を狙い、個人情報の表示不具合を引き起こすことで、当サイトの信用を失墜させることを目的としたものと考えております。
被害拡大を防ぐため、やむを得ずサーバーを一時停止いたしましたが、その間、原因・経緯・影響・対応状況については随時お知らせしてまいりました。
修復・点検・再発防止対策を重ね、安全性に問題がないことを再三確認したうえで、12月30日にサイトを再開いたしました。

■ お詫びと今後について
このたびの件では、当社のセキュリティ対策および、混乱時における情報発信の迅速さに不足があったことを深く反省しております。
今後は、セキュリティ体制のさらなる強化とともに、万一の際にもより迅速かつ的確な情報提供が行えるよう、運用体制の改善に努めてまいります。
お客様には多大なるご不安とご迷惑をおかけしましたことを、心より深くお詫び申し上げます。
引き続き、何卒ご理解とご支援を賜りますようお願い申し上げます。』
（一部抜粋）#incident

[yousukezan @yousukezan]

NIST SP 800-63Bにおけるワンタイムパスワード（OTP）・多要素認証（MFA）の要件

* 基本方針
二つ以上の異なる要素（知識・所持・生体）を組み合わせて認証。
AAL2以上では多要素認証が推奨／必須。

* OTP関連要件
有効期間：短時間（例：30〜60秒）で失効すること。
再利用禁止：一度使ったOTPは再利用不可。

* 生成・検証
検証側（サーバー）は、再生攻撃を防ぐために過去のOTPを保存・拒否。
OTP生成器と検証者の**同期（時間またはカウンタ）**を維持すること。

* 送信チャネル
外部チャネル（例：SMS, 電話, プッシュ通知）を使う場合：
主チャネルと副チャネルを明確に分離。
通信は暗号化または認証済みチャネル上で行うこと。
可能であればSMSではなくアプリ内プッシュ方式を推奨。

* 多要素認証（MFA）要件
各要素は独立して機能し、片方の侵害が他方に影響しないこと。
MFAは以下のいずれかの組み合わせで構成可能：
パスワード + OTP
パスワード + ハードウェアトークン
生体認証 + 所持要素 など
AAL3では、公開鍵暗号ベースのフィッシング耐性認証（例：FIDO2, PIV, CAC）が必須。

[yousukezan @yousukezan]

NIST SP 800-63Bにおける「パスワード（Passwords）」の要件

* 基本方針
パスワードは「記憶された秘密（memorized secret）」として認証装置の一種とみなされる。パスワードの複雑性よりも「既知の弱いパスワードの排除」と「長さの確保」を重視。

* 最小長
単要素認証のみで使う場合：15文字以上
多要素認証の一要素として使う場合：8文字以上

* 禁止パスワードリスト
既知の漏洩済みパスワード
一般的な辞書語、簡単な連番、サービス名やユーザー名を含むもの

* 複雑性ルール
特定の文字種（大文字・数字・記号）の強制は推奨されない。

* 変更ポリシー
定期的なパスワード変更の強制は禁止。→ ただし、漏洩・侵害の疑いがある場合は変更を求める。

* 入力支援
貼り付け・パスワードマネージャーの使用を許可すべき。
入力中のパスワード表示（「表示」ボタン）は許可してよい。

* 保存
サーバー側ではソルト付きハッシュ（例：PBKDF2, bcrypt, scrypt, Argon2）で保護。

* ログイン試行
推測攻撃対策としてレート制限（throttling）を実装する。

* リカバリー
「秘密の質問」は非推奨。安全な再発行プロセスを使用。
https://t.co/4aoKPoPtm3

[はぐれSE @hagurese]

技術の発展によりAIが人間の知能を上回る転換点をシンギュラリティと呼ぶそうですが、過度な技術依存などにより人間の知能がAIを下回るといった事態が生じた場合も同じくシンギュラリティと呼ぶのか、三連休の終わりに気になった次第です。

[Sen Ueno @sen_u]

独立行政法人情報処理推進機構 産業サイバーセキュリティセンター 中核人材育成プログラムから「脆弱性診断内製化ガイド」が公開されています。
https://t.co/NX27JX5XEI