Security
How this site is protected

We publish the observation of the live site and the configuration we intend to apply as two separate things. Uploading HTML does not change a server's HTTP headers. A missing recommended header is a hardening gap, not evidence of compromise.

1. What we observed — and what it cannot tell us

Around 22:18 JST on 31 October 2026 we re-measured the homepage with curl and the SiteCheck CLI. The response was HTTP 200, the server was nginx, and X-Content-Type-Options was nosniff. Seory's earlier "0 action items, 3 warnings" is a scan from 26 October: it is not a current guarantee, and its three items are not the same classification as the five headers checked here.

The external view tells you what a browser is sent. It does not tell you what the origin is configured to do, whether an application was patched, or whether the site was compromised.

2. Recommended headers: what the responses show

Measured 31 October 2026. "Not observed" means not present in the response we received; it is not a judgement about the server's internal configuration.

3. Configuration samples are not deployment

The security-headers bundle shipped with this site is an example. We have not verified which configuration method the current shared host supports, and the nginx response alone does not establish edit rights or the internal architecture. Placing a sample file in a public folder does not enable it.

If the site moves to Cloudflare, the _headers file goes in the designated static-asset location, and the behaviour and responses are confirmed in a test environment before production. CSP Report-Only does not block anything. Applying a strict CSP across the whole site, Playground included, can break functionality.

4. Things we do not assert

• Not disclosing X-Powered-By or a generator tag is not a problem — and it is not proof that PHP is absent.
• We observed X-XSS-Protection: 1; mode=block, but that header is deprecated and we do not assert it is harmless. It is not a substitute for modern controls.
• Being a static site does not by itself make CSP unnecessary or the risk low.
• An external scan cannot show internal patch level or whether a compromise occurred.
• Reference: the Cloudflare header documentation and the MDN notes on deprecated headers.

5. Tools for checking Third-party verified

Two tools we actually ran: one for the php2shell exposure question, one for auditing the code itself.

5-1. php2shell-checker (OpenAI) Verified

A single-purpose tool that answers one question about PHP2Shell (CVE-2026-109618 / 109619): is this version fixed? Apache License 2.0. It sends no exploitation attempts.

Fixed releases are 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12. URL mode reads X-Powered-By and Server, sends HEAD, and falls back to GET only on 405/501. It does not follow redirects and does not read the body. A site that hides its version returns UNKNOWN.

What we measured (26 October 2026, Node.js 22): aifrontier.co.jp returned UNKNOWN: PHP version not found (exit 3). That is a statement that the PHP version could not be obtained from outside — not proof that PHP is absent or that the site is fixed. We also tried php.net, ja.wordpress.org, drupal.org and sakura.ad.jp: all five returned UNKNOWN. Now that hiding versions is standard, the tool only helps on servers that disclose them.

The author states the limit himself: HTTP headers cannot tell you whether a backport fixed the issue. OK only means the advertised version is new; it does not verify the actual installation. UNKNOWN is neither safe nor unsafe. Running phpcheck-server on the host gets past this limit.

5-2. security-audit-skill (Cloudflare) Verified

A skill that turns a coding agent into an auditor. Cloudflare published it as a starting point for their own vulnerability-discovery harness; MIT licence.

After installing, start the agent in the target codebase and ask in plain language — "security audit this codebase", "find security vulnerabilities in ./src", "do a security review, output to ~/audits/my-project". It triggers on audit requests: a direct audit request runs full-audit mode, questions or narrow tasks run guidance mode. The default output path is ~/security-audit-skill/<repo>/run-N.

Internally it runs six stages: reconnaissance (structure, trust boundaries, input surfaces, existing evidence, deterministic coverage in architecture.md and coverage-ledger.json), coverage, and so on through to reporting. The value is the forced structure: it records what it did not cover, which is exactly what a scan summary usually hides.

6. Updating local runtimes (Mac / Windows / Linux) AIfrontier view

Most vulnerabilities land in the foundation, not the app. Just as php2shell was PHP itself, a hole in the Node.js, Python, Perl, Ruby or PHP runtime affects every application running on it.

