AI agent skills for PHP2Shell: what each one checks
PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a pair of flaws in PHP itself. The PHP project fixed them on 21 October 2026 in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 (php.net advisory).
Within two days, several teams published skills for coding and operations agents (Claude Code, Codex, Devin and others) that look for affected PHP and help update it. We read the skill files of the ones below. This post lists what each one inspects, how it decides whether a build has the fix, and whether it waits for your approval before it changes anything.
Disclosure: we run php2shell.fyi, a passive checker for PHP2Shell. None of the tools below is ours.
The question that matters most
Some Linux distributions ship the fix under the old version number. Ubuntu 24.04 has the fix in php8.3 8.3.6-0ubuntu0.24.04.13 (USN-8948-1). RHEL 9 has it in php-8.0.30-8.el9_8.1 (RHSA-2026:87151). Chainguard has it in 8.4.26-r4.
A tool that compares only the upstream number (8.3.6 is lower than 8.3.36) reports these fixed servers as vulnerable. An agent that trusts that answer may try to "fix" a server that is already fixed. So the first column we checked is: does the tool compare the full package version?
The skills
| Skill | Publisher | What it inspects | Full package version? | Changes |
|---|---|---|---|---|
| phpcheck-server | OpenAI | The PHP binary or Apache module that serves the site, its package, the OS, containers | Yes | Check only |
| phpcheck-url | OpenAI | The Server and X-Powered-By headers of one URL | No, and it says so | Check only |
| fix-php-vuln | Cognition | Repositories: Dockerfiles, CI, Helm, Terraform, Ansible, Chef, Puppet | Yes | Only after you pick the repos; then one pull request per repo |
| php2shell | Chainguard | Chainguard and Wolfi images, SBOMs, Kubernetes workloads | Yes (apk revisions) | Each change needs approval |
| php2shell-response | Iurii Rogulia (community) | Hosts, images, hosting accounts, repositories | Yes | Read-only unless you say otherwise |
What the skill files say, in their own words:
- OpenAI phpcheck-server: "Compare the full package revision against vendor guidance covering both CVEs. An older upstream version alone does not prove vulnerability." It also asks whether the web workers restarted after the update, and says: "Do not run exploit probes."
- OpenAI phpcheck-url: "HTTP headers cannot tell whether the version contains a backported fix." Use it for a first look, not for a verdict.
- Cognition fix-php-vuln: "Never compare php -v with upstream numbers to decide this." Discovery ends with: "Stop. Show the table and ask which repos to patch."
- Chainguard php2shell: "Every change needs the user's explicit approval first". It also warns: "Never compare version strings as text (-r10 is newer than -r4)".
- php2shell-response: "A distribution package may carry the fix under an older version number: check the vendor changelog or advisory, never compare version strings alone." Its mode: "Read-only unless the user says otherwise."
Tools that compare only the upstream number
These are useful, but read their "vulnerable" answer as a question, not a verdict, on Ubuntu, RHEL and Chainguard:
- The ProjectDiscovery Nuclei template for CVE-2026-109618. Its version fallback marks a patch number below the fixed one as vulnerable, so 8.3.6-0ubuntu0.24.04.13 counts as vulnerable. It also marks every version below 8.2 as end of life.
- The Assetnote scanner. When it sees no crash signal, it falls back to the X-Powered-By number with the same comparison.
- Some community skills compare versions with sort -V on the upstream number only.
Before you let an agent change a server
- Give it read access first, and ask for a table: runtime, path, version, package, status.
- Check that it reads the PHP that serves the site (PHP-FPM, the Apache module, LiteSpeed), not only php -v on the command line.
- Ask it to show the restart step. Old PHP processes keep the old code until they stop. ps -eo pid,lstart,cmd | grep -i '[p]hp' shows when each one started.
- Do not let it fetch or run public proof-of-concept code. Most public PHP2Shell "PoC" repositories are attack tools, and their code is not reviewed.
We keep a read-first prompt, our own SKILL.md and this comparison up to date on php2shell.fyi. The fixed releases, the distribution builds and the mitigations are on php2shell.fyi, with a source for each fact.
Mentions
「悪用の報告なし」の脆弱性が CVE 公開 13 日後に試されていた ― TEN Framework の CVE-2026-85688 はじめに 前回の記事（ハニーポットに来る「AI 関連」の攻撃）では、「AI クローラ」を名乗る通信の 6 割が探査で、少数の Google Cloud の IP が十数種類の AI クローラの名前を使い回している、と書きました。 その探査の中身を細かく見ていたところ、見慣れないパスがありました。 POST /api/designer/v1/file-content {"file_path":"/proc/self/environ"} 調べると、TEN Framework という AI エージェント（音声対話など）を作るためのフレームワークの、開発用ツールの脆弱性（CVE-2026-85688）を狙ったものでした。この脆弱性は 2026 年 9 月 4 日に CVE として公開され、私が調べた時点の公開情報では「悪用の報告なし」とされていました。しかも、2026 年 10 月 30 日時点で修正版はまだ出ていません。 結論を先に書くと、次の 3 つです。 この脆弱性への探索は、CVE の公開から 13 日後（9 月 17 日）にはハニーポットに来ていた。 1 か月で 707 件、送信元は 51 個の IP で、すべて Google Cloud の IP でした。 狙いはファイルの「読み出し」で、読もうとしたのは 2 つだけ ── プロセスの環境変数（/proc/self/environ）と .env。つまり秘密情報（API キーなど）です。 これは単独の攻撃ではなく、前回の「AI クローラを名乗る探査」の語彙リストの 1 行だった。 同じ IP たちは同じ期間に約 11.8 万件の要求を送っていて、TEN を狙ったものはその 0.6% でした。 ! 調べたのは、インターネット上の VPS に置いた T-Pot 1 台の記録だけです。観測点は 1 つで、「世の中全体でこうなっている」とは言えません。ハニーポットなので、攻撃が「成功」したかどうかも分かりません。言えること・言えないことは、最後にまとめます。 攻撃元の IP は [.] で無害化しています。自分の観測点（IP・ドメイン）は伏せています。 調査は Claude Code と一緒に進めました。攻撃元への接続はしていません。 TEN Framework と CVE-2026-85688 TEN Framework は、リアルタイムの音声・映像を扱う AI エージェントを作るためのオープンソースのフレームワークです。その中に、TMAN Designer という、エージェントの構成をブラウザで編集する開発用ツールがあります。 公式の手順では、TMAN Designer は起動すると次のように表示します。 Starting server at 0.0.0.0 すべてのネットワークインターフェース（0.0.0.0）の 49483 番で待ち受けるのが初期設定です。 CVE-2026-85688 は、この TMAN Designer のファイルの中身を読み書きする API（/api/designer/v1/file-content）に認証が無いという脆弱性です（VulnCheck の公開情報による）。 項目 内容 対象 TEN Framework 0.11.71 以前の TMAN Designer（公開情報の記載）。⚠実際には最新の 0.11.74 でも同じ（下記） 内容 認証なしで任意のファイルを読める（POST）・書ける（PUT） 影響 読み出し＝秘密情報の漏えい。書き込み＝authorized_keys や cron を書き換えてのコード実行につながる 深刻度 CVSS v4.0 で 9.3（Critical） 報告 2026-06-12（GitHub の issue #2187・中身は誰でも読める） CVE の公開 2026-09-04 修正版 なし（2026-10-30 時点） 修正版は、まだ出ていない 公開情報の対象は「0.11.71 以前」ですが、GitHub で確かめると、その後に出た 0.11.72（9 月 18 日）・0.11.73（9 月 22 日）・0.11.74（10 月 21 日）でも、開発中の main ブランチでも、問題のコードは 0.11.71 とまったく同じでした。ファイルを読む処理は、送られてきたパスをそのまま開きます。 // core/src/ten_manager/src/designer/file_content/mod.rs（0.11.74・main とも同じ） match fs::read_to_string(&file_path) { // 送られてきたパスをそのまま読む ... match fs::write(file_path, content) { // 送られてきたパスにそのまま書く 報告した issue は 2026 年 6 月 12 日に作られたまま open で、コメントもありません。つまり、脆弱性の中身（どのファイルの何行目か）は 6 月から誰でも読める状態で、CVE が出たのは 9 月、修正はまだ、という順番です。 開発用ツールなので、本来はインターネットに出すものではありません。ただ、初期設定がすべてのインターフェースで待ち受けるので、クラウドの VM などで起動すると、そのまま外から届いてしまうことがあります。 何が来ていたか ハニーポットのうち、HTTPS を受ける Web のハニーポット（H0neytr4p）の記録を数えました。期間は 8 月 1 日から 10 月 29 日です。 項目 値 件数 707 件（すべて POST＝読み出し） 最初 2026-09-17 10:47（CVE の公開の 13 日後） 最後 2026-10-15 送信元 51 IP・すべて Google LLC の AS 名乗った User-Agent 41 種類（すべて AI のクローラ・アシスタントや検索エンジンの名前） 本文 {"file_path":"/proc/self/environ"} が 362 件・{"file_path":".env"} が 345 件。この 2 つだけ 日ごとの件数は、山が何回かあります。 日付 件数 09-17〜09-23 31 09-24 78 09-25〜09-27 32 09-28 196 09-29 58 09-30〜10-09 75 10-10 147 10-11〜10-12 12 10-13 74 10-14〜10-15 4 計 707 最初の 2 件は、こういう形でした（1 秒違いの同じ IP です）。 09-17 10:47:10 136[.]109[.]234[.]57 UA: PanguBot/1.0 {"file_path":"/proc/self/environ"} 09-17 10:47:11 136[.]109[.]234[.]57 UA: DeepSeekBot/1.0 {"file_path":".env"} 1 秒の間に、名乗る名前が Huawei Cloud のクローラから DeepSeek のクローラに変わっています。 前回の記事で書いた「名前の使い回し」そのものです。 名乗った名前は、Claude-SearchBot・Claude-User・ClaudeBot・ChatGPT-User・GPTBot・OAI-SearchBot・GrokBot・PerplexityBot・Perplexity-User・DeepSeekBot・Qwenbot・KimiBot・MoonshotBot・MistralAI-User・Meta-ExternalAgent・Googlebot・Google-Extended・Bytespider・Amazonbot・CCBot など 41 種類で、多くは 20〜30 件ずつ、特定の名前に偏っていませんでした。本物のクローラが、他人のサーバの /proc/self/environ を POST で読みに来ることはありません。 なぜ「環境変数」と「.env」なのか AI エージェントを動かすサーバには、LLM や音声認識など、外部サービスの API キーがたくさん置かれます。そうしたキーは、環境変数や .env で渡す作りが一般的です。 /proc/self/environ は、そのプロセスの環境変数がそのまま入っているファイルです。ファイルの読み出しの脆弱性があれば、1 回の要求で API キーをまとめて取れる可能性があります。書き込み（コード実行）まで試さず、読み出しの 2 つだけに絞っているのは、「鍵を取る」ことが目的の探査だからだと考えています（推測です）。 同じ IP たちは、ほかに何をしていたか TEN を狙った 51 個の IP が、同じ期間（9 月 15 日〜10 月 16 日）に送ってきた要求をすべて数えると、117,772 件ありました。TEN を狙ったものは 707 件で、0.6% にすぎません。 上位のパスを分類すると、こうなります。 種類 例 AI／ML 系アプリのファイル読み出し・コード実行 /read-document・/feast/read-document（Feast＝ML の特徴量ストア・CVE-2026-23536）、/api/v1/node-load-method/customMCP（Flowise）、/api/v1/validate/code（Langflow）、/api/designer/v1/file-content（TEN） 開発用サーバの穴 /@fs/…/.env?raw??（Vite）、/_debugbar/open・/telescope/requests（Laravel）、/actuator/*（Spring Boot）、/debug/vars（Go）、/functionRouter 秘密ファイルそのもの .env の亜種（.env.bak・.env.prod など）、.npmrc、firebase-adminsdk.json、/@fs/home/ubuntu/.aws/credentials?raw?? 古い既知の脆弱性 PHP-CGI の引数注入（/php-cgi/php-cgi.exe?%AD…） Feast の /read-document（1,344 件）も、本文は TEN とまったく同じ 2 種類（/proc/self/environ と .env）で、すべて Google Cloud の IP からでした。 つまり、TEN の脆弱性は「AI アプリや開発ツールで、ファイルを読める穴」を集めた語彙リストに、公開から 2 週間たたずに加えられた、と見るのが自然です。 初期ポートは狙われていなかった TMAN Designer の初期ポートは 49483 です。もし TEN を専門に狙う攻撃者なら、このポートを探しに来るはずです。 ところが、ハニーポットに届いた 49483 番への接続は、8 月以降で 465 件・27 IP で、月別では 8 月 294 → 9 月 113 → 10 月 58 と、公開後にむしろ減っていました。ふだんのポートスキャンの一部にすぎません。 TEN を狙った 707 件は、すべて HTTPS（443 番）で、すべてドメイン名あてでした。IP アドレスを直接指定した要求は 0 件です。 この探査は「TEN が動いているサーバ」を探しているのではなく、「ドメイン名の Web サーバ」に、手持ちの語彙リストを順に投げているのだと思います。リバースプロキシの裏に開発用ツールをそのまま置いていれば、初期ポートを閉じていても届いてしまいます。 世間の報道との関係 「AI クローラを名乗って認証情報を探す」動きは、2026 年の夏から秋にかけて、何社かが報告しています。 報告 時期 内容 GreyNoise 2026-07-28〜08-23 AI 関連の 13 の名前を名乗る scanner・824 IP・/.env・/.aws/credentials Fastly「AI Bot Cosplay」 2026-09-23（1 日分） 約 630 万件・約 1 万 IP。約 1,600 IP が 94% を占め、ほぼ全部が 1 つのパブリッククラウドから。大半の IP が約 12 種の AI ボット名を回す・96 語の共通の語彙・/@fs/.env（Vite） Cequence（Hackread の記事） 2026-09 下旬〜10 下旬 数秒で別の会社のボット名に切り替える・1 日 300 を超えるクラウドの IP 私の観測とは、1 つのクラウドからの IP・名前の回し方・語彙（.env・Vite の /@fs/）がよく一致します。Fastly のデータの日付（9 月 23 日）は、前回の記事で書いた「9 月下旬から、1 つの IP が多数の名前を使い回すようになった」時期とも重なります。 ただし、どの報告も「どの脆弱性の語彙が入っていたか」の細かいところや、IP などの痕跡は公開していません。TEN Framework の脆弱性が狙われていたことは、私が探した範囲では報じられていませんでした。 CVE-2026-85688 そのものについても、2026 年 10 月 30 日時点で、米 CISA の「悪用が確認された脆弱性」の一覧（KEV・10 月 28 日版）には載っておらず、脆弱性の情報サイトでも「悪用は未確認」とされています。今後 30 日に悪用される確率の推定（EPSS）は 2.6%（10 月 29 日時点・全 CVE の上位 15% ほど）でした。 一方で、脆弱性スキャナ Nuclei の公式テンプレート集には、この脆弱性を調べるテンプレートが 10 月 19 日に加わっています。中身を見ると、送るのは {"file_path":"/etc/passwd"} で、「読めるかどうか」を確かめるだけのものです。 Nuclei の公式テンプレート ハニーポットに来た要求 送る本文 /etc/passwd（読めるかの確認） /proc/self/environ と .env（秘密情報） 時期 10 月 19 日に追加 9 月 17 日から つまり、ハニーポットに来たものは「公開の検査テンプレートで調べた」ものではありません。検査テンプレートが公開される 1 か月前から、最初から鍵を取る本文で試していたことになります。 帰属について：言えること・言えないこと 言えること 2026-09-17 から 10-15 まで、/api/designer/v1/file-content に /proc/self/environ と .env を読む POST が 707 件届いた。 送信元の 51 IP は、記録の時点ですべて Google LLC の AS だった。 同じ IP たちは、AI／ML 系アプリ・開発用サーバ・秘密ファイルを狙う要求を、合計 11.8 万件送っていた。 名乗った User-Agent は 41 種類の AI クローラ・検索エンジンの名前で、1 秒で変わることもあった。 言えないこと 攻撃が成功するかどうか。 ハニーポットは TEN Framework を動かしていません。届いたのは「試み」です。 誰がやっているか。 クラウドの IP は借りて返せるので、その時点の借り手が誰かは分かりません。「Google がやっている」という意味ではありません。 名乗った名前が本物かどうか。 各社が公開している IP の範囲とは照合していません（ただ、本物のクローラが他人の環境変数を POST で読みに来ることは無いので、名前の偽装とみています）。 報道された活動と同じ攻撃者かどうか。 手口と時期は似ていますが、痕跡が公開されていないので照合できません。 「世の中で悪用されていない」かどうか。 公開情報に「悪用の報告なし」とあっても、それは「報告されていない」だけです。今回の観測も、悪用の成功ではなく、試みの観測です。 守る側として、できること TMAN Designer のような開発用ツールを、インターネットに出さない。 初期設定は 0.0.0.0 なので、起動するときに待ち受けるアドレスを 127.0.0.1 に絞るか、ファイアウォールで閉じます。 リバースプロキシの裏に置かない。 今回の探査は初期ポートではなく、ドメイン名の 443 番に来ていました。「ポートを閉じているから大丈夫」とは限りません。 TEN Framework を使っているなら、版を上げても直らないことに注意します（2026 年 10 月 30 日時点で修正版は無し）。TMAN Designer は使うときだけ起動し、待ち受けるアドレスを絞ります。--ip オプションで指定できます（初期値は 0.0.0.0）。tman designer --ip 127.0.0.1 離れた場所から使うなら、SSH のポート転送などで 127.0.0.1 に入ります。修正版が出たかは、GitHub の issue #2187 とリリースで確認してください。 秘密情報が漏れる前提で考える。 ファイルを読める穴が 1 つあれば、/proc/self/environ と .env から API キーがまとめて取れます。キーの権限を必要最小限にして、使っていないキーは消しておきます。 ログで探す。 POST /api/designer/v1/file-content、本文に file_path があるもの、/proc/self/environ を含む要求は、ほぼ確実に探査です。 「AI クローラ」の名前だけで信用しない。 名前は簡単に偽装されます。許可するなら、各社が公開している IP の範囲と照合します。 IoC 攻撃元の IP（すべて Google LLC の AS・記録した時点のもの・上位 10 件）。 IP 件数 34[.]182[.]241[.]223 237 34[.]81[.]77[.]104 139 34[.]181[.]212[.]238 95 35[.]200[.]96[.]9 42 35[.]199[.]105[.]97 40 34[.]142[.]169[.]208 14 34[.]159[.]14[.]111 14 34[.]159[.]229[.]182 10 34[.]159[.]147[.]231 8 136[.]109[.]234[.]57 4 要求の形。 POST /api/designer/v1/file-content Content-Type: application/json {"file_path":"/proc/self/environ"} {"file_path":".env"} 同じ本文が /read-document・/feast/read-document（Feast）にも送られていました。 おわりに 「悪用の報告なし」と書かれ、修正版も出ていない脆弱性に、ハニーポットには CVE の公開から 2 週間たたずに探索が来ていました。ただ、それは TEN Framework を専門に狙う誰かではなく、AI クローラを名乗る大規模な探査が、語彙リストに 1 行足しただけでした。 AI アプリや AI エージェントの基盤は、新しい脆弱性が次々に公開されています。そして、その基盤には API キーが集まっています。ファイルを読める穴は、そのまま「鍵を集める穴」になるので、探す側は新しい穴をすぐに語彙リストへ加えてくるのだと思います。 開発用ツールは外に出さない。出してしまったら、「ポートが違うから」「誰も知らないツールだから」は安全の理由にならない ── というのが、今回の観測から言えることです。 出典 CVE-2026-85688（VulnCheck）: vulncheck.com TEN Framework の GitHub issue #2187（2026-06-12 報告・open）: ten-framework#2187 TEN Framework のリリース一覧（0.11.72〜0.11.74）: github.com/TEN-framework/ten-framework/releases 問題のコード（0.11.74）: github.com/TEN-framework/ten-framework/blob/0.11.… TEN Designer の使い方（Agora のドキュメント・初期ポート 49483）: docs.agora.io CISA KEV（10 月 28 日版）: cisa.gov EPSS（FIRST・2026-10-29）: api.first.org Nuclei の公式テンプレート: github.com/projectdiscovery/nuclei-templates/blob… Feast CVE-2026-23536（NVD）: nvd.nist.gov GreyNoise: greynoise.io Fastly「AI Bot Cosplay」: fastly.com Hackread（Cequence の調査）: hackread.com
AI agent skills for PHP2Shell: what each one checks PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a pair of flaws in PHP itself. The PHP project fixed them on 21 October 2026 in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 (php.net advisory). Within two days, several teams published skills for coding and operations agents (Claude Code, Codex, Devin and others) that look for affected PHP and help update it. We read the skill files of the ones below. This post lists what each one inspects, how it decides whether a build has the fix, and whether it waits for your approval before it changes anything. Disclosure: we run php2shell.fyi, a passive checker for PHP2Shell. None of the tools below is ours. The question that matters most Some Linux distributions ship the fix under the old version number. Ubuntu 24.04 has the fix in php8.3 8.3.6-0ubuntu0.24.04.13 (USN-8948-1). RHEL 9 has it in php-8.0.30-8.el9_8.1 (RHSA-2026:87151). Chainguard has it in 8.4.26-r4. A tool that compares only the upstream number (8.3.6 is lower than 8.3.36) reports these fixed servers as vulnerable. An agent that trusts that answer may try to "fix" a server that is already fixed. So the first column we checked is: does the tool compare the full package version? The skills | Skill | Publisher | What it inspects | Full package version? | Changes | |---|---|---|---|---| | phpcheck-server | OpenAI | The PHP binary or Apache module that serves the site, its package, the OS, containers | Yes | Check only | | phpcheck-url | OpenAI | The Server and X-Powered-By headers of one URL | No, and it says so | Check only | | fix-php-vuln | Cognition | Repositories: Dockerfiles, CI, Helm, Terraform, Ansible, Chef, Puppet | Yes | Only after you pick the repos; then one pull request per repo | | php2shell | Chainguard | Chainguard and Wolfi images, SBOMs, Kubernetes workloads | Yes (apk revisions) | Each change needs approval | | php2shell-response | Iurii Rogulia (community) | Hosts, images, hosting accounts, repositories | Yes | Read-only unless you say otherwise | What the skill files say, in their own words: - OpenAI phpcheck-server: "Compare the full package revision against vendor guidance covering both CVEs. An older upstream version alone does not prove vulnerability." It also asks whether the web workers restarted after the update, and says: "Do not run exploit probes." - OpenAI phpcheck-url: "HTTP headers cannot tell whether the version contains a backported fix." Use it for a first look, not for a verdict. - Cognition fix-php-vuln: "Never compare php -v with upstream numbers to decide this." Discovery ends with: "Stop. Show the table and ask which repos to patch." - Chainguard php2shell: "Every change needs the user's explicit approval first". It also warns: "Never compare version strings as text (-r10 is newer than -r4)". - php2shell-response: "A distribution package may carry the fix under an older version number: check the vendor changelog or advisory, never compare version strings alone." Its mode: "Read-only unless the user says otherwise." Tools that compare only the upstream number These are useful, but read their "vulnerable" answer as a question, not a verdict, on Ubuntu, RHEL and Chainguard: - The ProjectDiscovery Nuclei template for CVE-2026-109618. Its version fallback marks a patch number below the fixed one as vulnerable, so 8.3.6-0ubuntu0.24.04.13 counts as vulnerable. It also marks every version below 8.2 as end of life. - The Assetnote scanner. When it sees no crash signal, it falls back to the X-Powered-By number with the same comparison. - Some community skills compare versions with sort -V on the upstream number only. Before you let an agent change a server - Give it read access first, and ask for a table: runtime, path, version, package, status. - Check that it reads the PHP that serves the site (PHP-FPM, the Apache module, LiteSpeed), not only php -v on the command line. - Ask it to show the restart step. Old PHP processes keep the old code until they stop. ps -eo pid,lstart,cmd | grep -i '[p]hp' shows when each one started. - Do not let it fetch or run public proof-of-concept code. Most public PHP2Shell "PoC" repositories are attack tools, and their code is not reviewed. We keep a read-first prompt, our own SKILL.md and this comparison up to date on php2shell.fyi. The fixed releases, the distribution builds and the mitigations are on php2shell.fyi, with a source for each fact.
🚨 PHP2Shell (CVE-2026-109618/CVE-2026-109619) Nuclei Template : github.com/projectdiscovery/nuclei-templates/blob… Reference: calif.io #hackwithautomation #php2shell t.co
ProjectDiscovery’s Nuclei Templates repository includes a verified template designed to identify websites and servers running PHP by analyzing HTTP response headers. github.com/projectdiscovery/nuclei-templates/blob…
Detect PHP-powered websites & IPs using the updated php-detect nuclei template Link : github.com/projectdiscovery/nuclei-templates/blob… t.co
🚨 CVE-2026-104935 - Ivanti Connect Secure <= 22.8R2.4 - Authentication Bypass via X-DSCGI-PATH Header Nuclei Template : github.com/projectdiscovery/nuclei-templates/blob… Reference: volexity.com #bugbounty #hackwithautomation #ivanti t.co
🚨 CVE-2026-21589 - Atlassian Jira/Confluence/Bitbucket - Pre-Auth Arbitrary File Read Nuclei Template : github.com/projectdiscovery/nuclei-templates/blob… Reference: labs.watchtowr.com #bugbounty #hackwithautomation #atlassian t.co