6-1. Find out where it came from first

Most failed updates are a path mismatch: the binary you update is not the one that runs. There are three routes — OS-supplied, package manager, version manager — and each is updated separately.

6-2. macOS — Homebrew

Three cautions: (1) /usr/bin/ruby and /usr/bin/perl are OS-managed and SIP-protected — brew upgrade will not change them; use rbenv, perlbrew or the Homebrew formula instead. (2) brew install node gives you Current, not LTS; pin LTS with nvm or volta if that is what production needs. (3) Clear the shell's command cache afterwards with hash -r (bash) or rehash (zsh), or you keep hitting the old path.

6-3. Windows — winget / Chocolatey / Scoop

IDs vary: OpenJS.NodeJS.LTS or OpenJS.NodeJS, Python.Python.3.14, StrawberryPerl.StrawberryPerl, RubyInstallerTeam.Ruby.4.0; for PHP run winget search php because several distributors publish it. Chocolatey: choco upgrade all -y. Scoop: scoop update *. Mixing winget, Chocolatey, Scoop, vendor installers and the Microsoft Store is how the same language ends up installed twice — check winget list node for duplicates first.

6-4. Linux — the distribution's package manager

Distribution packages favour stability and can lag: for Node.js use the NodeSource repository, for Python deadsnakes, and for the rest the upstream repositories where needed. A distribution upgrade does not replace a runtime you installed under your home directory.

7. The October 2026 vulnerability roundup Verified

Between mid and late October, serious vulnerabilities landed in foundations: PHP, the Linux kernel, GitLab, Oracle Java, LiteLLM and BIND 9. The roundup covers 16 components, more than 50 CVEs, 8 of them rated 9.0 or above, 5 unauthenticated RCEs. Priority order and per-chapter detail are in the dedicated feature (Japanese edition).

• Roundup and priority order（日本語）
• Language runtimes: PHP / Node / Python / Ruby / Java / BIND（日本語）
• Kernel / GitLab / Tomcat（日本語）
• Supply chain: LiteLLM（日本語）

"Japanese edition" marks pages that exist only in Japanese. The per-page sources are listed at the end of each page.

8. Where the vulnerability reports live AIfrontier view

This page doubles as the index of the vulnerability reports we maintain. Individual reports (PHP, Node.js, Python, Ruby, Java, the Linux kernel, GitLab, Tomcat and others) are extended edition by edition.

"Not listed" does not mean "safe". For products this site does not cover, read the vendor advisory directly.

9. What this tells us AIfrontier view

These three findings are the last few per cent of what an outside view can see. For a static site the material risks sit elsewhere: (1) domain and certificate management, (2) compromise of the build environment or upload path, (3) takeover of the external scripts you reference. This site loads Tailwind and cdnjs from CDNs — if a CDN is compromised, CSP alone will not save you.

Three practical implications:

1. Headers are not "set and done" — check that they survive the CDN, not just the origin.
2. Roll CSP out in stages — frame-ancestors and default-src first, then externalise inline code.
3. Do not report a scanner's "0 items" as an outcome. What the scan does not cover — patch level, tampering, permissions — needs a different method.

Sources

• Seory site security check (external scanner, run 26 October 2026) — https://tools.seory.co.jp/site-security-check
• Our own measurement: response headers of https://aifrontier.co.jp/ (nginx, retrieved 26 October 2026 13:41 JST; re-measured 31 October 2026 22:18 JST)
• NVD CVE API 2.0 (publication window) — https://services.nvd.nist.gov/rest/json/cves/2.0
• CISA KEV catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• php2shell-checker — https://github.com/openai/php2shell-checker
• security-audit-skill — https://github.com/cloudflare/security-audit-skill
• AIfrontier, "php2shell — a CVSS 9.2 RCE in PHP" (22 October 2026, Japanese) — /ai-news/php2shell-2026-10-22.html

Figures on this page are generated from the same dataset as the unified report and the CVE list (dataset aifrontier-c867dac5565b2d45e0dc). They are not re-verified vendor by vendor on this page.